ToolsMethods Discussed in this Chapter

Tools/Methods Discussed in this Chapter

Diagnostic Logging

Probably one of the single most valuable diagnostic procedures in debugging firewall rules is a catch all logging rule, which was covered earlier in Chapter 9. In all of our following example rules, we will include that example of our diagnostic catch all rule. You may or may not want to keep this rule on in a production environment, especially if you are interested in seeing what your firewall is dropping from a security standpoint. However, bear in mind the additional disk space this might require for long-term use and potential I/O issues caused by excessive writes to the log file(s).

Example:

 # catch all dropped packets $IPTABLES -A INPUT -p all -m limit --limit 1/second \         -j LOG --log-level info --log-prefix "FINAL -- DROP "\         --log-tcp-sequence --log-tcp-options --log-ip-options

Example output:

 Jun 30 17:22:19 localhost kernel: FINAL -- DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:57:00:7d:b9:08:00 SRC=10.5.64.1 DST=255.255.255.255 LEN=328 TOS=0x06 PREC=0x00 TTL=16 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308 Jun 30 17:22:23 localhost kernel: FINAL -- DROP IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0a:e6:8d:ec:af:08:00 SRC=10.10.12.201 DST=255.255.255.255 LEN=153 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=133

Line 1 shows the firewall is dropping a UDP port 67 (DHCP) packet being broadcast from the system 10.5.64.1 on the eth0 (external) interface. Line 2 shows a UDP port 631 (cups printer) packet being broadcast from the system 10.10.12.201 on the etH1 interface.

Viewing NAT Connections with netstat-nat

One highly recommended tool for viewing NAT-ed connections through a firewall is the user-space tool, netstat-nat available from: http://tweegy.demon.nl/projects/netstat-nat/index.html.

This utility, which requires the kernel to be compiled with IP connection tracking, works similarly to the netstat command, but specifically displays NAT connection information.

Example diagnostic usage:

netstat-nat -S would display SNAT or masqueraded connections

netstat-nat -D would display DNAT connections

netstat-nat -L would display connections to the NAT system

Example output:

 [root@minimoose root]# netstat-nat -S Proto NATed Address                   Foreign Address                   State tcp 10.10.12.201:59837                po:imaps                          ESTABLISHED tcp 192.168.32.190:36340              server4:ssh                       ESTABLISHED

This output shows that the system 10.10.12.201 has an open outbound SSL IMAP connection to the remote server "po" and that the system 192.168.32.190 has an open outbound SSH connection to the server "server4."

 [root@minimoose root]# netstat-nat -D Proto NATed Address                   Foreign Address                State tcp 10.10.12.201:37708                10.10.12.1:http                ESTABLISHED tcp 192.168.32.190:47775              192.168.32.1:5190              ESTABLISHED

This output demonstrates more advanced inbound connection data. Specifically, our firewall is running transparent application layer proxies, reaim (for IM traffic) and squid (for web traffic) on the firewall itself. Both of these proxies are discussed in later chapters, and the data here indicates that there is an open redirect from the systems 10.10.12.201 and 192.168.32.190 to the locally running proxy servers on the system. From the end user's perspective, they are using their applications as normal. Specifically the system at 10.10.12.201 has an open web browser on www.cnn.com, and 192.168.32.190 has an open AOL Instant Messenger client.

 [root@minimoose root]# netstat-nat -L Proto Source Address                  Destination Address         State raw   192.168.32.1:                   192.168.32.190:             REPLIED tcp   192.168.32.190:59471            192.168.32.1:ssh            ESTABLISHED tcp   192.168.32.190:59590            192.168.32.1:ssh            ESTABLISHED tcp   192.168.32.190:58923            empire:ssh                  ESTABLISHED tcp   ip68-98-150-6.dc.dc.cox.:41579 hal-d023e.blue.aol.com:5190  ESTABLISHED

This shows an even more advanced picture of the traffic being NAT-ed through our firewall. The output from this shows a "raw" connection from the firewall (192.168.32.1) to the system 192.168.32.190. In this case, this "raw" connection is an IPSEC VPN being used to secure a wireless network that has been configured as a DMZ. On lines 2 and 3, we also see two SSH sessions from the 192.168.32.190 host to the firewall. These are two separate SSH sessions being used to run the netstat-nat commands. The fourth line shows an open SSH session from 192.168.32.190 to the system named "empire," which in this case happens to be on the internal "wired" network. Line 5 shows the rest of the picture from the netstat-nat -D example here. This is the reaim proxy server making the connection to the AOL Instant Messenger on behalf of the host 192.168.32.190.

Listing Current NAT Entries with iptables

 iptables -t nat -L

This command will show all your NAT rules on your system.

Example output:

 [root@minimoose root]# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target      prot opt source                 destination DNAT        tcp  --  anywhere               anywhere         tcp dpts:6881:6889 to:192.168.32.190 REDIRECT    tcp  --  anywhere               anywhere         tcp dpt:http redir ports 3128 REDIRECT    tcp  --  anywhere               anywhere         tcp dpt:5190 redir ports 5190 Chain POSTROUTING (policy ACCEPT) target     prot opt source                  destination MASQUERADE  all  --  anywhere               anywhere Chain OUTPUT (policy ACCEPT) target     prot opt source                  destination

The first line in the PREROUTING chain shows a DNAT rule on the firewall that redirects connections to the firewall on ports 6881 through 6889 to the system 192.168.32.190. This is specifically an example of getting the bittorrent file sharing protocol through a firewall. Line 2 shows the firewall is configured as a transparent proxy serverany outbound connections through the firewall on port 80 will be redirected to the local port 3128, which is running a squid proxy server. This is called a "transparent proxy" because from the user's experience, they do not even know the proxy server is there. Line 3 is a similar transparent redirect, but this time for the AOL Instant Messenger protocol. Again from the user's perspective, this is completely transparent.

The POSTROUTING chain shows that the system is configured to MASQUERADE connections from anywhere to anywhere. In this case our firewall has a dynamic IP address.

Listing Current NAT and Rule Packet Counters

 iptables -L -nvx

This command will show the packet counters on each one of your rules.

Example output:

 [root@minimoose root]# iptables -L -nvx Chain INPUT (policy DROP 2780 packets, 575124 bytes)     pkts      bytes target     prot opt in     out      source            destination  1844685 236055702  ACCEPT    all --   *      *        0.0.0.0/0          0.0.0.0/0 state RELATED,ESTABLISHED       3       180 ACCEPT     tcp --   *      *        0.0.0.0/0          0.0.0.0/0 tcp dpt:22       0         0 ACCEPT     tcp --  !eth0   *        0.0.0.0/0          0.0.0.0/0 tcp dpt:53      49      3196 ACCEPT     udp --  !eth0   *        0.0.0.0/0          0.0.0.0/0 udp dpt:53     124      6216 ACCEPT     tcp --  !eth0   *        0.0.0.0/0          0.0.0.0/0 tcp dpt:3128       8       480 ACCEPT     tcp --  !eth0   *        0.0.0.0/0          0.0.0.0/0 tcp dpt:5190    2794    577784 IPSEC      all --  *       *        0.0.0.0/0          0.0.0.0/0    2780    575124 XWIN       all --  *       *        0.0.0.0/0          0.0.0.0/0    2449    507425 LOG        all --  *       *        0.0.0.0/0          0.0.0.0/0 limit: avg 1/sec burst 5 LOG flags 7 level 6 prefix `STEALTH -- DROP ' Chain FORWARD (policy DROP 0 packets, 0 bytes)     pkts      bytes target     prot opt in     out     source destination  3619455 2438207911 ACCEPT     all  --  *      *       0.0.0.0/0          0.0.0.0/0 state RELATED,ESTABLISHED      159      8513 ACCEPT    all --  eth1    *       0.0.0.0/0          0.0.0.0/0 state NEW        0         0 ACCEPT    all --  ipsec0  eth0    0.0.0.0/0          0.0.0.0/0 state NEW        0         0 ACCEPT    all --  ipsec1  eth0    0.0.0.0/0          0.0.0.0/0 state NEW     1219     77605 ACCEPT    all --  ipsec2  *       0.0.0.0/0          0.0.0.0/0 state NEW        0         0 IPSEC     all --  *       *       0.0.0.0/0          0.0.0.0/0 Chain OUTPUT (policy DROP 0 packets, 0 bytes)     pkts      bytes target      prot opt in      out    source destination  1895909 2414814203 ACCEPT      all  --  *       *     0.0.0.0/0          0.0.0.0/0 state NEW,RELATED,ESTABLISHED        0      0     TCPMSS    tcp -- *         eth0    0.0.0.0/0          0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain IPSEC (2 references)     pkts      bytes target        prot opt in       out     source destination        0        0 ACCEPT      udp  --  eth1      *        0.0.0.0/0      0.0.0.0/0 udp dpt:500        0        0 ACCEPT      esp  --  eth1      *        0.0.0.0/0      0.0.0.0/0       14     2660 ACCEPT      udp  --  eth2      *        0.0.0.0/0      0.0.0.0/0 udp dpt:500        0        0 ACCEPT      esp  --  eth2      *        0.0.0.0/0      0.0.0.0/0 Chain XWIN (1 references)     pkts      bytes target      prot opt in         out      source destination         0         0 ACCEPT       tcp  --   lo         *          0.0.0.0/0 0.0.0.0/0            tcp dpts:6000:6015

The output here shows the various packet counters for each default table (INPUT, FORWARD, and OUTPUT), as well as three user-defined tables, LOG, IPSEC, and XWIN. Packet counters are especially useful for debugging when your rules are being triggered.

Forward: A Basic Masquerading Firewall

Figure 12.1 is a basic firewall setup using IP masquerading. This type of configuration is suitable for environments involving dynamic IP addresses on the external interface. If you have a static IP address on your external interface, a SNAT configuration is going to be a more efficient choice. In this configuration, our firewall Host-A protects an internal network, 10.10.10.0/24, and is connected to the Internet through a cable or DSL connection. If you're trying to get a firewall set up quickly and aren't concerned about more complicated features, this is the section for you.

Figure 12.1. A masquerading SOHO firewall.

This example script is self-contained; it consists of a minimal filtering policy, purely allowing all traffic from the internal RFC1918 network to be masqueraded out through the external interface:

 #!/bin/sh IPTABLES="/sbin/iptables" EXTERNAL="eth0" INTERNAL="eth1" # Flush our old rules $IPTABLES -F $IPTABLES -X # load your connection tracking modules modprobe ip_conntrack modprobe ip_conntrack_ftp # this next rule is mainly for PPPoE, VPN, and DSL users $IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN \         -j TCPMSS clamp-mss-to-pmtu # these are our connection tracking rules $IPTABLES -A INPUT -m state \         --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state \         --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state \         --state NEW,ESTABLISHED,RELATED -j ACCEPT # finally, we masquerade our traffic $IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Enable IP Forwarding in the kernel echo "1" > /proc/sys/net/ipv4/ip_forward

Note that we are binding this rule to our external interface, eth0. This is a good practice to get into because not specifying an interface will cause this rule to masquerade traffic across all interfaces. It doesn't really matter in a two-interface setup like our firewall here; however, if you were to add VPNs or other interfaces at a later date, this would cause problems.

Forward: A Basic SNAT Firewall

In a network where you have a static external IP, SNAT will provide you with better performance than a masquerading firewall. The following example demonstrates the same configuration as just detailed, where the firewall Host-A protects an internal network, 10.10.10.0/24, and has the static IP address 22.33.44.55 on its external interface. If you are in a SOHO environment with a dynamic IP address, you do not want to use SNAT.

Figure 12.2. A basic SNAT firewall.

This example script is self-contained; it consists of a minimal filtering policy, purely allowing all traffic from the internal RFC1918 network to be NAT-ed out through the external interface. In addition, this example demonstrates a stricter "unless allow, deny" firewall policy, the rules required to allow SSH connections to the firewall, and a caching DNS server on the internal interface:

 #!/bin/sh IPTABLES="/sbin/iptables" EXTERNAL="eth0" INTERNAL="eth1" EXTERNALIP="22.33.44.55" # Flush our old rules $IPTABLES -F $IPTABLES -X echo "Setting default filter policy" $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP # load your connection tracking modules modprobe ip_conntrack modprobe ip_conntrack_ftp # this next rule is PPPoE, and DSL users $IPTABLES -A OUTPUT -o eth0 -p tcp \         --tcp-flags SYN,RST SYN -j TCPMSS \         clamp-mss-to-pmtu # these are our connection tracking rules $IPTABLES -A INPUT -m state \         --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state \         --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state \         --state NEW,ESTABLISHED,RELATED -j ACCEPT # Allow DNS queries on the internal interface $IPTABLES -A INPUT -p tcp --dport 53 -i  eth1 -j ACCEPT $IPTABLES -A INPUT -p udp --dport 53 -i eth1 -j ACCEPT # Allow SSH $IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT # finally, we SNAT our traffic $IPTABLES -t nat -A POSTROUTING -i eth1 -o $EXTERNAL\         -j SNAT --to $EXTERNALIP # Enable IP Forwarding in the kernel echo "1" > /proc/sys/net/ipv4/ip_forward

Note how this final rule is applied to eth0, the external interface. This is because we want to match all traffic leaving our firewall and change its source IP to 22.33.44.55. This allows the flexibility of creating VPNs, as discussed in later chapters of the book.

Forward: A Basic DMZ

Figure 12.3 demonstrates taking the ruleset from the previous listing and adding a DMZ network, where we can support separate web and mail servers. Our firewall, Host-A, protects an internal network, 10.10.10.0/24, a DMZ network, 192.168.1.0/24, where we contain our web server Host-B with the IP address of 192.168.1.80 and our mail server Host-C with the IP address of 192.168.1.25. In addition, we will configure this DMZ so that it cannot access the internal network and that all hosts on both the Internet and the internal network can connect to our DMZ-ed web and mail servers using their hostnames, www.domain.com, and mail.domain.com, respectively. Creating DMZs around specific services is covered in more detail in later chapters.

Figure 12.3. A basic DMZ network.

This example script is self-contained; it consists of a simple filtering policy allowing all traffic from the internal RFC1918 network to be NAT-ed out through the external interface and DNAT-ing all traffic from the firewall's 22.33.44.55 IP address to the DMZ server, 192.168.1.80:

 #!/bin/sh IPTABLES="/sbin/iptables" EXTERNAL="eth0" INTERNAL="eth1" DMZ="eth2" EXTERNALIP="22.33.44.55" # servers WEBSERVER=192.168.1.80 echo "Setting default filter policy" $IPTABLES -P INPUT   DROP $IPTABLES -P OUTPUT  DROP $IPTABLES -P FORWARD DROP # load your connection tracking modules modprobe ip_conntrack modprobe ip_conntrack_ftp # this next rule is PPPoE, and DSL users $IPTABLES -A OUTPUT -o eth0 -p tcp \         --tcp-flags SYN,RST SYN -j TCPMSS \         clamp-mss-to-pmtu # these are our connection tracking rules $IPTABLES -A INPUT -m state \         --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state \         --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state \         --state NEW,ESTABLISHED,RELATED -j ACCEPT # Allow SSH to the firewall on the internal interface # only $IPTABLES -A INPUT -p tcp --dport 22 -i $INTERNAL \         -j ACCEPT # Forward traffic to our DMZ server, 192.168.1.80 $IPTABLES -A FORWARD -i $EXTERNAL -o $DMZ -p tcp \         -d $EXTERNALIP -m state \         --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $EXTERNAL -o $DMZ -p tcp \         --dport $EXTERNALIP -m state \         --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -t nat -A PREROUTING -i $EXTERNAL -p tcp \         -d $EXTERNALIP -j DNAT \         --to-destination $WEBSERVER # finally, we SNAT our traffic $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -j SNAT \         --to-source $EXTERNALIP # Enable IP Forwarding in the kernel echo "1" > /proc/sys/net/ipv4/ip_forward

Note that we are sending all traffic hitting the firewall's external interface to the DMZ server. In later chapters we will discuss how to specify DNAT rules for specific services.

Troubleshooting: Internal Systems Cannot Communicate with External SystemsPackets Do Not Pass in or Out of the Firewall

Extended Description: You have created a NAT or masquerading firewall between an external network and one more internal networks. These networks cannot communicate with systems on the other side of the firewall. Packets do not pass through the firewalleither inbound or outbound.

Figure 12.4. Graphic showing networks unable to communicate through a masquerading firewall.

Figure 12.5. Diagnostic flowchart, part 1.

Figure 12.6. Diagnostic flowchart, part 2.^[**]

^[**] Setting NEW globally on the INPUT, FORWARD and OUTPUT chains effectively disables all your filtering.

Corrective Actions

Connect cablingensure that all cables are correctly wired and correctly plugged in. Loose or bad cabling can cause inconsistent operation.
Ensure that the network card driver you are using is the correct one for the device. Oftentimes drivers, such as the tulip chipset, will work on multiple tulip-based network cards.
Ensure that the correct default route and netmask is set on the gateway/firewall system. Ensure that the routes back to the internal networks are correct as well. Consider clearing all the firewall rules and testing basic access to external and internal networks from the firewall itself.
Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward.

Load IP connection tracking module modprobe <modulename>, where <modulename> corresponds to the ip_tracking module for the service you are using.

Example:

 modprobe ip_conntrack_amanda modprobe ip_conntrack_ftp modprobe ip_conntrack_irc modprobe ip_conntrack modprobe ip_conntrack_tftp modprobe ip_nat_amanda modprobe ip_nat_ftp modprobe ip_nat_irc modprobe ip_nat_snmp_basic modprobe ip_nat_tftp

Enable connection tracking or output rules. Connection tracking rules:

 $IPTABLES -A INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT # Don't set NEW in here** $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Confirm that the kernel is actually compiled to support IP Forwarding and NAT For 2.4.x Kernelsif this is a custom compiled kernel, ensure that the following is set:

Make menuconfig for console

make xconfig for X11

Ensure the following is set:

 Networking options --->   [*] Network packet filtering (replaces ipchains)   IP: Netfilter Configuration --->     [*] Connection tracking (required for masq/NAT)       [M]   FTP protocol support (** Only if you need FTP)       [M]   Amanda protocol support (** Only if you need Amanda)       [M]   TFTP protocol support (** Only if you need TFTP)       [M]   IRC protocol support (** Only if you need IRC)     [*] IP tables support (required for filtering/masq/NAT)       [*]   Connection state match support     [*]   Full NAT       [*]     MASQUERADE target support (** Required for dynamic connections only)

For 2.6.x kernelsif this is a custom compiled kernel ensure that the following is set:

Make menuconfig for console

make xconfig for X11

Ensure the following is set:

 Device Drivers --->   Networking support --->     Networking options --->     [*] Network packet filtering (replaces ipchains) --->       [*]   Bridged IP/ARP packets filtering (NEW) (if you are creating a briding firewall)       IP: Netfilter Configuration --->         <*> Connection tracking (required for masq/NAT)             [M]   FTP protocol support (** Only if you need FTP)             [M]   Amanda protocol support (** Only if you need Amanda)             [M]   TFTP protocol support (** Only if you need TFTP)             [M]   IRC protocol support (** Only if you need IRC)        <*>  IP tables support (required for filtering/masq/NAT)           [*]    Connection state match support        <*>    Full NAT        <*>  MASQUERADE target support (** Required for dynamic connections only)

Clear all the NAT rules on the source or destination networks.
Ensure that any DROP rules do not match the traffic from your NAT-ed network(s). If the IP forwarding gateway system functions correctly with all firewall rules disabled, it's possible that there are issues with the order in which the firewall rules are set. Ensure that the ALLOW and session tracking rules come before any DROP rules that reference the internal network or services being accessed.
Ensure that the upstream gateway from the firewall is configured with the appropriate routes for the forwarded internal networks with the firewall set as the gateway for those networks.
Clear all the filter rules from your firewall. If one of these rules is having a conflict with the traffic routing through your firewall, consult the diagnostic logging section of this book for further information on how to determine which rule is being problematic.
Ensure that the nodes on your internal network are configured with the firewall set as their default route or gateway into those external networks.
The problem is most likely not in the firewall as at this point the system is configured as a basic IP forwarding gateway and contains no filtering rules at all. Possibly the problem is DNS related or is in the network (netmask, and so on) settings on the hosts themselves.
Enable NAT and/or MASQUERADE in the Linux kernel.
Enable NAT or MASQUERADE rules for the internal network. ExampleMASQUERADE rule, where eth0 is the Internet or external network facing interface:
```
 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
```
Ensure that the NAT or MASQ rule is bound to the correct interface. Failure to bind to the correct interface can result in traffic destined for non-masqueraded or NAT-ed network to appear to come from the NAT or MASQUERADED network(s), which may not be intended.

Enable connection tracking with the following rule:

 $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT     # Don't set NEW in here** $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Clear DROP or OUTPUT filtering rules that may be interfering with the routing of traffic.

Troubleshooting: Internal Systems Can Communicate with External SystemsDMZ Systems Cannot Be Reached from the Outside

Extended Description: You have created multiple networks, including one or more DMZ networks. Both internal and DMZ networks can communicate with external systems, but external systems cannot connect to systems on the DMZ network.

Figure 12.7. Internal traffic can communicate with external systems; DMZ systems cannot be accessed from the outside.^[**]

^[**] Setting global NEW rules on the INPUT, FORWARD, and OUTPUT chains effectively disables all your filtering.

Figure 12.8. DMZ Diagnostic Flowchart.

Corrective Actions

Connect cablingensure that all cables are correctly wired and correctly plugged in. Loose or bad cabling can cause inconsistent operation.
Ensure that the network card driver you are using is the correct one for the device. Oftentimes drivers, such as the tulip chipset, will work on multiple tulip-based network cards.
Ensure that the correct default route and netmask is set on the gateway/firewall system. Ensure that the routes back to the internal networks are correct as well. Consider clearing all the firewall rules and testing basic access to external and internal networks from the firewall itself.
Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward

Compile DNAT support into the kernel: 2. 4.x Kernels:

 Networking options --->   IP: Netfilter Configuration --->       <M>Connection tracking (required for masq/NAT)         <M>   FTP protocol support         <M>   IRC protocol support Full NAT          <M> MASQUERADE target support          <M> REDIRECT target support Device Drivers --->    Networking support --->      Networking options --->         [*] Network packet filtering (replaces ipchains) --->           IP: Netfilter Configuration ---> <M> Connection tracking (required for masq/NAT) FTP protocol support <M>    IRC protocol support <M> IP tables support (required for filtering/masq/NAT) Full NAT <M> MASQUERADE target support

Load IP connection tracking module: modprobe <modulename>, where <modulename> corresponds to the ip_tracking module for the service you are using, for example

 modprobe ip_conntrack_amanda modprobe ip_conntrack_ftp modprobe ip_conntrack_irc modprobe ip_conntrack modprobe ip_conntrack_tftp modprobe ip_nat_amanda modprobe ip_nat_ftp modprobe ip_nat_irc modprobe ip_nat_snmp_basic modprobe ip_nat_tftp

Enable connection tracking or output rules.

Connection tracking rules:

 $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Don't set NEW in here** $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Internal Systems Can Communicate to External Systems Except to a Small Percentage of Systems

You have created internal and/or DMZ network(s). These systems can communicate with most systems in the outside world; however, a small percentage of systems that are otherwise accessible from other networks cannot be reached.

Figure 12.9. Internal systems cannot communicate with a small percentage of external systems.^[**]

^[**] Setting global NEW rules on the INPUT, FORWARD, and OUTPUT chains effectively disables all your filtering.

This is most likely due to the Explicit Congestion Notification (ECN) feature in the Linux kernel. While a highly useful feature, some broken TCP/IP stacks cannot safely handle this traffic. Fortunately this is very easy to disable, using /proc:

 # this will disable ECN echo 0 > /proc/sys/net/ipv4/tcp_ecn #this will enable ECN echo 1 >/proc/sys/net/ipv4/tcp_ecn

Internal Systems Can Communicate with External Systems, but only with Small PacketsLarge File Transfers Fail

You are configuring a network on a DSL and have created internal and/or DMZ network(s). Only small payload traffic, such as ping, will work inconsistently through the firewall. Large payload traffic fails to traverse the firewall 100% of the time.

Most likely this is due to an MTU mismatch when you're dealing with DSL, PPPoE, or VPN connections. Generally, the following rule should solve this problem:

 $IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN \         -j TCPMSS clamp-mss-to-pmtu

On VPN connections you might need to further reduce your MTU settings, due to the even higher overhead. Consult the VPN chapter for more information on this topic.