From 02e89fa699015ed6619bda54f4f46d882e08d8bf Mon Sep 17 00:00:00 2001 From: teastep Date: Sat, 18 Dec 2004 17:07:38 +0000 Subject: [PATCH] Update docs git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1830 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs2/NAT.xml | 133 ++++++++++++++++++++++++++++++++--- Shorewall-docs2/ProxyARP.xml | 26 ++++++- Shorewall-docs2/myfiles.xml | 62 +++++++++++++--- 3 files changed, 197 insertions(+), 24 deletions(-) diff --git a/Shorewall-docs2/NAT.xml b/Shorewall-docs2/NAT.xml index cba3c5fc0..9a57f73a2 100644 --- a/Shorewall-docs2/NAT.xml +++ b/Shorewall-docs2/NAT.xml @@ -15,7 +15,7 @@ - 2004-08-10 + 2004-12-16 2001-2004 @@ -29,7 +29,8 @@ 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled - GNU Free Documentation License. + GNU Free Documentation + License. @@ -70,7 +71,8 @@ Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above example) is (are) not included in any specification in - /etc/shorewall/masq or /etc/shorewall/proxyarp. + /etc/shorewall/masq or + /etc/shorewall/proxyarp. The ALL INTERFACES column is used to specify @@ -90,15 +92,19 @@ Shorewall will automatically add the external address to the specified interface unless you specify ADD_IP_ALIASES=no - (or No) in /etc/shorewall/shorewall.conf; - If you do not set ADD_IP_ALIASES or if you set it to Yes - or yes then you must NOT configure your own alias(es). + (or No) in + /etc/shorewall/shorewall.conf; If you do not set + ADD_IP_ALIASES or if you set it to Yes or + yes then you must NOT configure your own + alias(es). - Shorewall versions earlier than 1.4.6 can only - add external addresses to an interface that is configured with a single - subnetwork -- if your external interface has addresses in more than one - subnetwork, Shorewall 1.4.5 and earlier can only add addresses to the - first one. + + Shorewall versions earlier than 1.4.6 can only add external + addresses to an interface that is configured with a single + subnetwork -- if your external interface has addresses in more than + one subnetwork, Shorewall 1.4.5 and earlier can only add addresses + to the first one. + @@ -112,4 +118,109 @@ you must have enabled CONFIG_IP_NF_NAT_LOCAL in your kernel. + +
+ ARP cache + + 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: + + + + A reading of TCP/IP Illustrated, Vol 1 by + Stevens reveals + Courtesy of Bradey Honsinger + that a gratuitous ARP packet should cause + the ISP's router to refresh their ARP cache (section 4.7). A + gratuitous ARP is simply a host requesting the MAC address for its own + IP; in addition to ensuring that the IP address isn't a + duplicate... + +
+ if the host sending the gratuitous ARP has just changed its + hardware address..., this packet causes any other host...that has an + entry in its cache for the old hardware address to update its ARP + cache entry accordingly. +
+ + Which is, of course, exactly what you want to do when you switch + a host from being exposed to the Internet to behind Shorewall using + one-to-one NAT (or Proxy ARP for that matter). Happily enough, recent + versions of Redhat's iputils package include arping, + whose -U flag does just that: + + arping -U -I <net if> <newly proxied IP> +arping -U -I eth0 66.58.99.83 # for example + + Stevens goes on to mention that not all systems respond + correctly to gratuitous ARPs, but googling for arping + -U seems to support the idea that it works most of the + time. + + To use arping with one-to-one NAT in the above example, you + would have to: + + shorewall clear +ip addr add 130.252.100.18 dev eth0 # You need to add the addresses only if Shorewall clear +ip addr add 130.252.100.19 dev eth0 # deletes them +arping -U -c 10 -I eth0 130.252.100.18 +arping -U -c 10 -I eth0 130.252.100.19 +ip addr del 130.252.100.18 dev eth0 # You need to delete the addresses only if you added +ip addr del 130.252.100.19 dev eth0 # them above +shorewall start + + + + You can call your ISP and ask them to purge the stale ARP cache + entry but many either can't or won't purge individual entries. + + + + + There are two distinct versions of arping + available: + + + + arping by Thomas Habets (Debian package + arping). + + + + arping as part of the iputils package by + Alexey Kuznetsov (Debian package + iputils-arping). + + + + 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 diff --git a/Shorewall-docs2/ProxyARP.xml b/Shorewall-docs2/ProxyARP.xml index 2a98354cd..704bec706 100644 --- a/Shorewall-docs2/ProxyARP.xml +++ b/Shorewall-docs2/ProxyARP.xml @@ -15,7 +15,7 @@ - 2004-11-16 + 2004-12-16 2001-2004 @@ -223,8 +223,8 @@ arping -U -I eth0 66.58.99.83 # for example shorewall clear ip addr add 130.252.100.18 dev eth0 ip addr add 130.252.100.19 dev eth0 -arping -U -I eth0 130.252.100.18 -arping -U -I eth0 130.252.100.19 +arping -U -c 10 -I eth0 130.252.100.18 +arping -U -c 10 -I eth0 130.252.100.19 ip addr del 130.252.100.18 dev eth0 ip addr del 130.252.100.19 dev eth0 shorewall start @@ -236,6 +236,26 @@ shorewall start + + There are two distinct versions of arping + available: + + + + arping by Thomas Habets (Debian package + arping). + + + + arping as part of the iputils package by + Alexey Kuznetsov (Debian package + iputils-arping). + + + + 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 diff --git a/Shorewall-docs2/myfiles.xml b/Shorewall-docs2/myfiles.xml index edb9cdb0f..02e43923b 100644 --- a/Shorewall-docs2/myfiles.xml +++ b/Shorewall-docs2/myfiles.xml @@ -15,7 +15,7 @@ - 2004-11-26 + 2004-12-16 2001-2004 @@ -78,7 +78,7 @@ - I use SNAT through 206.124.146.179 for my Wife's Windows XP + I use SNAT through 206.124.146.176 for my Wife's Windows XP system Tarry, and our  dual-booting (SuSE 9.2/Windows XP) laptop Tipper which connects through the Wireless Access Point (wap) via a Wireless Bridge (wet). @@ -107,7 +107,7 @@ - The firewall runs on a 384MB K-6/II with SuSE 9.2. + The firewall runs on a P-II/233 with Debian Sarge (testing). Ursa runs Samba for file sharing with the Windows systems and is configured as a Wins server. @@ -172,8 +172,9 @@ MACLIST_LOG_LEVEL=$LOG TCP_FLAGS_LOG_LEVEL=$LOG RFC1918_LOG_LEVEL=$LOG SMURF_LOG_LEVEL= +IPTABLES= PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin -SHOREWALL_SHELL=/bin/ash +SHOREWALL_SHELL=/bin/dash SUBSYSLOCK= STATEDIR=/var/state/shorewall MODULESDIR= @@ -191,7 +192,6 @@ CLAMPMSS=Yes ROUTE_FILTER=No DETECT_DNAT_IPADDRS=Yes MUTEX_TIMEOUT=60 - NEWNOTSYN=Yes BLACKLISTNEWONLY=Yes DELAYBLACKLISTLOAD=Yes @@ -214,8 +214,8 @@ TEXAS=<ip address of gateway in Plano> OMAK=64.139.97.48 LOG=info EXT_IF=eth1 -INT_IF=eth0 -DMZ_IF=eth2 +INT_IF=eth2 +DMZ_IF=eth0 @@ -362,7 +362,7 @@ all all REJECT $LOG #INTERFACE SUBNET ADDRESS +$EXT_IF::192.168.1.1 0.0.0.0/0 192.168.1.254 -$EXT_IF:2 eth2 206.124.146.179 +$EXT_IF:2 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE @@ -579,7 +579,7 @@ DropPing net loc ############################################################################################################################################################################### # Internet to DMZ # -DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.179,206.124.146.178 +DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.178 ACCEPT net dmz tcp smtp,smtps,www,ftp,imaps,domain,https,cvspserver - ACCEPT net dmz udp domain ACCEPT net dmz udp 33434:33436 @@ -599,7 +599,6 @@ ACCEPT net loc:192.168.1.5 tcp # ICQ # ACCEPT net loc:192.168.1.5 tcp 4000:4100 -DNAT net loc:192.168.1.8 tcp 4000:4100 - 206.124.146.179 # # Real Audio # @@ -664,6 +663,49 @@ REJECT fw dmz udp ############################################################################################################################################################################### ACCEPT tx loc:192.168.1.5 all #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE + + + + +
+ /etc/network/interfaces + + This file is Debian-specific and defines the configuration of the + network interfaces. + +
+ # The loopback network interface + +auto lo +iface lo inet loopback + +# DMZ interface -- after the interface is up, add a host route to the server. This allows 'Yes' in the +# HAVEROUTE column of the /etc/shorewall/proxyarp file. Note that the DMZ interface has +# the same IP address as the Internet interface but has no broadcast address or network. + +auto eth0 +iface eth0 inet static + address 206.124.146.176 + netmask 255.255.255.255 + broadcast 0.0.0.0 + up ip route add 206.124.146.177 dev eth0 + +# Internet interface -- after the interface is up, add a host route to the DSL 'Modem' (Westell 2200). + +auto eth1 +iface eth1 inet static + address 206.124.146.176 + netmask 255.255.255.0 + gateway 206.124.146.254 + up ip route add 192.168.1.1 dev eth1 + +# Local LAN interface -- after the interface is up, add a net route to the Wireless network through 'Ursa'. + +auto eth2 +iface eth2 inet static + address 192.168.1.254 + netmask 255.255.255.0 + up ip route add 192.168.3.0/24 via 192.168.1.5