From e2c1abb15e301de662396b21581e427068f55eca Mon Sep 17 00:00:00 2001 From: teastep Date: Sat, 18 Dec 2004 20:57:51 +0000 Subject: [PATCH] VPN Updates to documentaton git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1833 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs2/IPSEC-2.6.xml | 132 ++++++++++++++++- Shorewall-docs2/VPNBasics.xml | 264 ++++++++++++++++++++++++++++++++++ 2 files changed, 395 insertions(+), 1 deletion(-) create mode 100644 Shorewall-docs2/VPNBasics.xml diff --git a/Shorewall-docs2/IPSEC-2.6.xml b/Shorewall-docs2/IPSEC-2.6.xml index c3448b109..aa1c7ce2a 100644 --- a/Shorewall-docs2/IPSEC-2.6.xml +++ b/Shorewall-docs2/IPSEC-2.6.xml @@ -15,7 +15,7 @@ - 2004-12-04 + 2004-12-18 2004 @@ -453,7 +453,137 @@ vpn eth0:0.0.0.0/0 ipsec You will need to configure your through the tunnel policy as shown under the first example above. + + On the laptop: + +
+ /etc/shorewall/zones - System B: + + #ZONE DISPLAY COMMENTS +vpn VPN VPN back home +net Internet The big bad internet +loc local Local Network (192.168.1.0/24) +#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE + + /etc/shorewall/tunnels - System B: + + #TYPE ZONE GATEWAY GATEWAY ZONE +ipsec net 206.162.148.9 vpn +#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE + + /etc/shorewall/hosts - System B: + + #ZONE HOSTS OPTIONS +vpn eth0:0.0.0.0/0 ipsec +#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE +
+ + 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 3des; + hash_algorithm sha1; + authentication_method rsasig ; + dh_group 2 ; + } +} + +sainfo anonymous +{ + pfs_group 2; + lifetime time 12 hour ; + encryption_algorithm 3des, blowfish, des, rijndael ; + authentication_algorithm hmac_sha1, hmac_md5 ; + compression_algorithm deflate ; +} + + /etc/racoon/setkey.conf - System A: + + flush; +spdflush; +
+ + 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. +
diff --git a/Shorewall-docs2/VPNBasics.xml b/Shorewall-docs2/VPNBasics.xml new file mode 100644 index 000000000..1203e41df --- /dev/null +++ b/Shorewall-docs2/VPNBasics.xml @@ -0,0 +1,264 @@ + + +
+ + + + VPN, Netfilter and Shorewall — The Basics + + + + Tom + + Eastep + + + + 2004-12-18 + + + 2004 + + Thomas M. Eastep + + + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, Version + 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 + GNU Free Documentation + License. + + + +
+ Gateway-to-gateway traffic vs. Host-to-host traffic. + + The purpose of a Virtual Private Network + (VPN) is to provide for secure communication between a set of hosts. + Communication between a pair of hosts connected by a VPN occurs in + stages: + + + + Local-host-to-local-gateway. + This communication is not encrypted; in the case where the traffic + originates on the gateway itself, the communication is local to that + system. + + + + Local-gateway-to-remote-gateway. This + communication is encrypted and can use a tunneling protocol such as + GRE, AH or ESP or a standard protocol such as UDP or TCP. Some VPNs + use multiple protocols; for example PPTP uses TCP port 1723 and GRE + while IPSEC uses UDP port 500 together with ESP or AH. + + + + Remote-gateway-to-remote-host. + This is just the unencrypted traffic described in the first item as it + is delivered to its destination. + + + + Of course, one-way communication generally isn't useful so we need + traffic in the other direction as well. + + + + Remote-host-to-remote-gateway. + + + + Remote-gateway-to-local-gateway. + + + + Local-gateway-to-local-host. + + +
+ +
+ Relationship to Netfilter + + When Netfilter is configured on a VPN gateway, each VPN packet goes + through Netfilter twice! Let's first consider outbound traffic: + + + + Local-host-to-local-gateway. + This traffic has a source address in the local network or on the + gateway itself. The destination IP address is that of a remote host; + either the remote gateway itself or a host behind that gaeway. + + + + Local-gateway-to-remote-gateway. This + (encrypted) traffic has a source IP address on the gateway and is + addressed to the remote gateway. + + + + Incoming traffic is similar. +
+ +
+ What does this mean with Shorewall? + + When Shorewall is installed on a VPN gateway system, it catagorizes + the VPN-related traffic slightly differently: + + + + Local-host-to-remote-host — same as Local-host-to-local-gateway + above. + + + + Local-gateway-to-remote-gateway. + + + + Remote-gateway-to-local-gateway. + + + + Remote-host-to-local-host — same as Local-gateway-to-local-host + above. + + + + Shorewall implements a set of features for dealing with VPN. + + + + The /etc/shorewall/tunnels file. This file + is used to define remote gateways and the type of encrypted traffic + that will be passed between the Shorewall system and those remote + gateways. In other words, the tunnels file deals with Local-gateway-to-remote-gateway and Remote-gateway-to-local-gateway traffic. + + + + The /etc/shorewall/zones file. An entry in + this file allows you to associated a name with the set of hosts behind + the remote gateway (or to the remote gateway itself if it is a + standalone system). + + + + The /etc/shorewall/interfaces and + /etc/shorewall/hosts files. These files are used + to associate a set of remote hosts with the zone name defined in + /etc/shorewall/zones. + + + + The /etc/shorewall/policy and + /etc/shorewall/rules files. These files are used + to define the connections that are permitted between the remote and + local hosts -- in other words, the Local-host-to-remote-host and Remote-host-to-local-host traffic. + + +
+ +
+ Eliminating the /etc/shorewall/tunnels file + + The /etc/shorewall/tunnels file provides no functionality that could + not be implemented using entries in /etc/shorewall/rules and I have + elimination of the /etc/shorewall/tunnels file as a long-term goal. The + following sections show how entries in /etc/shorewall/tunnels can be + replaced by rules for some common tunnel types. + +
+ IPSEC + + /etc/shorewall/tunnels: + +
+ #TYPE ZONE GATEWAY GATEWAY ZONE +ipsec Z1 1.2.3.4 Z2 +
+ + /etc/shorewall/rules: + +
+ #ACTION SOURCE DEST PROTO DEST SOURCE +# PORT PORT(S) +ACCEPT $FW Z1:1.2.3.4 udp 500 +ACCEPT Z1:1.2.3.4 $FW udp 500 +ACCEPT $FW Z1:1.2.3.4 50 +ACCEPT Z1:1.2.3.4 $FW 50 +ACCEPT $FW Z1:1.2.3.4 51 +ACCEPT Z1:1.2.3.4 $FW 51 +ACCEPT $FW Z2:1.2.3.4 udp 500 +ACCEPT Z2:1.2.3.4 $FW udp 500 +
+ + The "noah" option causes the rules for protocol 50 to be + eliminated. The "ipsecnat" causes UDP port 4500 to be accepted in both + directions. If no GATEWAY ZONE is given then the last two rules above + are omitted. +
+ +
+ PPTP + + /etc/shorewall/tunnels: + +
+ #TYPE ZONE GATEWAY GATEWAY ZONE +pptpserver Z1 1.2.3.4 +
+ + /etc/shorewall/rules: + +
+ #ACTION SOURCE DEST PROTO DEST SOURCE +# PORT PORT(S) + +ACCEPT Z1:1.2.3.4 $FW tcp 1723 +ACCEPT $FW Z1:1.2.3.4 47 +ACCEPT Z1:1.2.3.4 $FW 47 +
+ + Tunnel type "pptpclient" simply reverses the direction of the tcp + port 1723 rule. +
+ +
+ OpenVPN + + /etc/shorewall/tunnels: + +
+ #TYPE ZONE GATEWAY GATEWAY ZONE +openvpn:P Z1 1.2.3.4 +
+ + /etc/shorewall/rules: + +
+ #ACTION SOURCE DEST PROTO DEST SOURCE +# PORT PORT(S) + +ACCEPT Z1:1.2.3.4 $FW udp P +ACCEPT $FW Z1:1.2.3.4 udp P +
+
+
+
\ No newline at end of file