User Tools

Site Tools


doc:howto:vpn.ipsec.site2site.openswan

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
doc:howto:vpn.ipsec.site2site.openswan [2012/08/30 15:45]
rharrison.hgf.com
doc:howto:vpn.ipsec.site2site.openswan [2013/10/28 08:30] (current)
lorema
Line 1: Line 1:
 +====== IPsec Site To Site Using Openswan ======
 +| For an overview over all existing Virtual private network (VPN)-related articles in the OpenWrt wiki, please visit [[doc/​howto/​vpn.overview]] |
 +For all those people who want to use openswan for a site to site connection here are the gory details...
 +
 +===== Background =====
 +In our office environment we use Centos on many of our internet faceing servers. In RedHat Enterprise Linux 5 the IPsec implementation was provided by racoon (KAME), userland tools, and NETKEY in the kernel. We set up our six office WAN using this and when it's up and running it seems to be stable, however adding a new site to the WAN seems to require reseting all of the IPsec server accross the WAN. This can be accomplished by killing off the racoon service and starting it again. This is not particularly helpfull. RedHat have decided to move to openswan for their Enterprise Linux 6 release as the default IPsec implementation using pluto for the userland tools but keeping with NETKEY for the kernel stack. We are now in the process of migrating all our IPsec VPN connections to Centos 6.x.
 +
 +===== Preparation =====
 +==== Background Reading ====
 +[[https://​www.openswan.org/​projects/​openswan/​|Openswan]]
 +
 +[[wp>​IPsec]] [[http://​www.linuxjournal.com/​article/​9916|Linux Journal IPsec article]] A good explanation IPsec implementations in linux. A good grounding on openSwan and openVPN with discussion about the two kernel stacks KLIPS and NETKEY as well as the userland tools pluto (openswan) and racoon (KAME). Note KLIPS is used in openWRT and NETKEY is used in RHEL 6.x / CENTOS 6.x the pecularities of this are discussed later.
 +
 +[[https://​www.openswan.org/​projects/​openswan/​|IPtables]]
 +
 +[[https://​www.openswan.org/​projects/​openswan/​|dnsmasq]]
 +
 +==== Required Packages ====
 +
 +=== Server (OpenWrt) ===
 +You need to install the openswan package
 +
 +=== Server (RHEL 6.x / Centos 6.x) ===
 +yum install openswan
 +
 +===== Installation =====
 +
 +Use the graphical package manager to install openswan
 +
 +or
 +
 +from the command prompt using [[doc:​techref:​opkg|opkg]]
 +
 +<​code>​
 +# opkg install openswan
 +</​code>​
 +
 +===== Configuration =====
 +==== OpenWrt ====
 +
 +Edit **/​etc/​ipsec.conf** file and add this to the bottom of the file. ( You may only have to uncomment the line )
 +<​code>​
 +include /​etc/​ipsec.d/​*.conf
 +</​code>​
 +
 +Edit **/​etc/​ipsec.secrets** file and add this to the bottom of the file. 
 +<​code>​
 +include /​etc/​ipsec.d/​*.secret
 +</​code>​
 +
 +These two lines allow you to create separate configuration and secret files in the **/​etc/​ipsec.d/​** directory for each connection.
 +
 +By convention it makes sense to name these files :-
 +
 +**<​connection name>​.conf**\\ ​
 +**<​connection name>​.secrets**
 +
 +==== RHEL 6.x / Centos 6.x ... any other openswan server =====
 +
 +<​code>​
 +</​code>​
 +
 +
 +==== Chap configuration ====
 +
 +
 +
 +==== DNS ====
 +
 +Connecting two private networks opens an interesting DNS challenge. The ACME DNS server does not only resolve official server names to IP addresses but also those of ACME internal servers. E.g. hobbit.acme.inc and its IP 10.1.2.42. As we have established a VPN connection we already can reach this host by its address. To get it by its name too we have to offer a name resolution in our home domain. With OpenWrt being very powerful we assume that our router has an active Dnsmasq DNS server. So we have two possibilities to resolve acme.inc addresses.
 +
 +  * **Manually**:​ Each acme.inc server and its IP address is put into the OpenWrt local hosts file. Dnsmasq will read this list and answer DNS requests for those ACME machines correctly. This should only be an option if we have a very restrictive VPN connection.
 +  * **Automatically**:​ Dnsmasq forwards requests for acme.inc through the tunnel to the ACME DNS server. This avoids double work.  ​
 +
 +DNS fowarding through VPN tunnels is almost the same as normal DNS forwarding with one exception. Dnsmasq must use the correct source interface. By default it will use the OpenWrt internet IP for it's requests but this cannot be tunneled. So just expand the Dnsmasq forward settings in LuCI with the OpenWrt internal IP address. In our scenario we wan't to reach ACME DNS at 10.1.2.250 by using our internal IP 192.168.2.82. Don't forget to add this domain on the whitelist otherwise Dnsmasq will detect rebind attacks and discard requests.
 +
 +{{:​doc:​howto:​ipsec_dns.png|}}
 +
 +
 +
 +
 +==== Start on boot ====
 +
 +To enable/​disable start on boot:
 +
 +''/​etc/​init.d/​ipsec enable'' ​ this simply creates a symlink: ''/​etc/​rc.d/​S60ipsec -> /​etc/​init.d/​ipsec''​\\
 +''/​etc/​init.d/​ipsec disable''​ this removes the symlink again\\
 +
 +
 +
 +===== Troubleshooting =====
 +If you are having problems getting the IPsec stuff to work try dropping the firewalls
 +<​code>​
 +Try `iptables -h' or '​iptables --help'​ for more information.
 +</​code>​
 +then bla bla bla
 +=== Usefull Commands ===
 +<code bash>
 +# ping -I <local internal interface | local internal ip> <remote internal ip>
 +
 +# tcpdump -i <​external interface>​
 +
 +# tcpdump -i <​internal interface>​
 +
 +# ipsec look <​connection name>
 +
 +# ipsec auto --add <​connection name>
 +
 +# ipsec auto --up <​connection name>
 +
 +# ipsec auto --down <​connection name>
 +
 +# ipsec auto --delete <​connection name>
 +
 +# route
 +
 +# ifconfig
 +
 +# ip xfrm policy
 +
 +# ip xfrm state
 +
 +
 +</​code>​
 +
 +===== Notes =====
 +  * The Project Homepage: [[http://​mumble.sourceforge.net/​]]
 +  * a very good tutorial: [[http://​www.frozentux.net/​iptables-tutorial/​iptables-tutorial.html]]
  
doc/howto/vpn.ipsec.site2site.openswan.txt · Last modified: 2013/10/28 08:30 by lorema