Skip to content

sonicwall’s IPsec and linux

Sonicwall’s are pretty common in my ecosystem. Maybe it’s dell country, maybe it’s just all the small businesses. But Sonicwall is definitely on the windows agenda. There’s the Net-extender app which is supposed to work on linux/unix machines, but I’ve had mixed success.┬áThere’s a few open source options out there for ipsec and some┬ácome stock on most distributions. A quick search on my redhad/fedora repos gives a healthly list of options.

[root@groundsdesktop ipsec.d]# dnf search ipsec
Last metadata expiration check: 1:57:11 ago on Sun Feb 12 08:55:58 2017.
============================================= N/S Matched: ipsec =============================================
ipsec-tools.x86_64 : Tools for configuring and using IPSEC
strongswan-libipsec.i686 : Strongswan's libipsec backend
strongswan-libipsec.x86_64 : Strongswan's libipsec backend
NetworkManager-libreswan.x86_64 : NetworkManager VPN plug-in for IPsec VPN
NetworkManager-strongswan.x86_64 : NetworkManager strongSwan IPSec VPN plug-in
strongswan.i686 : An OpenSource IPsec-based VPN and TNC solution
strongswan.x86_64 : An OpenSource IPsec-based VPN and TNC solution
vpnc.x86_64 : IPSec VPN client compatible with Cisco equipment
NetworkManager-l2tp.x86_64 : NetworkManager VPN plugin for L2TP and L2TP/IPsec
racoon2.x86_64 : An implementation of key management system for IPsec
libreswan.x86_64 : IPsec implementation with IKEv1 and IKEv2 keying protocols
NetworkManager-l2tp-gnome.x86_64 : NetworkManager VPN plugin for L2TP and L2TP/IPsec - GNOME files
ike-scan.x86_64 : IKE protocol tool to discover, fingerprint and test IPsec VPN servers
[root@groundsdesktop ipsec.d]#

regular net-tools should give us enough to set up an ipsec tunnel, but I found a good amount of info concerning strongSwan and sonicwall so I went for the easier softer route. Besides, I have a real softspot for camelCase.



I found a reasonable amount of dated no longer relevant info on the web concerning setting up strongSwan and sonic wall. I just had to hash out what still works and what doesn’t. This post is more of a paste of my configs than anything. I’ll define a few things for you but you’re going to have to do the work here. This setup is for a single client to connect.

You’re best resource…

There’s a few files to touch on with openSwan. It’s no longer one config file.


Our main config is at…

[root@groundsdesktop etc]# more /etc/ipsec.conf 
# /etc/ipsec.conf - Libreswan IPsec configuration file

# Uncomment when using this configuration file with openswan
#version 2
# Manual: ipsec.conf.5

config setup
 # which IPsec stack to use, "netkey" (the default), "klips" or "mast".
 # For MacOSX use "bsd"
 # Normally, pluto logs via syslog. If you want to log to a file,
 # specify below or to disable logging, eg for embedded systems, use
 # the file name /dev/null
 # Note: SElinux policies might prevent pluto writing to a log file at
 # an unusual location.
 # Do not enable debug options to debug configuration issues!
 # plutodebug "all", "none" or a combation from below:
 # "raw crypt parsing emitting control controlmore kernel pfkey
 # natt x509 dpd dns oppo oppoinfo private".
 # Note: "private" is not included with "all", as it can show confidential
 # information. It must be specifically specified
 # examples:
 # plutodebug="control parsing"
 # plutodebug="all crypt"
 # Again: only enable plutodebug when asked by a developer
 # Enable core dumps (might require system changes, like ulimit -C)
 # This is required for abrtd to work properly
 # Note: SElinux policies might prevent pluto writing the core at
 # unusual locations
 # NAT-TRAVERSAL support
 # exclude networks used on server side by adding %v4:!a.b.c.0/24
 # It seems that T-Mobile in the US and Rogers/Fido in Canada are
 # using 25/8 as "private" address space on their wireless networks.
 # This range has never been announced via BGP (at least upto 2015)

# For example connections, see your distribution's documentation directory,
# or
# There is also a lot of information in the manual page, "man ipsec.conf"
# It is best to add your IPsec connections as separate files in /etc/ipsec.d/
include /etc/ipsec.d/*.conf

This is my kind of package. Well documented with plenty of comments. Now you could just throw your configs in here, but I like following the rules. We’ll adhere to that last line. Everything concerning our new connection will live in /etc/ipsec.d/; the main config will include anything names .conf in that directory, so create you site config file with whatever name you want. Shoot for something like this…

 left=<internal IP of remote host>
 leftid=<leave blank>
 right=<WAN IP of sonicwall>
 rightsubnet=<internal LAN subnet written linux way, X.X.X.X/XX>
 rightid=<WAN IP of sonicwall>

This is really all you need in your site config. We’re assuming the connecting node will have a static IP here. A subnet value could also be used instead of the ip of the remote host. The last field is going to point the config to the *.secret file to grab the PSK. Again, name the secret file whatever you want and place it in the same directory, so long as it ends in .secret;

The secret file isn’t going to contain much for just one vpn config. Just one line containing…

<what was in your left=> <what was in your right=> : PSK "<your PSK>"

and example config would look like : PSK "155D4FFPS658AA8"

that’s it.


On the sonicwall end of things, since you can’t define something directly in your configuration, you have to first create a network object. This should be the specific local IP of the connecting host or it’s subnet. We’re going to reference the value of this object in VPN policies. Once you do that, I’ll make things easy for you and give you pictures.




Be sure to match the ipsec policies and protocols used on both ends. I shouldn’t have to tell you this.



That should give you everything you need. Stay tuned and I’ll get a cert made for this connection so we can beef this up a little.