From a15b2918a4256a7f4bdb4d2f74a44ed801d8fffe Mon Sep 17 00:00:00 2001 From: Tom Eastep Date: Sun, 8 Jan 2017 13:32:34 -0800 Subject: [PATCH] Remove ipsec-tools/Racoon config info from the IPSEC-2.6 Article Signed-off-by: Tom Eastep --- docs/IPSEC-2.6.xml | 427 ++++----------------------------------------- 1 file changed, 32 insertions(+), 395 deletions(-) diff --git a/docs/IPSEC-2.6.xml b/docs/IPSEC-2.6.xml index 87ce669dc..9f028f889 100644 --- a/docs/IPSEC-2.6.xml +++ b/docs/IPSEC-2.6.xml @@ -106,10 +106,10 @@ traffic that is to be encrypted according to the contents of the SPD requires an appropriate SA to exist. SAs may be created manually using setkey(8) but most often, they are created by a - cooperative process involving the ISAKMP protocol and daemons such - as racoon or isakmpd. Incoming - traffic is verified against the SPD to ensure that no unencrypted traffic - is accepted in violation of the administrator's policies. + cooperative process involving the ISAKMP protocol and a daemon included in + 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. There are three ways in which IPsec traffic can interact with Shorewall policies and rules: @@ -225,18 +225,11 @@ of) SA(s) used to encrypt and decrypt traffic to/from the zone and the security policies that select which traffic to encrypt/decrypt. - This article assumes the use of ipsec-tools (http://ipsec-tools.sourceforge.net). - As of this writing, I recommend that you run at least version 0.5.2. - Debian users, please note that there are separate Debian packages for - ipsec-tools and racoon although the ipsec-tools project releases them as a - single package. - - For more information on IPsec, Kernel 2.6 and Shorewall see my presentation on the subject given at LinuxFest NW - 2005. Be warned though that the presentation is based on Shorewall - 2.2 and there are some differences in the details of how IPsec is - configured. + + This article provides guidance regarding configuring Shorewall to + use with IPSEC. For configuring IPSEC itself, consult your IPSEC + product's documentation. +
@@ -360,155 +353,25 @@ $FW vpn ACCEPT ACCEPT vpn:134.28.54.2 $FW - Note that your Security Policies must also be set up to send traffic - between 134.28.54.2 and 206.162.148.9 through the tunnel (see - below). + + If you have hosts that access the Internet through an IPsec + tunnel, then it is a good idea to set the MSS value for traffic from + those hosts explicitly in the /etc/shorewall/zones + file. For example, if hosts in the vpn + zone access the Internet through an ESP tunnel then the following entry + would be appropriate: - Once you have these entries in place, restart Shorewall (type - shorewall restart); you are now ready to configure IPsec. - - For full encrypted connectivity in this configuration (between the - subnets, between each subnet and the opposite gateway, and between the - gateways), you will need eight policies in - /etc/racoon/setkey.conf. For example, on gateway - A: - -
- # First of all flush the SPD and SAD databases -spdflush; -flush; - -# Add some SPD rules - -spdadd 192.168.1.0/24 10.0.0.0/8 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require; -spdadd 192.168.1.0/24 134.28.54.2/32 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require; -spdadd 206.162.148.9/32 134.28.54.2/32 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require; -spdadd 206.162.148.9/32 10.0.0.0/8 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require; -spdadd 10.0.0.0/8 192.168.1.0/24 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require; -spdadd 10.0.0.0/8 206.162.148.9/32 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require; -spdadd 134.28.54.2/32 192.168.1.0/24 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require; -spdadd 134.28.54.2/32 206.162.148.9/32 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require; -
- - The setkey.conf file on gateway B would be - similar. - - A sample /etc/racoon/racoon.conf file using - X.509 certificates might look like: - -
- path certificates "/etc/certs" ; - -listen -{ - isakmp 206.162.148.9; -} - -remote 134.28.54.2 -{ - exchange_mode main ; - certificate_type x509 "GatewayA.pem" "GatewayA_key.pem" ; - verify_cert on; - my_identifier asn1dn ; - peers_identifier asn1dn ; - verify_identifier on ; - lifetime time 24 hour ; - proposal { - encryption_algorithm blowfish; - hash_algorithm sha1; - authentication_method rsasig ; - dh_group 2 ; - } -} - -sainfo address 192.168.1.0/24 any address 10.0.0.0/8 any -{ - pfs_group 2; - lifetime time 12 hour ; - encryption_algorithm blowfish ; - authentication_algorithm hmac_sha1, hmac_md5 ; - compression_algorithm deflate ; -} - -sainfo address 206.162.148.9/32 any address 10.0.0.0/8 any -{ - pfs_group 2; - lifetime time 12 hour ; - encryption_algorithm blowfish ; - authentication_algorithm hmac_sha1, hmac_md5 ; - compression_algorithm deflate ; -} - -sainfo address 206.162.148.9/32 any address 134.28.54.2/32 any -{ - pfs_group 2; - lifetime time 12 hour ; - encryption_algorithm blowfish ; - authentication_algorithm hmac_sha1, hmac_md5 ; - compression_algorithm deflate ; -} - -sainfo address 192.168.1.0/24 any address 134.28.54.2/32 any -{ - pfs_group 2; - lifetime time 12 hour ; - encryption_algorithm blowfish ; - authentication_algorithm hmac_sha1, hmac_md5 ; - compression_algorithm deflate ; -} - - - If you have hosts that access the Internet through an IPsec - tunnel, then it is a good idea to set the MSS value for traffic from - those hosts explicitly in the - /etc/shorewall/zones file. For example, if hosts - in the vpn zone access the Internet - through an ESP tunnel then the following entry would be - appropriate: - - #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS + #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS vpn ipsec mode=tunnel mss=1400 - You should also set FASTACCEPT=No in shorewall.conf to ensure - that both the SYN and SYN,ACK packets have their MSS field - adjusted. + You should also set FASTACCEPT=No in shorewall.conf to ensure that + both the SYN and SYN,ACK packets have their MSS field adjusted. - Note that CLAMPMSS=Yes in shorewall.conf - isn't effective with the 2.6 native IPsec implementation because there - is no separate IPsec device with a lower mtu as there was under the - 2.4 and earlier kernels. - -
-
- -
- IPCOMP and IPSEC - - IPSEC can be configured to perform data compression. This is - accomplished by compressing the original IP packet, then encapsulating it - in an ipcomp (protocol 108) packet. That packet is then encrypted and - encapsulated within an ESP packet. Because of the extra protocol header - required for compression, short IP packets (such as default ping packets) - are not compressed. The Linux IP stack handles these uncompressed packets - by creating an IPIP (protocol 4) SA. As a consequence, IPIP packets from - the remote gateway must be handled in Shorewall. The easiest way to - accomplish this is to add an ACCEPT rule for protocol 4 from the IPSEC vpn - zone to the $FW zone: - -
- #ACTION SOURCE DEST PROTO DPORT ... -ACCEPT vpn $FW 4 -
- - Note that the source IP address is these IPIP packets is that of the - remote peer, so the definition of the ipsec zone in shorewall-hosts(5) must - include the peer. - - Finally, when IPCOMP is used, it is recommended that the OPTIONS - column of the ipsec zone's entry in shorewall-zones(5) be left - empty. + Note that CLAMPMSS=Yes in shorewall.conf + isn't effective with the 2.6 native IPsec implementation because there + is no separate IPsec device with a lower mtu as there was under the 2.4 + and earlier kernels. +
@@ -586,116 +449,7 @@ ipsec net 206.162.148.9 vpn #ZONE HOSTS OPTIONS vpn eth0:0.0.0.0/0 - - On system A, here are the IPsec files: - -
- /etc/racoon/racoon.conf - System A: - - path certificate "/etc/certs" ; - -listen -{ - isakmp 206.162.148.9; -} - -remote anonymous -{ - exchange_mode main ; - generate_policy on ; - passive on ; - certificate_type x509 "GatewayA.pem" "GatewayA_key.pem" ; - verify_cert on; - my_identifier asn1dn ; - peers_identifier asn1dn ; - verify_identifier on ; - lifetime time 24 hour ; - proposal { - encryption_algorithm blowfish ; - hash_algorithm sha1; - authentication_method rsasig ; - dh_group 2 ; - } -} - -sainfo anonymous -{ - pfs_group 2; - lifetime time 12 hour ; - encryption_algorithm blowfish ; - authentication_algorithm hmac_sha1, hmac_md5 ; - compression_algorithm deflate ; -} - - /etc/racoon/setkey.conf - System A: - - flush; -spdflush; -
- - If system A is running kernel 2.6.10 or later then it must also be - running ipsec-tools (racoon) 0.5rc1 or later. - - On the mobile system (system B), it is not possible to create a - static IPsec configuration because the IP address of the laptop's - Internet connection isn't static. I have created an 'ipsecvpn' script - and included in the tarball and in the RPM's documentation directory; - this script can be used to start and stop the connection. - - The ipsecvpn script has some variable assignments at the top -- in - the above case, these would be as follows: - -
- # -# External Interface -# -INTERFACE=eth0 -# -# Remote IPsec Gateway -# -GATEWAY=206.162.148.9 -# -# Networks behind the remote gateway -# -NETWORKS="192.168.1.0/24" -# -# Directory where X.509 certificates are stored. -# -CERTS=/etc/certs -# -# Certificate to be used for this connection. The cert -# directory must contain: -# -# ${CERT}.pem - the certificate -# ${CERT}_key.pem - the certificates's key -# -CERT=roadwarrior -# -# The setkey binary -# -SETKEY=/usr/sbin/setkey -# -# The racoon binary -# -RACOON=/usr/sbin/racoon -
- - The ipsecvpn script can be installed in /etc/init.d/ but it is - probably best installed in /usr/local/sbin and run manually: - -
- ipsecvpn start # Starts the tunnel - - ipsecvpn stop # Stops the tunnel -
- - - Although the ipsecvpn script allows you to specify multiple remote - NETWORKS as a space-separated list, SAs are created on the gateway only - during ISAKMP negotiation. So in practice, only the first remote network - accessed will be accessible from the roadwarrior. -
@@ -853,62 +607,7 @@ HTTPS(ACCEPT) l2tp $FW hosts in that network. In that case, IPsec transport mode is an appropriate solution. - Here's an example using - the ipsec-tools package. The files shown are from host 192.168.20.10; the - configuration of the other nodes is similar. - -
- /etc/racoon/racoon.conf: - - path pre_shared_key "/etc/racoon/psk.txt" ; - -remote anonymous -{ - exchange_mode main ; - my_identifier address ; - lifetime time 24 hour ; - proposal { - encryption_algorithm blowfish ; - hash_algorithm sha1; - authentication_method pre_shared_key ; - dh_group 2 ; - } -} - -sainfo anonymous -{ - pfs_group 2; - lifetime time 12 hour ; - encryption_algorithm blowfish ; - authentication_algorithm hmac_sha1, hmac_md5 ; - compression_algorithm deflate ; -} - - - /etc/racoon/setkey.conf: - - # First of all flush the SPD database -spdflush; - -# Add some SPD rules - -spdadd 192.168.20.10/32 192.168.20.20/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.20/require; -spdadd 192.168.20.20/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.20.20-192.168.20.10/require; -spdadd 192.168.20.10/32 192.168.20.30/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.30/require; -spdadd 192.168.20.30/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.20.30-192.168.20.10/require; -spdadd 192.168.20.10/32 192.168.20.40/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.40/require; -spdadd 192.168.20.40/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.20.40-192.168.20.10/require; - - - /etc/racoon/psk.txt: - - 192.168.20.20 <key for 192.168.20.10<->192.168.20.20> -192.168.20.30 <key for 192.168.20.10<->192.168.20.30> -192.168.20.40 <key for 192.168.20.10<->192.168.20.40> - - Note that the same keymust be - used in both directions. -
+ Shorewall configuration goes as follows: @@ -973,75 +672,13 @@ all all REJECT info ipip vpn 0.0.0.0/0The above assumes that the name of your IPsec vpn zone is vpn. -
-
- IPsec and <trademark>Windows</trademark> XP - - I have successfully configured my work laptop to use IPsec with - X.509 certificates for wireless IP communication when it is undocked at - home. I looked at dozens of sites and the one I found most helpful was - http://ipsec.math.ucla.edu/services/ipsec-windows.html. - The instructions on that site are directed to students at UCLA but they - worked fine for me (once I followed them very carefully). - - - The instructions found on the UCLA site are complex and do not - include any information on the generation of X.509 certificates. There - are lots of sites however that can tell you how to generate - certificates, including http://www.ipsec-howto.org/. - - One piece of information that may not be so easy to find is "How - do I generate a PKCS#12 certificate to import into Windows?". Here's the - openssl command that I used: - - openssl pkcs12 -export -in eastepnc6000.pem -inkey eastepnc6000_key.pem -out eastepnc6000.pfx -name "IPsec Cert for Home Wireless" - - I was prompted for a password to associate with the certificate. - This password is entered on the Windows system during import. - - In the above command: - - - - eastepnc6000.pem was the laptop's - certificate in PEM format. - - - - eastepnc6000_key.pem was the laptop's - private key (actually, it's the original signing request which - includes the private key). - - - - eastepnc6000.pfx is the PKCS#12 output - file. - - - - "IPsec Cert for Home Wireless" is the friendly name for the - certificate. - - - - I started to write an article about how to do this, complete with - graphics captured from my laptop. I gave up. I had captured 12 images - and hadn't really started yet. The Windows interface for configuring - IPsec is the worst GUI that I have ever used. What can be displayed on - one split Emacs screen (racoon.conf plus setkey.conf) takes 20+ - different dialog boxes on Windows XP!!! - -
- -
- Source of Additional Samples - - Be sure to check out the src/racoon/samples subdirectory in the - ipsec-tools source tree. It has a wide variety of sample racoon - configuration files. + + Note that this protocol 4 (IPIP) traffic appears to originate in + the vpn zone, but it's source IP address is that of the remote gateway. + As a consequence, that address must be included in the definition of the + remote zone. If you haven't done that, the traffic will be dropped in + the INPUT chain. +