summaryrefslogtreecommitdiff
path: root/doc/src/quickstart-firewall.html
diff options
context:
space:
mode:
authorRene Mayrhofer <rene@mayrhofer.eu.org>2007-01-30 12:21:07 +0000
committerRene Mayrhofer <rene@mayrhofer.eu.org>2007-01-30 12:21:07 +0000
commitaaa0331ecf95ced1e913ac9be50168cf0e7cbb82 (patch)
tree3a86b51b3cb0b5ce596ebd0043af7b3f44384461 /doc/src/quickstart-firewall.html
parent61aaf3c61a16fb7257ea58f381f3579cea84d9c1 (diff)
downloadvyos-strongswan-aaa0331ecf95ced1e913ac9be50168cf0e7cbb82.tar.gz
vyos-strongswan-aaa0331ecf95ced1e913ac9be50168cf0e7cbb82.zip
[svn-upgrade] Integrating new upstream version, strongswan (2.8.2)
Diffstat (limited to 'doc/src/quickstart-firewall.html')
-rw-r--r--doc/src/quickstart-firewall.html187
1 files changed, 0 insertions, 187 deletions
diff --git a/doc/src/quickstart-firewall.html b/doc/src/quickstart-firewall.html
deleted file mode 100644
index 53c27b5af..000000000
--- a/doc/src/quickstart-firewall.html
+++ /dev/null
@@ -1,187 +0,0 @@
-<html>
-<head>
- <meta http-equiv="Content-Type" content="text/html">
- <title>Quick FreeS/WAN installation and configuration</title>
- <meta name="keywords"
- content="Linux, IPsec, VPN, security, FreeSWAN, installation, quickstart">
- <!--
-
- Written by Sandy Harris for the Linux FreeS/WAN project
- Revised by Claudia Schmeing for same
- Freely distributable under the GNU General Public License
-
- More information at www.freeswan.org
- Feedback to users@lists.freeswan.org
-
- RCS ID: $Id: quickstart-firewall.html,v 1.1 2004/03/15 20:35:24 as Exp $
- Last changed: $Date: 2004/03/15 20:35:24 $
- Revision number: $Revision: 1.1 $
-
- CVS revision numbers do not correspond to FreeS/WAN release numbers.
- -->
-</head>
-<BODY>
-<H1><A name="quick_firewall">FreeS/WAN quick start on firewalling</A></H1>
-<P>This firewalling information supplements our
-<A HREF="quickstart.html#quick_guide">quickstart guide.</A></P>
-<P>It includes tips for firewalling:</P>
-<UL>
-<LI><A HREF="#firewall.standalone">a standalone system with initiator-only
-opportunism</A></LI>
-<LI><A HREF="#incoming.opp.firewall">incoming opportunistic connections</A></LI>
-<LI><A HREF="#opp.gate.firewall">an opportunistic gateway</A></LI>
-</UL>
-<P>and a list of helpful <A HREF="#resources">resources</A>.</P>
-<H2><A name="firewall.standalone">Firewalling a standalone system</A></H2>
-<P>Firewall rules on a standalone system doing IPsec can be very simple.</P>
-<P>The first step is to allow IPsec packets (IKE on UDP port 500 plus
- ESP, protocol 50) in and out of your gateway. A script to set up
- iptables(8) rules for this is:</P>
-<PRE># edit this line to match the interface you use as default route
-# ppp0 is correct for many modem, DSL or cable connections
-# but perhaps not for you
-world=ppp0
-#
-# allow IPsec
-#
-# IKE negotiations
-iptables -A INPUT -p udp -i $world --sport 500 --dport 500 -j ACCEPT
-iptables -A OUTPUT -p udp -o $world --sport 500 --dport 500 -j ACCEPT
-# ESP encryption and authentication
-iptables -A INPUT -p 50 -i $world -j ACCEPT
-iptables -A OUTPUT -p 50 -o $world -j ACCEPT</PRE>
-<P>Optionally, you could restrict this, allowing these packets only to
- and from a list of known gateways.</P>
-<P>A second firewalling step -- access controls built into the IPsec
- protocols -- is automatically applied:</P>
-<DL>
-<DT><A href="glossary.html#Pluto">Pluto</A> -- the FreeS/WAN keying
- daemon -- deals with the IKE packets.</DT>
-<DD>Pluto authenticates its partners during the IKE negotiation, and
- drops negotiation if authentication fails.</DD>
-<DT><A href="glossary.html#KLIPS">KLIPS</A> -- the FreeS/WAN kernel
- component -- handles the ESP packets.</DT>
-<DD>
-<DL>
-<DT>KLIPS drops outgoing packets</DT>
-<DD>if they are routed to IPsec, but no tunnel has been negotiated for
- them</DD>
-<DT>KLIPS drops incoming unencrypted packets</DT>
-<DD>if source and destination addresses match a tunnel; the packets
- should have been encrypted</DD>
-<DT>KLIPS drops incoming encrypted packets</DT>
-<DD>if source and destination address do not match the negotiated
- parameters of the tunnel that delivers them</DD>
-<DD>if packet-level authentication fails</DD>
-</DL>
-</DD>
-</DL>
-<P>These errors are logged. See our <A href="trouble.html">
- troubleshooting</A> document for details.</P>
-<P>As an optional third step, you may wish to filter packets emerging from
- your opportunistic tunnels.
- These packets arrive on an interface such as <VAR>ipsec0</VAR>, rather than
- <VAR>eth0</VAR>, <VAR>ppp0</VAR> or whatever. For example, in an iptables(8)
- rule set, you would use:</P>
-<DL>
-<DT><VAR>-i ipsec+</VAR></DT>
-<DD>to specify packets arriving on any ipsec device</DD>
-<DT><VAR>-o ipsec+</VAR></DT>
-<DD>to specify packets leaving via any ipsec device</DD>
-</DL>
-<P>In this way, you can apply whatever additional filtering you like to these
-packets.</P>
-<P>The packets emerging on <VAR>ipsec0</VAR> are likely
- to be things that a client application on your machine requested: web
- pages, e-mail, file transfers and so on. However, any time you initiate
- an opportunistic connection, you open a two-way connection to
- another machine (or network). It is conceivable that a Bad Guy there
- could take advantage of your link.</P>
-<P>For more information, read the next section.</P>
-</P>
-<H2><A name="incoming.opp.firewall">Firewalling incoming opportunistic
- connections</A></H2>
-<P>The basic firewalling for IPsec does not change when you support
- incoming connections as well as connections you initiate. You must
- still allow IKE (UDP port 500) and ESP (protocol 50) packets to and
- from your machine, as in the rules given <A href="#firewall.standalone">
- above</A>.</P>
-<P>However, there is an additional security concern when you allow
- incoming opportunistic connections. Incoming opportunistic packets
- enter your machine via an IPSec tunnel. That is, they all appear as
- ESP (protocol 50) packets, concealing whatever port and protocol
- characteristics the packet within the tunnel has. Contained
- in the tunnel as they pass through <VAR>ppp0</VAR> or <VAR>eth0</VAR>,
- these packets can bypass your usual firewall rules on these interfaces.
-<P>Consequently, you will want to firewall your <VAR>ipsec</VAR> interfaces
- the way you would any publicly accessible interface.</P>
-<P>A simple way to do this is to create one iptables(8) table with
- all your filtering rules for incoming packets, and apply the entire table to
- all public interfaces, including <VAR>ipsec</VAR> interfaces.</P>
-
-<H2><A name="opp.gate.firewall">Firewalling for opportunistic gateways</A></H2>
-<P>On a gateway, the IPsec-related firewall rules applied for input and
- output on the Internet side are exactly as shown
-<A HREF="#firewall.standalone">above</A>. A gateway
- exchanges exactly the same things -- UDP 500 packets and IPsec packets
- -- with other gateways that a standalone system does, so it can use
- exactly the same firewall rules as a standalone system would.</P>
-<P>However, on a gateway there are additional things to do:</P>
-<UL>
-<LI>you have other interfaces and need rules for them</LI>
-<LI>packets emerging from ipsec processing must be correctly forwarded</LI>
-</UL>
-<P>You need additional rules to handle these things. For example, adding
- some rules to the set shown above we get:</P>
-<PRE># edit this line to match the interface you use as default route
-# ppp0 is correct for many modem, DSL or cable connections
-# but perhaps not for you
-world=ppp0
-#
-# edit these lines to describe your internal subnet and interface
-localnet=42.42.42.0/24
-internal=eth1
-#
-# allow IPsec
-#
-# IKE negotiations
-iptables -A INPUT -p udp -i $world --sport 500 --dport 500 -j ACCEPT
-iptables -A OUTPUT -p udp -o $world --sport 500 --dport 500 -j ACCEPT
-# ESP encryption and authentication
-iptables -A INPUT -p 50 -i $world -j ACCEPT
-iptables -A OUTPUT -p 50 -o $world -j ACCEPT
-#
-# packet forwarding for an IPsec gateway
-# simplest possible rules
-$ forward everything, with no attempt to filter
-#
-# handle packets emerging from IPsec
-# ipsec+ means any of ipsec0, ipsec1, ...
-iptables -A FORWARD -d $localnet -i ipsec+ -j ACCEPT
-# simple rule for outbound packets
-# let local net send anything
-# IPsec will encrypt some of it
-iptables -A FORWARD -s $localnet -i $internal -j ACCEPT </PRE>
-<P>On a production gateway, you would no doubt need tighter rules than
- the above.</P>
-<H2><A NAME="resources">Firewall resources</A></H2>
-<P>For more information, see these handy resources:</P>
-<UL>
-<LI><A href="http://www.netfilter.org/documentation/">netfilter
- documentation</A></LI>
-<LI>books such as:
-<UL>
-<LI>Cheswick and Bellovin, <A href="biblio.html#firewall.book">Firewalls
- and Internet Security</A></LI>
-<LI>Zeigler, <A href="biblio.html#Zeigler">Linux Firewalls</A>,</LI>
-</UL>
-</LI>
-<LI><A href="firewall.html#firewall">our firewalls document</A></LI>
-<LI><A href="web.html#firewall.web">our firewall links</A></LI>
-</UL>
-<A HREF="quickstart.html#quick.firewall">Back to our quickstart guide.</A>
-</BODY>
-</HTML>
-
-
-