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

Update docs

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1830 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2004-12-18 17:07:38 +00:00
parent 368b397c99
commit 02e89fa699
3 changed files with 197 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

133
Shorewall-docs2/NAT.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-08-10</pubdate>
<pubdate>2004-12-16</pubdate>
<copyright>
<year>2001-2004</year>
@ -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
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
@ -70,7 +71,8 @@
<para>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
<filename>/etc/shorewall/masq</filename> or <filename>/etc/shorewall/proxyarp</filename>.</para>
<filename>/etc/shorewall/masq</filename> or
<filename>/etc/shorewall/proxyarp</filename>.</para>
<note>
<para>The <quote>ALL INTERFACES</quote> column is used to specify
@ -90,15 +92,19 @@
<para>Shorewall will automatically add the external address to the
specified interface unless you specify <ulink
url="Documentation.htm#Aliases">ADD_IP_ALIASES</ulink>=<quote>no</quote>
(or <quote>No</quote>) in <filename>/etc/shorewall/shorewall.conf</filename>;
If you do not set ADD_IP_ALIASES or if you set it to <quote>Yes</quote>
or <quote>yes</quote> then you must NOT configure your own alias(es).</para>
(or <quote>No</quote>) in
<filename>/etc/shorewall/shorewall.conf</filename>; If you do not set
ADD_IP_ALIASES or if you set it to <quote>Yes</quote> or
<quote>yes</quote> then you must NOT configure your own
alias(es).</para>
<para><important><para>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.</para></important></para>
<para><important>
<para>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.</para>
</important></para>
</note>
<note>
@ -112,4 +118,109 @@
you must have enabled CONFIG_IP_NF_NAT_LOCAL in your kernel.</para>
</note>
</section>
<section>
<title>ARP cache</title>
<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>
<orderedlist>
<listitem>
<para>A reading of <citetitle>TCP/IP Illustrated, Vol 1</citetitle> by
Stevens reveals<footnote>
<para>Courtesy of Bradey Honsinger</para>
</footnote> that a <quote>gratuitous</quote> 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...</para>
<blockquote>
<para>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.</para>
</blockquote>
<para>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 <quote>arping</quote>,
whose <quote>-U</quote> flag does just that:</para>
<programlisting>arping -U -I &lt;<emphasis>net if</emphasis>&gt; &lt;<emphasis>newly proxied IP</emphasis>&gt;
arping -U -I eth0 66.58.99.83 # for example</programlisting>
<para>Stevens goes on to mention that not all systems respond
correctly to gratuitous ARPs, but googling for <quote>arping
-U</quote> seems to support the idea that it works most of the
time.</para>
<para>To use arping with one-to-one NAT in the above example, you
would have to:</para>
<programlisting>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</programlisting>
</listitem>
<listitem>
<para>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.</para>
</listitem>
</orderedlist>
<warning>
<para>There are two distinct versions of <command>arping</command>
available:</para>
<orderedlist>
<listitem>
<para><command>arping</command> by Thomas Habets (Debian package
<emphasis>arping</emphasis>).</para>
</listitem>
<listitem>
<para><command>arping</command> as part of the iputils package by
Alexey Kuznetsov (Debian package
<emphasis>iputils-arping</emphasis>).</para>
</listitem>
</orderedlist>
<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>

26
Shorewall-docs2/ProxyARP.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-11-16</pubdate>
<pubdate>2004-12-16</pubdate>
<copyright>
<year>2001-2004</year>
@ -223,8 +223,8 @@ arping -U -I eth0 66.58.99.83 # for example</programlisting>
<programlisting>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</programlisting>
@ -236,6 +236,26 @@ shorewall start</programlisting>
</listitem>
</orderedlist>
<warning>
<para>There are two distinct versions of <command>arping</command>
available:</para>
<orderedlist>
<listitem>
<para><command>arping</command> by Thomas Habets (Debian package
<emphasis>arping</emphasis>).</para>
</listitem>
<listitem>
<para><command>arping</command> as part of the iputils package by
Alexey Kuznetsov (Debian package
<emphasis>iputils-arping</emphasis>).</para>
</listitem>
</orderedlist>
<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

62
Shorewall-docs2/myfiles.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-11-26</pubdate>
<pubdate>2004-12-16</pubdate>
<copyright>
<year>2001-2004</year>
@ -78,7 +78,7 @@
</listitem>
<listitem>
<para>I use SNAT through 206.124.146.179 for&nbsp;my Wife's Windows XP
<para>I use SNAT through 206.124.146.176 for&nbsp;my Wife's Windows XP
system <quote>Tarry</quote>, and our&nbsp; dual-booting (SuSE
9.2/Windows XP) laptop <quote>Tipper</quote> which connects through
the Wireless Access Point (wap) via a Wireless Bridge (wet).<note>
@ -107,7 +107,7 @@
</listitem>
</itemizedlist>
<para>The firewall runs on a 384MB K-6/II with SuSE 9.2.</para>
<para>The firewall runs on a P-II/233 with Debian Sarge (testing).</para>
<para>Ursa runs Samba for file sharing with the Windows systems and is
configured as a Wins server.</para>
@ -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=&lt;ip address of gateway in Plano&gt;
OMAK=64.139.97.48
LOG=info
EXT_IF=eth1
INT_IF=eth0
DMZ_IF=eth2</programlisting></para>
INT_IF=eth2
DMZ_IF=eth0</programlisting></para>
</blockquote>
</section>
@ -362,7 +362,7 @@ all all REJECT $LOG
<programlisting>#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</programlisting>
</blockquote>
</section>
@ -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
</programlisting>
</blockquote>
</section>
<section>
<title>/etc/network/interfaces</title>
<para>This file is Debian-specific and defines the configuration of the
network interfaces.</para>
<blockquote>
<programlisting># 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
</programlisting>
</blockquote>
</section>