Updates for RC1

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@429 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-02-04 15:26:02 +00:00
parent 98cab703a2
commit 0079744348
9 changed files with 6932 additions and 6552 deletions

File diff suppressed because it is too large Load Diff

View File

@ -86,8 +86,8 @@ I do?</a></p>
<p align="left"><b>6b. <a href="#faq6b">DROP messages</a></b><a
href="#faq6b"> on port 10619 are <b>flooding the logs</b> with their connect
requests. Can i exclude these error messages for this port temporarily from
logging in Shorewall?</a><br>
requests. Can i exclude these error messages for this port temporarily
from logging in Shorewall?</a><br>
</p>
<p align="left"><b>6c. </b><a href="#faq6c">All day long I get a steady flow
@ -120,8 +120,7 @@ I do?</a></p>
<p align="left"><b>14. </b><a href="#faq14">I'm connected via a cable modem
and it has an internel web server that allows me to configure/monitor
it but as expected if I enable <b> rfc1918 blocking</b> for
my eth0 interface, it also blocks the <b>cable modems web
server</b></a>.</p>
my eth0 interface, it also blocks the <b>cable modems web server</b></a>.</p>
<p align="left"><b>14a. </b><a href="#faq14a">Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC 1918 address.
@ -138,8 +137,8 @@ server</b></a>.</p>
do I find out <b>why this traffic is</b> getting <b>logged?</b></a><br>
<br>
<b>18.</b> <a href="#faq18">Is there any way to
use <b>aliased ip addresses</b> with Shorewall, and maintain separate
rulesets for different IPs?</a><br>
use <b>aliased ip addresses</b> with Shorewall, and maintain
separate rulesets for different IPs?</a><br>
<br>
<b>19. </b><a href="#faq19">I have added <b>entries
to /etc/shorewall/tcrules</b> but they <b>don't </b>seem to <b>do
@ -152,9 +151,9 @@ server. <b>Do I have to change Shorewall to allow access to my server
</b></a><b>21. </b><a href="#faq21">I see these <b>strange log
entries </b>occasionally; what are they?<br>
</a><br>
<b>22. </b><a href="#faq22">I have some <b>iptables commands </b>that
I want to <b>run when Shorewall starts.</b> Which file do I put them
in?</a><br>
<b>22. </b><a href="#faq22">I have some <b>iptables commands
</b>that I want to <b>run when Shorewall starts.</b> Which file do I
put them in?</a><br>
<br>
<b>23. </b><a href="#faq23">Why do you use such <b>ugly fonts</b>
on your <b>web site</b>?</a><br>
@ -278,7 +277,9 @@ in?</a><br>
</table>
</blockquote>
Finally,
if you need to forward a range of ports, in the PORT column specify the range
as <i>low-port</i>:<i>high-port</i>.<br>
<h4 align="left"><a name="faq1a"></a>1a. Ok -- I followed those instructions
but it doesn't work</h4>
@ -286,8 +287,8 @@ in?</a><br>
<ul>
<li>You are trying to test from inside
your firewall (no, that won't work -- see <a href="#faq2">FAQ
#2</a>).</li>
your firewall (no, that won't work -- see <a
href="#faq2">FAQ #2</a>).</li>
<li>You have a more basic problem with
your local system such as an incorrect default gateway configured
(it should be set to the IP address of your firewall's internal
@ -300,8 +301,8 @@ in?</a><br>
<b>Answer: </b>To further diagnose this problem:<br>
<ul>
<li>As root, type "iptables -t nat -Z". This clears
the NetFilter counters in the nat table.</li>
<li>As root, type "iptables -t nat -Z". This
clears the NetFilter counters in the nat table.</li>
<li>Try to connect to the redirected port from
an external host.</li>
<li>As root type "shorewall show nat"</li>
@ -318,11 +319,11 @@ being redirected to the server. In this case, the problem is usually
<ul>
<li>the connection request is not reaching your
server (possibly it is being blocked by your ISP); or</li>
<li>the connection request is not reaching
your server (possibly it is being blocked by your ISP); or</li>
<li>you are trying to connect to a secondary
IP address on your firewall and your rule is only redirecting the
primary IP address (You need to specify the secondary IP address
IP address on your firewall and your rule is only redirecting
the primary IP address (You need to specify the secondary IP address
in the "ORIG. DEST." column in your DNAT rule); or</li>
<li>your DNAT rule doesn't match the connection
request in some other way. In that case, you may have to use a
@ -345,11 +346,11 @@ problem.<br>
<ul>
<li>Having an internet-accessible server
in your local network is like raising foxes in the corner
of your hen house. If the server is compromised, there's nothing
between that server and your other internal systems. For
the cost of another NIC and a cross-over cable, you can put
your server in a DMZ such that it is isolated from your local systems
- assuming that the Server can be located near the Firewall,
of your hen house. If the server is compromised, there's
nothing between that server and your other internal systems.
For the cost of another NIC and a cross-over cable, you can put
your server in a DMZ such that it is isolated from your local
systems - assuming that the Server can be located near the Firewall,
of course :-)</li>
<li>The accessibility problem is best
solved using <a href="shorewall_setup_guide.htm#DNS">Bind Version
@ -472,12 +473,12 @@ each other using their DNS names.</h4>
name.</p>
<p align="left">Another good way to approach this problem is to switch from
static NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918
addresses and can be accessed externally and internally using
the same address. </p>
static NAT to Proxy ARP. That way, the hosts in Z have
non-RFC1918 addresses and can be accessed externally and
internally using the same address. </p>
<p align="left">If you don't like those solutions and prefer routing all
Z-&gt;Z traffic through your firewall then:</p>
<p align="left">If you don't like those solutions and prefer routing all Z-&gt;Z
traffic through your firewall then:</p>
<p align="left">a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces
(If you are running a Shorewall version earlier than 1.3.9).<br>
@ -554,7 +555,8 @@ Z-&gt;Z traffic through your firewall then:</p>
id="AutoNumber3" width="369">
<tbody>
<tr>
<td width="93"><u><b>INTERFACE </b></u></td>
<td width="93"><u><b>INTERFACE
</b></u></td>
<td width="31"><u><b>SUBNET</b></u></td>
<td width="120"><u><b>ADDRESS</b></u></td>
</tr>
@ -578,16 +580,18 @@ Z-&gt;Z traffic through your firewall then:</p>
<p align="left"><b>Answer: </b>There is an <a
href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection
tracking/NAT module</a> that may help with Netmeeting. Look
<a href="http://linux-igd.sourceforge.net">here</a> for a solution for
MSN IM but be aware that there are significant security risks involved
with this solution. Also check the Netfilter mailing list archives
<a href="http://linux-igd.sourceforge.net">here</a> for a solution for MSN
IM but be aware that there are significant security risks involved with
this solution. Also check the Netfilter mailing list archives
at <a href="http://www.netfilter.org">http://www.netfilter.org</a>.
</p>
<h4 align="left"><a name="faq4"></a>4. I just used an online port scanner
to check my firewall and it shows some ports as 'closed'
rather than 'blocked'. Why?</h4>
<p align="left"><b>Answer: </b>The common.def included with version 1.3.x
always rejects connection requests on TCP port 113 rather
than dropping them. This is necessary to prevent outgoing
@ -599,17 +603,20 @@ ports that are used by Windows (Windows <u>can</u> be configured
requests rather than dropping them cuts down slightly on the amount
of Windows chatter on LAN segments connected to the Firewall. </p>
<p align="left">If you are seeing port 80 being 'closed', that's probably
your ISP preventing you from running a web server in
violation of your Service Agreement.</p>
your ISP preventing you from running a web server in violation
of your Service Agreement.</p>
<h4 align="left"><a name="faq4a"></a>4a. I just ran an nmap UDP scan of my
firewall and it showed 100s of ports as open!!!!</h4>
<p align="left"><b>Answer: </b>Take a deep breath and read the nmap man page
section about UDP scans. If nmap gets <b>nothing</b>
back from your firewall then it reports the port as open.
If you want to see which UDP ports are really open, temporarily
section about UDP scans. If nmap gets <b>nothing</b> back
from your firewall then it reports the port as open. If
you want to see which UDP ports are really open, temporarily
change your net-&gt;all policy to REJECT, restart Shorewall and
do the nmap UDP scan again.</p>
@ -636,11 +643,11 @@ do the nmap UDP scan again.</p>
<h4 align="left"><a name="faq6"></a>6. Where are the log messages written
and how do I change the destination?</h4>
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of
syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern)
facility (see "man openlog") and you get to choose the log level (again,
see "man syslog") in your <a href="Documentation.htm#Policy">policies</a>
and <a href="Documentation.htm#Rules">rules</a>. The destination for messaged
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of syslog
(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility
(see "man openlog") and you get to choose the log level (again, see "man
syslog") in your <a href="Documentation.htm#Policy">policies</a> and <a
href="Documentation.htm#Rules">rules</a>. The destination for messaged
logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
When you have changed /etc/syslog.conf, be sure to restart
syslogd (on a RedHat system, "service syslog restart"). </p>
@ -678,8 +685,8 @@ from my various systems with each report summarizing the logged activity
on the corresponding system.
<h4 align="left"><b><a name="faq6b"></a>6b. DROP messages</b> on port 10619
are <b>flooding the logs</b> with their connect requests. Can i exclude these
error messages for this port temporarily from logging in Shorewall?</h4>
are <b>flooding the logs</b> with their connect requests. Can i exclude
these error messages for this port temporarily from logging in Shorewall?</h4>
Temporarily add the following rule:<br>
<pre> DROP    net    fw    udp    10619</pre>
@ -697,9 +704,9 @@ from my various systems with each report summarizing the logged activity
</ol>
You can distinguish the difference by setting the <b>logunclean</b> option
(<a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>) on
your external interface (eth0 in the above example). If they get logged twice,
they are corrupted. I solve this problem by using an /etc/shorewall/common
(<a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>)
on your external interface (eth0 in the above example). If they get logged
twice, they are corrupted. I solve this problem by using an /etc/shorewall/common
file like this:<br>
<blockquote>
@ -743,6 +750,7 @@ from my various systems with each report summarizing the logged activity
<h4 align="left"><a name="faq9"></a>9. Why can't Shorewall detect my interfaces
properly?</h4>
<p align="left">I just installed Shorewall and when I issue the start command,
I see the following:</p>
@ -755,37 +763,42 @@ from my various systems with each report summarizing the logged activity
</div>
<div align="left">
<p align="left"><b>Answer: </b>The above output is perfectly normal. The
Net zone is defined as all hosts that are connected through eth0 and the
local zone is defined as all hosts connected through eth1</p>
<p align="left"><b>Answer: </b>The above output is perfectly normal. The Net
zone is defined as all hosts that are connected through eth0 and the local
zone is defined as all hosts connected through eth1</p>
</div>
<h4 align="left"><a name="faq10"></a>10. What Distributions does it work
with?</h4>
<p align="left">Shorewall works with any GNU/Linux distribution that includes
the <a href="shorewall_prerequisites.htm">proper prerequisites</a>.</p>
<h4 align="left">11. What Features does it have?</h4>
<p align="left"><b>Answer: </b>See the <a href="shorewall_features.htm">Shorewall
Feature List</a>.</p>
<h4 align="left"><a name="faq12"></a>12. Why isn't there a GUI?</h4>
<p align="left"><b>Answer: </b>Every time I've started to work on one, I
find myself doing other things. I guess I just don't care enough if
Shorewall has a GUI to invest the effort to create one myself. There
are several Shorewall GUI projects underway however and I will publish
links to them when the authors feel that they are ready. </p>
<p align="left"><b>Answer: </b>Every time I've started to work on one, I find
myself doing other things. I guess I just don't care enough if Shorewall
has a GUI to invest the effort to create one myself. There are several
Shorewall GUI projects underway however and I will publish links to
them when the authors feel that they are ready. </p>
<h4 align="left"> <a name="faq13"></a>13. Why do you call it "Shorewall"?</h4>
<p align="left"><b>Answer: </b>Shorewall is a concatenation of "<u>Shore</u>line"
(<a href="http://www.cityofshoreline.com">the city
where I live</a>) and "Fire<u>wall</u>". The full name of
the product is actually "Shoreline Firewall" but "Shorewall" is must
more commonly used.</p>
(<a href="http://www.cityofshoreline.com">the city where
I live</a>) and "Fire<u>wall</u>". The full name of the product
is actually "Shoreline Firewall" but "Shorewall" is must more commonly
used.</p>
<h4 align="left"> <a name="faq14"></a>14. I'm connected via a cable modem
and it has an internal web server that allows me to configure/monitor
@ -793,14 +806,14 @@ more commonly used.</p>
interface (the internet one), it also blocks the cable modems
web server.</h4>
<p align="left">Is there any way it can add a rule before the rfc1918 blocking
that will let all traffic to and from the 192.168.100.1
address of the modem in/out but still block all other rfc1918
addresses?</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall
earlier than 1.3.1, create /etc/shorewall/start and in it, place the
following:</p>
<p align="left">Is there any way it can add a rule before the rfc1918 blocking
that will let all traffic to and from the 192.168.100.1 address
of the modem in/out but still block all other rfc1918 addresses?</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall earlier
than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<div align="left">
<pre> run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</pre>
@ -877,10 +890,10 @@ following:</p>
</div>
<div align="left">
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable
RFC 1918 filtering on my external interface, my DHCP client cannot renew
its lease.</h4>
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public IP
addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC
1918 filtering on my external interface, my DHCP client cannot renew its
lease.</h4>
</div>
<div align="left">
@ -923,6 +936,7 @@ its lease.</h4>
<h4 align="left"><a name="faq16"></a>16. Shorewall is writing log messages
all over my console making it unusable!</h4>
<p align="left"><b>Answer: </b>"man dmesg" -- add a suitable 'dmesg' command
to your startup scripts or place it in /etc/shorewall/start.
Under RedHat, the max log level that is sent to the console
@ -938,8 +952,8 @@ its lease.</h4>
<li><b>man1918 - </b>The destination address
is listed in /etc/shorewall/rfc1918 with a <b>logdrop </b>target
-- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>rfc1918</b> - The source address is
listed in /etc/shorewall/rfc1918 with a <b>logdrop </b>target
<li><b>rfc1918</b> - The source address
is listed in /etc/shorewall/rfc1918 with a <b>logdrop </b>target
-- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>all2&lt;zone&gt;</b>, <b>&lt;zone&gt;2all</b>
or <b>all2all </b>- You have a<a
@ -958,14 +972,13 @@ that includes a log level.</li>
being logged under the <b>maclist</b> <a
href="Documentation.htm#Interfaces">interface option</a>.<br>
</li>
<li><b>logpkt</b> - The packet is being logged
under the <b>logunclean</b> <a
<li><b>logpkt</b> - The packet is being
logged under the <b>logunclean</b> <a
href="Documentation.htm#Interfaces">interface option</a>.</li>
<li><b>badpkt </b>- The packet is being logged
under the <b>dropunclean</b> <a
<li><b>badpkt </b>- The packet is being
logged under the <b>dropunclean</b> <a
href="Documentation.htm#Interfaces">interface option</a> as specified
in the <b>LOGUNCLEAN </b>setting in <a
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
in the <b>LOGUNCLEAN </b>setting in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
<li><b>blacklst</b> - The packet is being
logged because the source IP is blacklisted in the<a
href="Documentation.htm#Blacklist"> /etc/shorewall/blacklist </a>file.</li>
@ -974,9 +987,9 @@ logged because the source IP is blacklisted in the<a
connection yet it is not a syn packet. Options affecting the logging
of such packets include <b>NEWNOTSYN </b>and <b>LOGNEWNOTSYN
</b>in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
<li><b>INPUT</b> or <b>FORWARD</b> - The packet
has a source IP address that isn't in any of your defined zones
("shorewall check" and look at the printed zone definitions)
<li><b>INPUT</b> or <b>FORWARD</b> - The
packet has a source IP address that isn't in any of your defined
zones ("shorewall check" and look at the printed zone definitions)
or the chain is FORWARD and the destination IP isn't in any of your
defined zones.</li>
<li><b>logflags </b>- The packet is being logged because
@ -990,14 +1003,15 @@ defined zones.</li>
with Shorewall, and maintain separate rulesets for different
IPs?</h4>
<b>Answer: </b>Yes. You simply use the IP address
in your rules (or if you use NAT, use the local IP address in your
rules). <b>Note:</b> The ":n" notation (e.g., eth0:0) is deprecated
in your rules (or if you use NAT, use the local IP address in
your rules). <b>Note:</b> The ":n" notation (e.g., eth0:0) is deprecated
and will disappear eventually. Neither iproute (ip and tc) nor
iptables supports that notation so neither does Shorewall. <br>
<br>
<b>Example 1:</b><br>
<br>
/etc/shorewall/rules
<pre wrap=""><span class="moz-txt-citetags"></span> # Accept AUTH but only on address 192.0.2.125<br><span
class="moz-txt-citetags"></span><br><span class="moz-txt-citetags"></span> ACCEPT net fw:192.0.2.125 tcp auth<br><span
class="moz-txt-citetags"></span></pre>
@ -1009,6 +1023,7 @@ IPs?</h4>
<pre wrap=""><span class="moz-txt-citetags"></span><span
class="moz-txt-citetags"></span> 192.0.2.126 eth0 10.1.1.126</pre>
/etc/shorewall/rules
<pre wrap=""><span class="moz-txt-citetags"></span> # Accept HTTP on 192.0.2.126 (a.k.a. 10.1.1.126)<br><span
class="moz-txt-citetags"></span><br> <span class="moz-txt-citetags"></span>ACCEPT net loc:10.1.1.126 tcp www<span
class="moz-txt-citetags"></span><br></pre>
@ -1025,9 +1040,9 @@ IPs?</h4>
to change Shorewall to allow access to my server from the internet?</b><br>
</h4>
Yes. Consult the <a
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that you
used during your initial setup for information about how to set up
rules for your server.<br>
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that
you used during your initial setup for information about how to set
up rules for your server.<br>
<h4><a name="faq21"></a><b>21. </b>I see these <b>strange log entries </b>occasionally;
what are they?<br>
@ -1043,8 +1058,8 @@ is my internal LAN<br>
Control Message Protocol (ICMP) with 'ping', ICMP is a key piece
of the internet. ICMP is used to report problems back to the sender
of a packet; this is what is happening here. Unfortunately, where NAT
is involved (including SNAT, DNAT and Masquerade), there are a lot
of broken implementations. That is what you are seeing with these messages.<br>
is involved (including SNAT, DNAT and Masquerade), there are a lot of
broken implementations. That is what you are seeing with these messages.<br>
<br>
Here is my interpretation of what is happening -- to confirm
this analysis, one would have to have packet sniffers placed a both
@ -1054,27 +1069,27 @@ of broken implementations. That is what you are seeing with these messages.
a UDP DNS query to 192.0.2.3 and your DNS server tried to send a
response (the response information is in the brackets -- note source
port 53 which marks this as a DNS reply). When the response was returned
to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10
and forwarded the packet to 172.16.1.10 who no longer had a connection
on UDP port 2857. This causes a port unreachable (type 3, code 3) to
be generated back to 192.0.2.3. As this packet is sent back through 206.124.146.179,
to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10 and
forwarded the packet to 172.16.1.10 who no longer had a connection on
UDP port 2857. This causes a port unreachable (type 3, code 3) to be
generated back to 192.0.2.3. As this packet is sent back through 206.124.146.179,
that box correctly changes the source address in the packet to 206.124.146.179
but doesn't reset the DST IP in the original DNS response similarly.
When the ICMP reaches your firewall (192.0.2.3), your firewall has
no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't
When the ICMP reaches your firewall (192.0.2.3), your firewall has no
record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't
appear to be related to anything that was sent. The final result is
that the packet gets logged and dropped in the all2all chain. I have also
seen cases where the source IP in the ICMP itself isn't set back to the
external IP of the remote NAT gateway; that causes your firewall to log
and drop the packet out of the rfc1918 chain because the source IP is
reserved by RFC 1918.<br>
and drop the packet out of the rfc1918 chain because the source IP is reserved
by RFC 1918.<br>
<h4><a name="faq22"></a><b>22. </b>I have some <b>iptables commands </b>that
I want to <b>run when Shorewall starts.</b> Which file do I put them
in?</h4>
You can place these commands in one of the <a
href="shorewall_extension_scripts.htm">Shorewall Extension Scripts</a>. Be
sure that you look at the contents of the chain(s) that you will be modifying
href="shorewall_extension_scripts.htm">Shorewall Extension Scripts</a>.
Be sure that you look at the contents of the chain(s) that you will be modifying
with your commands to be sure that the commands will do what they are
intended. Many iptables commands published in HOWTOs and other instructional
material use the -A command which adds the rules to the end of the chain.
@ -1085,9 +1100,9 @@ Check "man iptables" and look at the -I (--insert) command.<br>
<h4><a name="faq23"></a><b>23. </b>Why do you use such ugly fonts on your
web site?</h4>
The Shorewall web site is almost font neutral (it doesn't explicitly
specify fonts except on a few pages) so the fonts you see are largely the
default fonts configured in your browser. If you don't like them then reconfigure
your browser.<br>
specify fonts except on a few pages) so the fonts you see are largely
the default fonts configured in your browser. If you don't like them then
reconfigure your browser.<br>
<h4><a name="faq24"></a>24. How can I <b>allow conections</b> to let's say
the ssh port only<b> from specific IP Addresses</b> on the internet?</h4>
@ -1099,17 +1114,19 @@ Check "man iptables" and look at the -I (--insert) command.<br>
<pre> ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22<br></pre>
<div align="left"> </div>
<font size="2">Last updated 1/30/2003 - <a
<font size="2">Last updated 2/3/2003 - <a
href="support.htm">Tom Eastep</a></font>
<p><a href="copyright.htm"><font size="2">Copyright</font> ©
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<p><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

File diff suppressed because it is too large Load Diff

281
Shorewall-docs/OPENVPN.html Executable file
View File

@ -0,0 +1,281 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>GRE/IPIP Tunnels</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">OpenVPN Tunnels</font></h1>
</td>
</tr>
</tbody>
</table>
<h3><br>
</h3>
<p>OpenVPN is a robust and highly configurable VPN (Virtual Private Network)
daemon which can be used to securely link two or more private networks using
an encrypted tunnel over the internet. OpenVPN is an Open Source project and
is <a href="http://openvpn.sourceforge.net/license.html">licensed under the
GPL</a>. OpenVPN can be downloaded from <a
href="http://openvpn.sourceforge.net/">http://openvpn.sourceforge.net/</a>.<br>
</p>
<p>OpenVPN support was added to Shorewall in version 1.3.14.<br>
</p>
<h2>Bridging two Masqueraded Networks</h2>
<p>Suppose that we have the following situation:</p>
<p align="center"><img border="0" src="images/TwoNets1.png" width="745"
height="427">
</p>
<p align="left">We want systems in the 192.168.1.0/24 subnetwork to be able
to communicate with the systems in the 10.0.0.0/8 network. This is accomplished
through use of the /etc/shorewall/tunnels file and the /etc/shorewall/policy
file and OpenVPN.</p>
<p align="left">While it was possible to use the Shorewall start and stop
script to start and stop OpenVPN, I decided to use the init script of OpenVPN
to start and stop it.</p>
<p align="left">On each firewall, you will need to declare a zone to represent
the remote subnet. We'll assume that this zone is called 'vpn' and declare
it in /etc/shorewall/zones on both systems as follows.</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>ZONE</strong></td>
<td><strong>DISPLAY</strong></td>
<td><strong>COMMENTS</strong></td>
</tr>
<tr>
<td>vpn</td>
<td>VPN</td>
<td>Remote Subnet</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">On system A, the 10.0.0.0/8 will comprise the <b>vpn</b> zone.
In /etc/shorewall/interfaces:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ZONE</b></td>
<td><b>INTERFACE</b></td>
<td><b>BROADCAST</b></td>
<td><b>OPTIONS</b></td>
</tr>
<tr>
<td>vpn</td>
<td>tun0</td>
<td><br>
</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">In /etc/shorewall/tunnels on system A, we need the following:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>openvpn</td>
<td>net</td>
<td>134.28.54.2</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>This entry in /etc/shorewall/tunnels opens the firewall so that OpenVPN
traffic on the default port 5000/udp will be accepted to/from the remote gateway.
If you change the port used by OpenVPN to 7777, you can define /etc/shorewall/tunnels
like this:<br>
</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>openvpn:7777</td>
<td>net</td>
<td>134.28.54.2</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>This is the OpenVPN config on system A:</p>
<blockquote>
<p></p>
</blockquote>
<blockquote>
<p>dev tun<br>
local 206.162.148.9<br>
remote 134.28.54.2<br>
ifconfig 192.168.99.1 192.168.99.2<br>
up ./route-a.up<br>
tls-server<br>
dh dh1024.pem<br>
ca ca.crt<br>
cert my-a.crt<br>
key my-a.key<br>
comp-lzo<br>
verb 5<br>
</p>
</blockquote>
<p>Similarly, On system B the 192.168.1.0/24 subnet will comprise the <b>vpn</b>
zone. In /etc/shorewall/interfaces:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ZONE</b></td>
<td><b>INTERFACE</b></td>
<td><b>BROADCAST</b></td>
<td><b>OPTIONS</b></td>
</tr>
<tr>
<td>vpn</td>
<td>tun0</td>
<td>192.168.1.255</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>In /etc/shorewall/tunnels on system B, we have:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>openvpn</td>
<td>net</td>
<td>206.191.148.9</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>And in the OpenVPN config on system B:</p>
<blockquote>
<p>dev tun<br>
local 134.28.54.2<br>
remote 206.162.148.9<br>
ifconfig 192.168.99.2 192.168.99.1<br>
up ./route-b.up<br>
tls-client<br>
ca ca.crt<br>
cert my-b.crt<br>
key my-b.key<br>
comp-lzo<br>
verb 5<br>
</p>
</blockquote>
<p align="left">You will need to allow traffic between the "vpn" zone and
the "loc" zone on both systems -- if you simply want to admit all traffic
in both directions, you can use the policy file:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>SOURCE</strong></td>
<td><strong>DEST</strong></td>
<td><strong>POLICY</strong></td>
<td><strong>LOG LEVEL</strong></td>
</tr>
<tr>
<td>loc</td>
<td>vpn</td>
<td>ACCEPT</td>
<td> </td>
</tr>
<tr>
<td>vpn</td>
<td>loc</td>
<td>ACCEPT</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>On both systems, restart Shorewall and start OpenVPN. The systems in the
two masqueraded subnetworks can now talk to each other.</p>
<p><font size="2">Updated 2/4/2003 - <a href="support.htm">Tom Eastep</a></font>
<small>and Simon Mater</small><br>
</p>
<p><font size="2"> </font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2003 Thomas M. Eastep. and Simon Mater<br>
</font></a></font></p>
<br>
<br>
</body>
</html>

View File

@ -79,6 +79,7 @@ Powered by Postfix
<h2>A Word about SPAM Filters <a href="http://ordb.org"></a><a
href="http://osirusoft.com/"> </a></h2>
<p>Before subscribing please read my <a href="spam_filters.htm">policy
about list traffic that bounces.</a> Also please note that the mail server
at shorewall.net checks incoming mail:<br>
@ -105,11 +106,12 @@ is a valid fully-qualified DNS name that resolves.</li>
I think that blocking all HTML is a Draconian way to control spam
and that the ultimate losers here are not the spammers but the list subscribers
whose MTAs are bouncing all shorewall.net mail. As one list subscriber
wrote to me privately "These e-mail admin's need to get a <i>(explitive deleted)</i>
life instead of trying to rid the planet of HTML based e-mail". Nevertheless,
to allow subscribers to receive list posts as must as possible, I have now
configured the list server at shorewall.net to strip all HTML from outgoing
posts. This means that HTML-only posts will be bounced by the list server.<br>
wrote to me privately "These e-mail admin's need to get a <i>(explitive
deleted)</i> life instead of trying to rid the planet of HTML based e-mail".
Nevertheless, to allow subscribers to receive list posts as must as possible,
I have now configured the list server at shorewall.net to strip all HTML
from outgoing posts. This means that HTML-only posts will be bounced by
the list server.<br>
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.<br>
</p>
@ -133,6 +135,7 @@ help but I'm not prepared to go so far as to start stripping <i>Received:</i>
<option value="boolean">Boolean </option>
</select>
Format:
<select name="format">
<option value="builtin-long">Long </option>
<option value="builtin-short">Short </option>
@ -155,29 +158,30 @@ help but I'm not prepared to go so far as to start stripping <i>Received:</i>
value=""> <input type="submit" value="Search"> </p>
</form>
<h2 align="left"><font color="#ff0000">Please do not try to download the
entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply
won't stand the traffic. If I catch you, you will be blacklisted.<br>
<h2 align="left"><font color="#ff0000">Please do not try to download the entire
Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't
stand the traffic. If I catch you, you will be blacklisted.<br>
</font></h2>
<h2 align="left">Shorewall CA Certificate</h2>
If you want to trust X.509 certificates issued by Shoreline
Firewall (such as the one used on my web site), you may <a
href="Shorewall_CA_html.html">download and install my CA certificate</a>
in your browser. If you don't wish to trust my certificates then you
can either use unencrypted access when subscribing to Shorewall mailing
lists or you can use secure access (SSL) and accept the server's certificate
when prompted by your browser.<br>
in your browser. If you don't wish to trust my certificates then
you can either use unencrypted access when subscribing to Shorewall
mailing lists or you can use secure access (SSL) and accept the server's
certificate when prompted by your browser.<br>
<h2 align="left">Shorewall Users Mailing List</h2>
<p align="left">The Shorewall Users Mailing list provides a way for users
to get answers to questions and to report problems. Information of
general interest to the Shorewall user community is also posted to
this list.</p>
to get answers to questions and to report problems. Information
of general interest to the Shorewall user community is also posted
to this list.</p>
<p align="left"><b>Before posting a problem report to this list, please see
the <a href="support.htm">problem reporting guidelines</a>.</b></p>
the <a href="http://www.shorewall.net/support.htm">problem reporting
guidelines</a>.</b></p>
<p align="left">To subscribe to the mailing list:<br>
</p>
@ -197,9 +201,9 @@ this list.</p>
<p align="left">The list archives are at <a
href="http://lists.shorewall.net/pipermail/shorewall-users/index.html">http://lists.shorewall.net/pipermail/shorewall-users</a>.</p>
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted at
<a href="http://sourceforge.net">Sourceforge</a>. The archives from that list
may be found at <a
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted
at <a href="http://sourceforge.net">Sourceforge</a>. The archives from that
list may be found at <a
href="http://www.geocrawler.com/lists/3/Sourceforge/9327/0/">www.geocrawler.com/lists/3/Sourceforge/9327/0/</a>.</p>
<h2 align="left">Shorewall Announce Mailing List</h2>
@ -283,11 +287,11 @@ to you.</p>
<p align="left"><a href="gnu_mailman.htm">Check out these instructions</a></p>
<p align="left"><font size="2">Last updated 1/14/2003 - <a
<p align="left"><font size="2">Last updated 2/3/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font> ©
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
@ -297,5 +301,6 @@ to you.</p>
<br>
<br>
<br>
<br>
</body>
</html>

View File

@ -108,9 +108,9 @@ easy"</i></font></font></h1>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables) based
firewall that can be used on a dedicated firewall system, a multi-function
<p>The Shoreline Firewall, more commonly known as "Shorewall", is a
<a href="http://www.netfilter.org">Netfilter</a> (iptables) based firewall
that can be used on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
@ -124,8 +124,8 @@ firewall that can be used on a dedicated firewall system, a multi-functio
<p>This program is free software; you can redistribute it and/or modify
it under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
General Public License</a> as published by the Free Software Foundation.<br>
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU General
Public License</a> as published by the Free Software Foundation.<br>
<br>
@ -138,9 +138,10 @@ GNU General Public License for more details.<br>
<br>
You should have received a copy of the
GNU General Public License along with this
program; if not, write to the Free Software Foundation,
Inc., 675 Mass Ave, Cambridge, MA 02139, USA</p>
GNU General Public License along with
this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
USA</p>
@ -176,15 +177,15 @@ GNU General Public License for more details.<br>
<p><b>Congratulations to Jacques and Eric on the recent release of
Bering 1.0 Final!!! </b><br>
<p><b>Congratulations to Jacques and Eric on the recent release of Bering
1.0 Final!!! </b><br>
</p>
<h2>This is a mirror of the main Shorewall web site at SourceForge
(<a href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>)</h2>
<h2>This is a mirror of the main Shorewall web site at SourceForge (<a
href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>)</h2>
@ -217,6 +218,19 @@ Bering 1.0 Final!!! </b><br>
<p><b>2/4/2003 - Shorewall 1.3.14-RC1</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>Includes the Beta 2 content plus support for OpenVPN tunnels.</p>
<p> The beta may be downloaded from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>1/28/2003 - Shorewall 1.3.14-Beta2 </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
@ -243,10 +257,10 @@ form $dev.$vid (e.g., eth0.1)</p>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
When set to Yes, Shorewall ping handling is as it has always been (see http://www.shorewall.net/ping.html).<br>
<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and policies
just like any other connection request. The FORWARDPING=Yes option in shorewall.conf
and the 'noping' and 'filterping' options in /etc/shorewall/interfaces will
all generate an error.<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
policies just like any other connection request. The FORWARDPING=Yes option
in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/interfaces
will all generate an error.<br>
<br>
</li>
<li>It is now possible to direct Shorewall to create a "label"
@ -257,8 +271,8 @@ just the interface name:<br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
   b) In the INTERFACE column of /etc/shorewall/nat<br>
 </li>
<li>When an interface name is entered in the SUBNET column of the
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
<li>When an interface name is entered in the SUBNET column of
the /etc/shorewall/masq file, Shorewall previously masqueraded traffic from
only the first subnet defined on that interface. It did not masquerade traffic
from:<br>
 <br>
@ -278,12 +292,12 @@ the masquerading/SNAT rules.<br>
<pre>  [root@gateway test]# shorewall start<br> ...<br> Masqueraded Subnets and Hosts:<br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br> Processing /etc/shorewall/tos... <br></pre>
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
connected to an interface that is specified in the SUBNET column of an /etc/shorewall/masq
entry, your /etc/shorewall/masq file will need changing. In most cases, you
will simply be able to remove redundant entries. In some cases though, you
might want to change from using the interface name to listing specific subnetworks
if the change described above will cause masquerading to occur on subnetworks
that you don't wish to masquerade.<br>
connected to an interface that is specified in the SUBNET column of an
/etc/shorewall/masq entry, your /etc/shorewall/masq file will need changing.
In most cases, you will simply be able to remove redundant entries. In some
cases though, you might want to change from using the interface name to
listing specific subnetworks if the change described above will cause masquerading
to occur on subnetworks that you don't wish to masquerade.<br>
 <br>
Example 2 -- Suppose that your current config is as follows:<br>
@ -314,6 +328,7 @@ required.<br>
<p><b>1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13
documenation. the PDF may be downloaded from</p>
    <a
@ -325,9 +340,9 @@ required.<br>
<p><b>1/17/2003 - shorewall.net has MOVED</b><b></b></p>
<p>Thanks to the generosity of Alex Martin and <a
href="http://www.rettc.com">Rett Consulting</a>, www.shorewall.net and ftp.shorewall.net
are now hosted on a system in Bellevue, Washington. A big thanks to Alex
for making this happen.<br>
href="http://www.rettc.com">Rett Consulting</a>, www.shorewall.net and
ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A
big thanks to Alex for making this happen.<br>
</p>
<p><b>1/13/2003 - Shorewall 1.3.13</b><br>
@ -356,8 +371,8 @@ to minimize the number of rules that connection requests must traverse.<br>
<br>
         ACCEPT net  dmz:206.124.146.177 tcp smtp<br>
<br>
   By writing the rules this way, I end up with only one copy of the
ACCEPT rule.<br>
   By writing the rules this way, I end up with only one copy of
the ACCEPT rule.<br>
<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179<br>
@ -372,10 +387,10 @@ to minimize the number of rules that connection requests must traverse.<br>
If this option is set to 'No' then Shorewall won't clear the current traffic
control rules during [re]start. This setting is intended for use by people
that prefer to configure traffic shaping when the network interfaces come
up rather than when the firewall is started. If that is what you want
to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart
file. That way, your traffic shaping rules can still use the 'fwmark'
classifier based on packet marking defined in /etc/shorewall/tcrules.<br>
up rather than when the firewall is started. If that is what you want to
do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart
file. That way, your traffic shaping rules can still use the 'fwmark' classifier
based on packet marking defined in /etc/shorewall/tcrules.<br>
<br>
</li>
<li>A new SHARED_DIR variable has been added that allows distribution
@ -426,32 +441,33 @@ classifier based on packet marking defined in /etc/shorewall/tcrules.<br>
<li>"shorewall refresh" now reloads the traffic shaping
rules (tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging
after an error occurs. This places the point of the failure near the
end of the trace rather than up in the middle of it.</li>
after an error occurs. This places the point of the failure near
the end of the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more
than 40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been
added which shows the current packet classification filters. The output
from this command is also added as a separate page in "shorewall monitor"</li>
added which shows the current packet classification filters. The
output from this command is also added as a separate page in "shorewall
monitor"</li>
<li>ULOG (must be all caps) is now accepted as a valid
syslog level and causes the subject packets to be logged using the
ULOG target rather than the LOG target. This allows you to run ulogd
(available from <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to
a separate log file</a>.</li>
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD
chain in the mangle table ("shorewall show mangle" will show you
the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes
in <a href="Documentation.htm#Conf">shorewall.conf</a>. This allows for
marking input packets based on their destination even when you are
using Masquerading or SNAT.</li>
in <a href="Documentation.htm#Conf">shorewall.conf</a>. This allows for marking
input packets based on their destination even when you are using
Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory
with empty 'init', 'start', 'stop' and 'stopped' files. If you already
have a file with one of these names, don't worry -- the upgrade process
won't overwrite your file.</li>
<li>I have added a new RFC1918_LOG_LEVEL variable to
<a href="Documentation.htm#Conf">shorewall.conf</a>. This variable
<li>I have added a new RFC1918_LOG_LEVEL variable
to <a href="Documentation.htm#Conf">shorewall.conf</a>. This variable
specifies the syslog level at which packets are logged as a result
of entries in the /etc/shorewall/rfc1918 file. Previously, these packets
were always logged at the 'info' level.<br>
@ -481,8 +497,9 @@ Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b><b>
</b></p>
The first public Beta version of Shorewall 1.3.12 is now
available (Beta 1 was made available to a limited audience). <br>
The first public Beta version of Shorewall 1.3.12 is
now available (Beta 1 was made available to a limited audience).
<br>
<br>
Features include:<br>
<br>
@ -499,20 +516,20 @@ near the end of the trace rather than up in the middle of it.</li>
by more than 40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has
been added which shows the current packet classification filters.
The output from this command is also added as a separate page in "shorewall
monitor"</li>
The output from this command is also added as a separate page in
"shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted as
a valid syslog level and causes the subject packets to be logged using
the ULOG target rather than the LOG target. This allows you to run ulogd
(available from <a
a valid syslog level and causes the subject packets to be logged
using the ULOG target rather than the LOG target. This allows you to
run ulogd (available from <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to
a separate log file</a>.</li>
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD
chain in the mangle table ("shorewall show mangle" will show you the
chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes
in shorewall.conf. This allows for marking input packets based on their
destination even when you are using Masquerading or SNAT.</li>
chain in the mangle table ("shorewall show mangle" will show you
the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes
in shorewall.conf. This allows for marking input packets based on
their destination even when you are using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory
with empty 'init', 'start', 'stop' and 'stopped' files. If you already
have a file with one of these names, don't worry -- the upgrade process
@ -567,6 +584,7 @@ now in a position to support Shorewall users who run Mandrake 9.0.</p>
<p><b>12/3/2002 - Shorewall 1.3.11a</b><b>
</b></p>
@ -615,11 +633,11 @@ now in a position to support Shorewall users who run Mandrake 9.0.</p>
to entries in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
This option causes Shorewall to make a set of sanity check on TCP
packet header flags.</li>
<li>It is now allowed to use 'all' in
the SOURCE or DEST column in a <a
href="Documentation.htm#Rules">rule</a>. When used, 'all' must
appear by itself (in may not be qualified) and it does not enable
intra-zone traffic. For example, the rule <br>
<li>It is now allowed to use 'all'
in the SOURCE or DEST column in a <a
href="Documentation.htm#Rules">rule</a>. When used, 'all' must appear
by itself (in may not be qualified) and it does not enable intra-zone
traffic. For example, the rule <br>
<br>
    ACCEPT loc all tcp 80<br>
<br>
@ -708,11 +726,11 @@ ignored</li>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
<p align="center"><font size="4" color="#ffffff">Shorewall is free but
if you try it and find it useful, please consider making a donation
to <a
href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
Foundation.</font></a> Thanks!</font></p>
</td>
@ -728,10 +746,11 @@ Children's Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 1/28/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/4/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
</body>
</html>

View File

@ -44,10 +44,10 @@
</ul>
</li>
<li> <a href="shorewall_quickstart_guide.htm">QuickStart Guides</a>
<li> <a href="shorewall_quickstart_guide.htm">QuickStart Guides (HOWTOs)</a>
to help get your first firewall up and running quickly</li>
<li>Extensive <b> <a
href="shorewall_quickstart_guide.htm#Documentation" target="_top">documentation</a>
href="shorewall_quickstart_guide.htm#Documentation">documentation</a>
</b> included in the .tgz and .rpm downloads.</li>
<li><b>Flexible address management/routing support</b> (and you can
use all types in the same firewall):

View File

@ -34,8 +34,8 @@
</tbody>
</table>
<p align="center">With thanks to Richard who reminded me once again that
we must all first walk before we can run.<br>
<p align="center">With thanks to Richard who reminded me once again that we
must all first walk before we can run.<br>
The French Translations are courtesy of Patrice Vetsel<br>
</p>
@ -69,8 +69,8 @@ and a DMZ. (<a href="three-interface_fr.html">Version Fran
<ul>
<li><a href="shorewall_setup_guide.htm#Introduction">1.0
Introduction</a></li>
<li><a href="shorewall_setup_guide.htm#Concepts">2.0 Shorewall
Concepts</a></li>
<li><a href="shorewall_setup_guide.htm#Concepts">2.0
Shorewall Concepts</a></li>
<li><a href="shorewall_setup_guide.htm#Interfaces">3.0
Network Interfaces</a></li>
<li><a href="shorewall_setup_guide.htm#Addressing">4.0
@ -101,7 +101,8 @@ RFC 1918</a></li>
up your Network</a>
<ul>
<li><a href="shorewall_setup_guide.htm#Routed">5.1 Routed</a></li>
<li><a href="shorewall_setup_guide.htm#Routed">5.1
Routed</a></li>
</ul>
@ -127,8 +128,8 @@ Static NAT</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#Rules">5.3 Rules</a></li>
<li><a href="shorewall_setup_guide.htm#OddsAndEnds">5.4
Odds and Ends</a></li>
<li><a
href="shorewall_setup_guide.htm#OddsAndEnds">5.4 Odds and Ends</a></li>
</ul>
@ -179,8 +180,9 @@ files</a></li>
<li><a
href="configuration_file_basics.htm#Compliment">Complementing an IP address
or Subnet</a></li>
<li><a href="configuration_file_basics.htm#Configs">Shorewall
Configurations (making a test configuration)</a></li>
<li><a
href="configuration_file_basics.htm#Configs">Shorewall Configurations
(making a test configuration)</a></li>
<li><a href="configuration_file_basics.htm#MAC">Using
MAC Addresses in Shorewall</a></li>
@ -225,8 +227,8 @@ files</a></li>
</li>
<li><a href="dhcp.htm">DHCP</a></li>
<li><font color="#000099"><a
href="shorewall_extension_scripts.htm">Extension Scripts</a></font> (How
to extend Shorewall without modifying Shorewall code)</li>
href="shorewall_extension_scripts.htm">Extension Scripts</a></font>
(How to extend Shorewall without modifying Shorewall code)</li>
<li><a href="fallback.htm">Fallback/Uninstall</a></li>
<li><a href="shorewall_firewall_structure.htm">Firewall
Structure</a></li>
@ -270,22 +272,24 @@ with Shorewall</a><br>
<ul>
<li><a href="IPSEC.htm">IPSEC</a></li>
<li><a href="IPIP.htm">GRE and IPIP</a></li>
<li><a href="OPENVPN.html">OpenVPN</a><br>
</li>
<li><a href="PPTP.htm">PPTP</a></li>
<li><a href="VPN.htm">IPSEC/PPTP</a> from a system behind
your firewall to a remote network.</li>
<li><a href="VPN.htm">IPSEC/PPTP</a> from a system
behind your firewall to a remote network.</li>
</ul>
</li>
<li><a href="whitelisting_under_shorewall.htm">White List
Creation</a></li>
<li><a href="whitelisting_under_shorewall.htm">White
List Creation</a></li>
</ul>
<p>If you use one of these guides and have a suggestion for improvement <a
href="mailto:webmaster@shorewall.net">please let me know</a>.</p>
<p><font size="2">Last modified 1/28/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font size="2">Last modified 2/4/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright 2002, 2003 Thomas M.
Eastep</font></a><br>
@ -293,5 +297,6 @@ Eastep</font></a><br>
<br>
<br>
<br>
<br>
</body>
</html>

View File

@ -18,6 +18,7 @@
<meta name="Microsoft Theme" content="none">
</head>
<body>
@ -139,9 +140,10 @@ list have answers directly accessible from the <a
Can anyone tell you what that strange smell is?<br>
<br>
Now, all of us could do some wonderful guessing as to the smell
and even what's causing it. You would be absolutely amazed at the range
and variety of smells we could come up with. Even more amazing is that
all of the explanations for the smells would be completely plausible."<br>
and even what's causing it. You would be absolutely amazed at the
range and variety of smells we could come up with. Even more amazing
is that all of the explanations for the smells would be completely
plausible."<br>
</i><br>
<div align="center"> - <i>Russell Mosemann</i> on the Postfix mailing list<br>
@ -232,8 +234,9 @@ do your job for you.<br>
</ul>
<ul>
<li><b>NEVER </b>include the output of "<b><font color="#009900">iptables
-L</font></b>". Instead, please post the exact output of<br>
<li><b>NEVER </b>include the output of "<b><font
color="#009900">iptables -L</font></b>". Instead, if you are having connection
problems please post the exact output of<br>
<br>
<b><font color="#009900">/sbin/shorewall status<br>
<br>
@ -271,9 +274,9 @@ so, include the message(s) in your post along with a copy of your /etc/shorewa
file.<br>
<br>
</li>
<li>Please include any of the Shorewall configuration files (especially
the /etc/shorewall/hosts file if you have modified that file)
that you think are relevant. If you include /etc/shorewall/rules,
<li>Please include any of the Shorewall configuration files
(especially the /etc/shorewall/hosts file if you have modified
that file) that you think are relevant. If you include /etc/shorewall/rules,
please include /etc/shorewall/policy as well (rules are meaningless unless
one also knows the policies). </li>
@ -306,23 +309,23 @@ so, include the message(s) in your post along with a copy of your /etc/shorewa
</li>
</ul>
The author gratefully acknowleges that the above list was heavily plagiarized
from the excellent LEAF document by <i>Ray</i> <em>Olszewski</em> found
at <a
The author gratefully acknowleges that the above list was heavily
plagiarized from the excellent LEAF document by <i>Ray</i> <em>Olszewski</em>
found at <a
href="http://leaf-project.org/pub/doc/docmanager/docid_1891.html">http://leaf-project.org/pub/doc/docmanager/docid_1891.html</a>.<br>
<h2>Please post in plain text</h2>
<blockquote> </blockquote>
A growing number of MTAs serving list subscribers are rejecting all
HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net
"for continuous abuse" because it has been my policy to allow HTML in
list posts!!<br>
A growing number of MTAs serving list subscribers are rejecting
all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net
"for continuous abuse" because it has been my policy to allow HTML in list
posts!!<br>
<br>
I think that blocking all HTML is a Draconian way to control spam
and that the ultimate losers here are not the spammers but the list subscribers
whose MTAs are bouncing all shorewall.net mail. As one list subscriber
wrote to me privately "These e-mail admin's need to get a <i>(expletive
I think that blocking all HTML is a Draconian way to control
spam and that the ultimate losers here are not the spammers but the list
subscribers whose MTAs are bouncing all shorewall.net mail. As one list
subscriber wrote to me privately "These e-mail admin's need to get a <i>(expletive
deleted)</i> life instead of trying to rid the planet of HTML based e-mail".
Nevertheless, to allow subscribers to receive list posts as must as possible,
I have now configured the list server at shorewall.net to strip all HTML
@ -333,16 +336,17 @@ list posts!!<br>
<blockquote>
<h4>If you run Shorewall under Bering -- <span
style="font-weight: 400;">please post your question or problem
to the <a href="mailto:leaf-user@lists.sourceforge.net">LEAF Users mailing
list</a>.</span></h4>
to the <a href="mailto:leaf-user@lists.sourceforge.net">LEAF Users
mailing list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft Multi Network Firewall
(MNF) and you have not purchased an MNF license from MandrakeSoft then
you can post non MNF-specific Shorewall questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing list.</a>
<b>Do not expect to get free MNF support on the list.</b><br>
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list.</a> <b>Do not expect to get free MNF support on the list.</b><br>
<p>Otherwise, please post your question or problem to the <a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing list.</a></p>
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list.</a></p>
</blockquote>
@ -353,13 +357,13 @@ list posts!!<br>
.</p>
<p align="left"><font size="2">Last Updated 1/16/2002 - Tom Eastep</font></p>
<p align="left"><font size="2">Last Updated 2/3/2003 - Tom Eastep</font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
<br>
</body>
</html>