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