mirror of
https://gitlab.com/shorewall/code.git
synced 2025-02-02 02:49:54 +01:00
Correct capitalization of IPsec
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
Tom Eastep
parent
e47b57fd4a
commit
9869dd25d7
@ -107,7 +107,7 @@
|
||||
requires an appropriate SA to exist. SAs may be created manually using
|
||||
<command>setkey</command>(8) but most often, they are created by a
|
||||
cooperative process involving the ISAKMP protocol and a daemon included in
|
||||
your IPSEC package (StrongSwan, LibreSwan, ipsec-tools/Racoon, etc.) .
|
||||
your IPsec package (StrongSwan, LibreSwan, ipsec-tools/Racoon, etc.) .
|
||||
Incoming traffic is verified against the SPD to ensure that no unencrypted
|
||||
traffic is accepted in violation of the administrator's policies.</para>
|
||||
|
||||
@ -227,7 +227,7 @@
|
||||
|
||||
<important>
|
||||
<para>This article provides guidance regarding configuring Shorewall to
|
||||
use with IPSEC. For configuring IPSEC itself, consult your IPSEC
|
||||
use with IPsec. For configuring IPsec itself, consult your IPsec
|
||||
product's documentation.</para>
|
||||
</important>
|
||||
</section>
|
||||
@ -683,9 +683,9 @@ ipip <emphasis role="bold">vpn</emphasis> 0.0.0.0/0</prog
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Using SNAT to Force Traffic over an IPSEC Tunnel</title>
|
||||
<title>Using SNAT to Force Traffic over an IPsec Tunnel</title>
|
||||
|
||||
<para>Cases can arise where you need to use an IPSEC tunnel to access a
|
||||
<para>Cases can arise where you need to use an IPsec tunnel to access a
|
||||
remote network, but you have no control over the associated security
|
||||
polices. In such cases, the resulting tunnel is accessible from your
|
||||
firewall but not from your local networks.</para>
|
||||
@ -716,6 +716,11 @@ ipip <emphasis role="bold">vpn</emphasis> 0.0.0.0/0</prog
|
||||
<listitem>
|
||||
<para>You want to access 172.22.4.0/24 from 192.168.219.0/24</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The IPsec tunnel is configured between 172.22.4.0/24 and
|
||||
192.0.2.199</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>You need to configure as follows.</para>
|
||||
@ -727,6 +732,11 @@ ipip <emphasis role="bold">vpn</emphasis> 0.0.0.0/0</prog
|
||||
vpn ip # Note that the zone <emphasis role="bold">cannot</emphasis> be declared as type ipsec
|
||||
...</programlisting>
|
||||
|
||||
<para>/etc/shorewall/interfaces:</para>
|
||||
|
||||
<programlisting>#ZONE INTERFACE OPTIONS
|
||||
net eth0 nets=(!172.22.4.0/24),... # You must exclude the remote network from the net zone</programlisting>
|
||||
|
||||
<para>/etc/shorewall/hosts:</para>
|
||||
|
||||
<programlisting>#ZONE HOSTS OPTIONS
|
||||
|
||||
@ -1233,7 +1233,7 @@ gateway:~ #</programlisting>
|
||||
those clients. See<link linkend="Openvpn"> Example 2</link>
|
||||
below.</para>
|
||||
|
||||
<para>If you have an IPSEC gateway on your firewall, be sure to
|
||||
<para>If you have an IPsec gateway on your firewall, be sure to
|
||||
arrange for ESP packets to be routed out of the same interface that
|
||||
you have configured your keying daemon to use.</para>
|
||||
</section>
|
||||
|
||||
@ -1021,7 +1021,7 @@ Mirrors(ACCEPT:none) { SOURCE=net, DEST=dmz:$SERVER, PROTO=tcp, DPORT=873 }
|
||||
<section>
|
||||
<title>tunnels</title>
|
||||
|
||||
<para>Both address families define IPSEC tunnels:</para>
|
||||
<para>Both address families define IPsec tunnels:</para>
|
||||
|
||||
<programlisting>#TYPE ZONE GATEWAY GATEWAY_ZONE
|
||||
ipsecnat {ZONE=net, GATEWAY=$ALL, GATEWAY_ZONE=vpn }
|
||||
|
||||
10
docs/VPN.xml
10
docs/VPN.xml
@ -43,7 +43,7 @@
|
||||
|
||||
<para>It is often the case that a system behind the firewall needs to be
|
||||
able to access a remote network through Virtual Private Networking (VPN).
|
||||
The two most common means for doing this are IPSEC and PPTP. The basic
|
||||
The two most common means for doing this are IPsec and PPTP. The basic
|
||||
setup is shown in the following diagram:</para>
|
||||
|
||||
<graphic fileref="images/VPN.png"/>
|
||||
@ -60,8 +60,8 @@
|
||||
modules file, Shorewall (Lite) will attempt to load these modules when
|
||||
Shorewall (Lite) is started.</para>
|
||||
|
||||
<para>If IPSEC is being used, you should configure IPSEC to use
|
||||
<firstterm>NAT Traversal</firstterm> -- Under NAT traversal the IPSEC
|
||||
<para>If IPsec is being used, you should configure IPsec to use
|
||||
<firstterm>NAT Traversal</firstterm> -- Under NAT traversal the IPsec
|
||||
packets (protocol 50 or 51) are encapsulated in UDP packets (normally with
|
||||
destination port 4500). Additionally, <firstterm>keep-alive
|
||||
messages</firstterm> are sent frequently so that NATing gateways between
|
||||
@ -69,10 +69,10 @@
|
||||
way that I connect to the HP Intranet and it works flawlessly without
|
||||
anything in Shorewall other than my ACCEPT loc->net policy. NAT
|
||||
traversal is available as a patch for Windows 2K and is a standard feature
|
||||
of Windows XP -- simply select "L2TP IPSec VPN" from the "Type of VPN"
|
||||
of Windows XP -- simply select "L2TP IPsec VPN" from the "Type of VPN"
|
||||
pulldown.</para>
|
||||
|
||||
<para>Alternatively, if you have an IPSEC gateway behind your firewall
|
||||
<para>Alternatively, if you have an IPsec gateway behind your firewall
|
||||
then you can try the following: only one system may connect to the remote
|
||||
gateway and there are firewall configuration requirements as
|
||||
follows:</para>
|
||||
|
||||
@ -508,7 +508,7 @@ rc-update add bridge boot
|
||||
packet arrived on and/or the bridge port that a packet will be sent over.
|
||||
The latter has proved to be problematic because it requires that the
|
||||
evaluation of rules be deferred until the destination bridge port is
|
||||
known. This deferral has the unfortunate side effect that it makes IPSEC
|
||||
known. This deferral has the unfortunate side effect that it makes IPsec
|
||||
Netfilter filtration incompatible with bridges. To work around this
|
||||
problem, in kernel version 2.6.20 the Netfilter developers decided to
|
||||
remove the deferred processing in two cases:</para>
|
||||
|
||||
@ -242,7 +242,7 @@ IMAPS(ACCEPT) <source> <destination> # IMAP over SSL.</programlis
|
||||
</section>
|
||||
|
||||
<section id="IPSEC">
|
||||
<title>IPSEC</title>
|
||||
<title>IPsec</title>
|
||||
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DPORT
|
||||
ACCEPT <emphasis><source></emphasis> <emphasis> <destination></emphasis> 50
|
||||
@ -252,8 +252,8 @@ ACCEPT <emphasis><destination></emphasis> <emphasis><source></e
|
||||
ACCEPT <emphasis><destination></emphasis> <emphasis><source></emphasis> 51
|
||||
ACCEPT <emphasis><destination></emphasis> <emphasis><source></emphasis> udp 500</programlisting>
|
||||
|
||||
<para>Lots more information <ulink url="IPSEC.htm">here</ulink> and <ulink
|
||||
url="VPN.htm">here</ulink>.</para>
|
||||
<para>Lots more information <ulink url="IPSEC-2.6.html">here</ulink> and
|
||||
<ulink url="VPN.htm">here</ulink>.</para>
|
||||
</section>
|
||||
|
||||
<section id="LDAP">
|
||||
|
||||
@ -176,7 +176,7 @@
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><ulink url="manpages/shorewall-tunnels.html">IPSEC, GRE,
|
||||
<para><ulink url="manpages/shorewall-tunnels.html">IPsec, GRE,
|
||||
IPIP and OpenVPN Tunnels</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
|
||||
@ -277,7 +277,7 @@ State:Stopped (Thu Mar 30 14:08:11 PDT 2006)</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If your problem has anything to do with IPSEC, be sure that
|
||||
<para>If your problem has anything to do with IPsec, be sure that
|
||||
the ipsec-tools package is installed.</para>
|
||||
</listitem>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user