extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-23 06:38:53 +01:00
Code Issues Packages Projects Releases Wiki Activity

Improve stale arp documentation for 1-to-1 NAT

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2789 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-10-04 17:18:16 +00:00
parent 116f96b47e
commit 93d0b91831
1 changed files with 34 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
Shorewall-docs2/NAT.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-09-08</pubdate>
<pubdate>2005-10-04</pubdate>
<copyright>
<year>2001-2004</year>
@ -125,8 +125,39 @@
<para>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:</para>
probably be HOURS before that system can communicate with the
internet.</para>
<para>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.</para>
<para>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:</para>
<programlisting>tcpdump -nei eth0 icmp</programlisting>
<para>Now from 10.1.1.3, ping the ISP's gateway (which we will assume is
130.252.100.254):</para>
<programlisting>ping 130.252.100.254</programlisting>
<para>We can now observe the tcpdump output:</para>
<programlisting>13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 &gt; 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 &gt; 130.252.100.177 : icmp: echo reply</programlisting>
<para>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.</para>
<para>If you have this problem, there are a couple of things that you can
try:</para>
<orderedlist>
<listitem>
@ -198,29 +229,5 @@ shorewall start</programlisting>
<para>You want the second one by Alexey Kuznetsov.</para>
</warning>
<para>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:</para>
<programlisting>tcpdump -nei eth0 icmp</programlisting>
<para>Now from 10.1.1.3, ping the ISP's gateway (which we will assume is
130.252.100.254):</para>
<programlisting>ping 130.252.100.254</programlisting>
<para>We can now observe the tcpdump output:</para>
<programlisting>13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 &gt; 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 &gt; 130.252.100.177 : icmp: echo reply</programlisting>
<para>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.</para>
</section>
</article>