diff --git a/Shorewall-docs2/NAT.xml b/Shorewall-docs2/NAT.xml index 43de5925b..7b62ac4f3 100644 --- a/Shorewall-docs2/NAT.xml +++ b/Shorewall-docs2/NAT.xml @@ -15,7 +15,7 @@ - 2005-09-08 + 2005-10-04 2001-2004 @@ -125,8 +125,39 @@ A word of warning is in order here. ISPs typically configure their routers with a long ARP cache timeout. If you move a system from parallel to your firewall to behind your firewall with one-to-one NAT, it will - probably be HOURS before that system can communicate with the internet. - There are a couple of things that you can try: + probably be HOURS before that system can communicate with the + internet. + + If you sniff traffic on the firewall's external interface, you can + see incoming traffic for the internal system(s) but the traffic is never + sent out the internal interface. + + You can determine if your ISP's gateway ARP cache is stale using + ping and tcpdump. Suppose that we suspect that the gateway router has a + stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as + follows: + + tcpdump -nei eth0 icmp + + Now from 10.1.1.3, ping the ISP's gateway (which we will assume is + 130.252.100.254): + + ping 130.252.100.254 + + We can now observe the tcpdump output: + + 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF) +13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply + + Notice that the source MAC address in the echo request is different + from the destination MAC address in the echo reply!! In this case + 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while + 0:c0:a8:50:b2:57 was the MAC address of the system on the lower right. In + other words, the gateway's ARP cache still associates 130.252.100.19 with + the NIC in that system rather than with the firewall's eth0. + + If you have this problem, there are a couple of things that you can + try: @@ -198,29 +229,5 @@ shorewall start You want the second one by Alexey Kuznetsov. - - You can determine if your ISP's gateway ARP cache is stale using - ping and tcpdump. Suppose that we suspect that the gateway router has a - stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as - follows: - - tcpdump -nei eth0 icmp - - Now from 10.1.1.3, ping the ISP's gateway (which we will assume is - 130.252.100.254): - - ping 130.252.100.254 - - We can now observe the tcpdump output: - - 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF) -13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply - - Notice that the source MAC address in the echo request is different - from the destination MAC address in the echo reply!! In this case - 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while - 0:c0:a8:50:b2:57 was the MAC address of the system on the lower right. In - other words, the gateway's ARP cache still associates 130.252.100.19 with - the NIC in that system rather than with the firewall's eth0. \ No newline at end of file