Q: Why is my GB-250 or GB-250e periodically resetting services?
The GB-250 and GB-250e were designed for small business networks, yet offer a full complement of threat management and network services to allow administrators to select the features that best match their needs. In order to provide network administrators with the broadest range of choices, GTA offers all threat management features (IPS, Mail Sentinel Anti-Spam, Mail Sentinel Anti-Virus, and Surf Sentinel Content Filtering) on the GB-250 and GB-250e. Additionally, many advanced network services (traditional and transparent proxy, authentication server, SNMP server, DHCP server, and VPN) are also available on these units.
However, the hardware specifications of these products necessitates limitations on utilizing every threat management and network service, as each additional service places greater demands the firewall’s CPU and memory. Firewall administrators should carefully select which threat management features and network services to activate on the firewall, and monitor the results to prevent undesired interruptions of service.
By activating all threat management and network services it is possible to exceed the available resources of the GB-250 and GB-250e. Should enabled services exceed the GB-250 or GB-250e’s resources, administrators will notice that GB-OS will restart enabled services as they exceed available memory and will generate a log message. These periodic restarts may result in a temporary loss of enabled services or network connectivity. GB-250 and GB-250e administrators with multiple threat management services should monitor GB-OS log messages to ensure continuous network connectivity.
If the GB-250 or GB-250e consistently exceeds available memory, administrators should consider disabling unnecessary GB-OS services or reducing defined threat management settings. To assist administrators in evaluating threat management features and their impact on performance of these units, GTA offers 30 day evaluation versions of Mail Sentinel Anti-Spam and Surf Sentinel Content Filtering. These evaluation versions may be requested at www.gta.com. If all services are desired, administrators may wish to consider one of GTA’s more powerful products, such as the GB-800 or GB-2000 Firewall UTM Appliance family, which are designed to meet the needs of more robust network implementations.
Q: Which policy should I use?
As packets flow into the firewall, they may be stopped, redirected or transformed depending on the types of policies that the packet ‘hits.’ If a packet succeeds through all possible checks and transformations, it is transmitted to a network destination on the other side of the firewall. But which policy set should you use to create your desired traffic flow to your desired destination? You must use policies to tell the firewall how traffic should be handled by the firewall’s logic.
Policies are enacted according to the firewall’s logical order. Based upon the type of packet, remote access, outbound, and/or pass-through policies may be required to permit a connection.
• Is the packet outgoing from a network protected by the firewall? • Create an outbound policy.
• Is the packet incoming to a network protected by the firewall (including from a PSN)?
• If it has NAT or VPN tunnel encapsulation, create a remote access policy. If it has no NAT, or has had NAT removed during decapsulation, use a pass through policy. Note that for en- capsulated traffic, this may mean that you need both a remote access and a pass through policy.
Also note that even if all your firewall policies are correct, a packet without a valid route cannot be delivered, even if it is allowed! If policies have been ruled out as the source of your problem, check routing settings.
Q: How do I determine which rule or policy is causing rejected traffic?
When the firewall evaluates a packet for acceptance or rejection, many rules may be used. However, they are not evaluated in a random order, but sequentially, and you can use this knowledge to help you trace conditions that may be causing firewall misconfiguration.
Order of evaluation is indicated on some screens by the index number (listed order on the screen) of a rule. Start by testing the configurations on the top of the page, and work your way down until all configurations have been tested. For example, a rule/policy with an index of 1 will be evaluated before a rule/policy with an index of 5, and should be tested first.
Q: Why can’t ALL hosts (computers and devices) behind the firewall reach the Internet?
This is usually a routing problem. The traceroute facility can be very useful in debugging routing problems. Check for these problems:
• Are the hosts that can’t reach the Internet on a different network subnet from the firewall? • Have you added a static route on the firewall to tell it which router is used to reach the Internet?
Have you set the router’s default route to be the firewall? Have you set the default route for hosts on the problem network to be the router or firewall?
• Is the wrong IP address assigned to the hosts or firewall? All network interfaces on the firewall must be on different logical networks.
• Is the default route incorrectly assigned? The default route should always be on the same subnet as the network interface of the host (this is true for all hosts, not just the firewall). For a firewall, the default route must be an IP address on the network which is attached to the network interface. Note
When using PPP, PPTP or PPPoE, the default route is not necessarily on the same subnet. The route is assigned by your PPP provider.
Q: Why can’t ONE host (computers and devices) behind the firewall reach the Internet?
This may indicate that the default route is assigned incorrectly (or not at all) to hosts on the protected or Private Service Networks. All hosts protected by the firewall must use the IP address of the firewall’s network interface for the respective network. Hosts that reside behind routers or other gateways on these networks generally use the IP address of the gateway or router instead.
Q: I can’t access a tunnel that I have created. Why?
There are a few key points to remember about tunnels:
• You cannot access a tunnel from the protected network, since you can access the host directly (use the real IP address of the host).
• The source side of the tunnel must use an interface or alias that is on the external network for tunnels from the external network to the PSN or to the protected network.
• The source side of the tunnel must use an interface or alias that is on the Private Service Network for tunnels from the PSN to the protected network.
• You must have a remote access policy that allows access to the tunnel from the host in question. A tunnel that has no remote access policy, or an improperly configured policy assigned to it, will generate a blocked packet message to the log file. Policies can be defined by using the tunnel’s automatic policies, located under the Advanced tab, or by manually creating remote access policies. • Ensure that your tunnel is active. Check the Monitor section to verify that both your tunnel and remote
access policies are active.
• Check the log messages for policy blocks when a remote host attempts to access the tunnel. If you see a block message, your remote access policy is most likely not configured correctly. If no block message appears, check the host that is specified as the target in the tunnel definition. The target host should have a default route configured, with the service in question running on the specified port. From the target host try to ping the remote host.
Q: Why can’t I “see” or ping the protected network interface?
You may have the wrong cable for your connection.
• For a direct connection (GTA Firewall to host or router) you need a crossover cable. • For a connection to a hub or switch you need a straight-through cable.
A yellow crossover cable and grey straight-through cable may be included with hardware appliances.
Note
Distinguish between crossover cables and straight-through cables by comparing the connection ends. On a straight-through cable, the wire order matches; on a crossover cable, the first three of the four cables are in reverse order.
Also check that your computer belongs to the same subnet as the IP address of the protected network interface.
Q: How do I bypass NAT, allowing no-NAT routing to an IP address on the internal net-
work?
NAT is applied by default, using connection state tracking to hide and protect internal IP addresses from the external network. In some cases, it is desirable to bypass NAT and make an internal host’s IP address visible to the external network. To bypass NAT, use pass through.
Pass through connections require two main configuration aspects on the firewall:
• Hosts/Networks to define groups of hosts that may bypass NAT
• Policies to specify conditions (such as specific ports or times) pass through hosts/networks’ connections must satisfy to be accepted
Note that pass through hosts must have an externally routable IP address; internal (RFC 1918) IP addresses (e.g. 192.168.1.2) cannot be used with pass through, because they do not have valid routes. Additionally, some paths may need to be added to external routers, indicating the firewall’s external interface as the gateway for the pass through hosts/networks.
Because pass through bypasses NAT, its policies are bidirectional: they can allow both inbound and outbound connections from pass through hosts/networks. An outbound policy is not necessary.
Q: I get a bridging loop error message when I am in bridging mode.
A bridging loop message indicates a physical loop in the network cabling.
Feb 2 02:04:30 pri=4 msg=”Bridging loop (13) 00:00:5e:00:01:60->01:00:5e:00:00:12 eth1->eth0 (muted)” src=199.120.225.53 dst=224.0.0.18
Check physical wiring of hubs and switches to be sure there are no crossed wires. Bridged networks must be physically isolated.
Q: My Microsoft Exchange server located on the PSN can’t find the PDC (Primary Do-
main Controller) on the protected network. Why?
Normally, NetBIOS locates the primary domain controller (PDC) and other peer hosts by using broadcast packets. Since the firewall blocks all broadcast packets, another method of locating the PDC needs to be used. The solution is to use an LMHOST file and add an entry for the PDC providing a conduit for NetBIOS traffic to the PDC via a tunnel and allow access via remote access policies.
1. Create a LMHOST file and insert an entry for the PDC. This entry will use the PDC’s NetBIOS name, the NetBIOS domain name, and the PSN interface IP address where the tunnel will be created.
2. Create three tunnels from the PSN interface to the PDC for NetBIOS services. UDP 137 - NetBIOS name resolution
UDP 138 - NetBIOS datagrams TCP 139 - NetBIOS data transfer
3. Create three remote access policies that allow the MS Exchange server on the PSN to access the three tunnels you created in step 2.