OpenSwan IPSEC VPN
conn stephanie connection name
left=10.50.161.116 Linux machine’s IP address
leftnexthop=10.50.161.113 Linux machine’s default gateway
leftsubnet=10.50.161.116/32 Linux machine’s IP and Subnet Mask
right=184.108.40.206 SonicWALL’s WAN IP address
rightnexthop=220.127.116.11 SonicWALL’s default gateway
rightsubnet=192.168.168.0/24 Destination network (usually SonicWALL’s LAN subnet)
rightid=18.104.22.168 SonicWALL’s IKE ID VPN
Create an entry in the ipsec.secrets file:
22.214.171.124 10.50.161.116 : PSK "sonic"
Configuring a site-to-site VPN between a Sonicwall and Linux Openswan
Revision as of 20:28, 7 May 2011 by Mikealeonetti (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
I have had the fortune of having the challenge to set up a site-to-site (or BOVPN/Branch Office VPN) between a Sonicwall and Openswan. I have searched for other articles that cover this topic and found plenty of information that got me far enough to get some of it working. However, getting the whole thing working took quite some time and I found the guides to be incomplete. So for the sake of even my own remembrance, I will write a mini guide up. Of course I will link all of the guides I've used in a references section.
Just to set the stage on this, I have only tried getting this to work using Gentoo Linux but am confident it will work with other distros as well. In my experience I've had no issues or downtime with a Sonicwall<->Openswan VPN. So if you are worried about stability and incompatibility, to be honest, I've found it to work even better than a Sonicwall<->Sonicwall BOVPN. This was my experience with openswan-2.5.15 on kernel version 2.6.24.
Test network scenario
We're going to set up a network scenario with the following information:
"Left side" - The Linux server
On this side (or branch office) we have our Gentoo Linux server as the router and providing Internet for the following network. Please note that the actual setup of a Linux machine to act as a network router is out of the scope of this document.
WAN IP: 126.96.36.199
Internal subnet: 192.168.0.0/24
IP of Linux server: 192.168.0.1
WAN Iface of Linux server: eth0
"Right side" - The Sonicwall device
On this side we (or branch office) we have our Sonicwall device serving as the router and providing Internet for the following network.
WAN IP: 188.8.131.52
Internal subnet: 10.0.0.0/24
IP of Sonicwall': 10.0.0.1
Openswan side configuration
If you built your own kernel you're going to either have to include the following as modules or build them in:
Transformation user configuration interface
IP: AH transformations
IP: ESP transformations
IP: IPComp transformations
IP: IPsec tunnel mode
Usually these are found under Networking->Network Options.
If you have not built your own kernel, chances are these are already built in.
There are two configuration files you need to worry about: /etc/ipsec.conf
version 2.0 config setup # Having this option off caused issues nat_traversal=yes oe=off protostack=netkey fragicmp=no conn sonicwall # This is where you define your connexion to the Sonicwall. # You do not have to call it "Sonicwall" you can all it what # you wish. left=184.108.40.206 leftsourceip=192.168.0.1 leftsubnet=192.168.0.0/24 leftid=220.127.116.11 right=18.104.22.168 rightid=22.214.171.124 keyingtries=0 pfs=no aggrmode=yes auth=esp esp=3des-sha1 ike=3des-sha1 authby=secret keyexchange=ike rightsubnet=10.0.0.0/24 # This allows the VPN to come up automatically when openswan starts auto=start
You'll notice the rightid and the leftid above. These are what helps identify the connexion when the Openswan and the Sonicwall try to talk. Usually Sonicwalls want this value set to a Sonicwall Identifier. Well, if you haven't noticed by now your Openswan/Linux box won't have an identifier for itself. So we use the IP instead. Sonicwalls will also accept that option.
126.96.36.199 188.8.131.52 : PSK "secretpass"
In the ipsec.secrets file make sure the IPs are correct. This will be what gives the authentication password for the VPN. If your IPs change and you have to change them in the ipsec.conf file, make sure to remember to change them here to. Otherwise you'll have errors and it won't establish a connexion.
If you're doing masquerading and you have other nat rules set up in iptables it will interfere with your VPN traffic. So, you will have to set rules to allow all traffic unaffected for your VPN subnet.
# IPSec ports for opening iptables -A INPUT -p ah -j ACCEPT iptables -A INPUT -p esp -j ACCEPT iptables -A INPUT -p udp -i eth0 --dport 500 -j ACCEPT iptables -A INPUT -p udp -i eth0 --dport 4500 -j ACCEPT iptables -A INPUT -p udp -i eth0 --dport 50:58 -j ACCEPT iptables -A INPUT -p tcp -i eth0 --dport 50:58 -j ACCEPT # Allow all traffic from our Sonicwall side of the VPN in iptables -A INPUT -j ACCEPT --source 10.0.0.0/255.255.255.0 # Put a rule in to cancel out any MASQ rules that might try to take effect iptables -t nat -A POSTROUTING -j ACCEPT --destination 10.0.0.0/255.255.255.0 # Cancel out any forward rules that might be trying to take effect iptables -t nat -A PREROUTING -j ACCEPT --source 10.0.0.0/255.255.255.0
The point of the above commands is that they are placed before any other firewall rules take place that may interfere with traffic either bound to or coming from the Sonicwall VPN network. In a default scenario without any restrictions we want to leave those packets untouched. If you find your VPN traffic is still being interfered with, check your other chains to see that they aren't mangling your VPN traffic.
If you need to insert the rule above another rule, for example above a MASQ rule, use the -I command instead. For example:
iptables -t nat -I POSTROUTING 1 -j ACCEPT --destination 10.0.0.0/255.255.255.0
To put the rule first in the chain.
Sonicwall side configuration
The screenshots below are from the web interface for the Sonicwall NSA 2400.
Go to the VPN lists to add another VPN (Usually VPN->Settings on the menu).
Add a new VPN connexion (the Add button).
Note: For the above you'll need to configure address objects for the Local Networks and Remote Networks. When configuring the Remote Networks address object make sure it's the same subnet as the Left (or Openswan/Linux) side. Otherwise you will get errors.
Note: The XAUTH option was checked in one of the articles I did see. However, this will make Openswan prompt you for another password and you won't be able to establish the VPN without it. Also, if you do not want SMB traffic to pass through the VPN uncheck the NetBIOS flag.
Click the OK button to make the settings live.
Bringing up the VPN
On the Sonicwall side, in the VPN settings where it lists the VPN just make sure the Enable checkbox is checked.
On the Openswan/Linux side, run the command
If everything was done correctly you should see the little green dot on the Sonicwall's VPN list indicating that everything is okay. Some ping tests should should that you have connectivity across the VPN.
Check the system log file and grep out messages from pluto. This will give you a real time update on the progress of your IPSec connexions.
Check the Sonicwall log system.
Make sure none of your iptables rules are blocking VPN traffic (this is a big one).
Multiple subnets across the VPN
So your Sonicwall side has multiple subnets that you want to be able to reach. This is easy with Openswan. On your Sonicwall side of course configure the proper Address Objects. Then on your Openswan config do the following.
version 2.0 config setup nat_traversal=yes oe=off protostack=netkey fragicmp=no conn sonicwall left=184.108.40.206 leftsourceip=192.168.0.1 leftsubnet=192.168.0.0/24 leftid=220.127.116.11 right=18.104.22.168 rightid=22.214.171.124 keyingtries=0 pfs=no aggrmode=yes auth=esp esp=3des-sha1 ike=3des-sha1 authby=secret keyexchange=ike conn sonicwall-0network # Include the other config also=sonicwall # Our default subnet rightsubnet=10.0.0.0/24 # Make sure this one autostarts auto=start conn sonicwall-1network also=sonicwall rightsubnet=10.0.1.0/24 auto=start
Given that 10.0.1.0/24 is the other subnet behind the Sonicwall on some VLAN or something. Make sure you put in the proper firewall rules to allow all traffic to and from the second subnet as well.