Hello!
It's been 20 years since I last looked at native IPSec on Linux. IPSec
is a nice standard
but whew it always seems difficult getting cross vendor stuff working.
Working on
this gave me flashbacks to mid 2000s seeing a network engineer at the
company I was
at spending hours on the phone with other vendors working to get IPSec
tunnels working
between our equipment and theirs. Seemed like 20-30% of his time for a
solid year was
doing that.
I'm trying to get an Ubuntu 20 system with strongSwan 5.8.2 to connect
to a
Sonicwall GroupVPN with a virtual IP.
Without a virtual IP it is working fine, I can connect and everything
works, but
I would really like to get virtual IP working if possible(see bottom for
reason
details on reason why if you really need to know).
To start off, this is not a supported Sonicwall setup, I do have a
support case,
though they say there is no documentation for setting this up, only Site
to
Site VPN is officially supported.
So here is my working configuration to connect to GroupVPN on Sonicwall
6.5.x:
(maybe this will help others as I really found no reference online on
configuring this only bits and pieces)
in charon.conf need to enable this:
accept_unencrypted_mainmode_messages = yes
ipsec.conf
--------------------------------------------------
config setup
#charondebug="ike 4, knl 4, cfg 2"
charondebug=all
conn my-sonicwall
aggressive=yes
right=MY_SONICWALL_WAN_IP
# IKEv1 only supports 1 subnet
rightsubnet=10.40.0.0/16
# with aggressive=yes rightid must be the Unique firewall identifier
on
# the Sonicwall as defined in VPN base settings, otherwise can use
# aggressive=no and rightid=MY_SONICWALL_WAN_IP
rightid=MY_SONICWALL_UNIQUE_ID
left=%defaultroute
modeconfig=push
# Sonicwall Config:
# Enabled: Require authentication of VPN clients by XAUTH
xauth_identity=MY_USERNAME
# Sonicwall WAN GroupVPN is IKEv1
keyexchange=ikev1
# xauthpsk is depreciated
# authby=xauthpsk
leftauth=psk
leftauth2=xauth
rightauth=psk
# Phase 1
# Sonicwall Config:
# DH Group: Group 14
# Encryption: AES-256
# Authentication: SHA-512
# Life time: 9000 seconds
ike=aes256-sha512-modp2048
ikelifetime=9000s
# Phase 2
# Sonicwall Config:
# Protocol: ESP
# Encryption: AES-256
# Authentication: SHA-512
# Life time: 6000 seconds
esp=aes256-sha512
# Not sure if there is an esp life time setting in strongSwan
auto=add
--------------------------------------------------
ipsec.secrets
--------------------------------------------------
MY_SONICWALL_WAN_IP %any : PSK "MY_SHARED_KEY"
MY_USERNAME : XAUTH "PASSWORD_FOR_MY_USERNAME"
--------------------------------------------------
I have enabled IKE mode configuration on the Sonicwall,
https://www.sonicwall.com/support/knowledge-base/enable-ike-mode-configuration-option-for-groupvpn-policies/170503815365224/
..and given it an IP range to assign to clients.
Everything I have read tells me I should use
leftsourceip=%config
to get a client IP address. I have seen this in this document:
https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp
as well as a sample Cisco strongSwan config:
https://www.cisco.com/c/en/us/support/docs/network-management/remote-access/117257-config-ios-vpn-strongswan-00.pdf
(and a few other places too I think)
If I put that in my configuration, while the tunnel comes up, then I
guess it goes to get an IP and I assume
it fails because it just sits there until it times out. No event logs on
the Sonicwall side of note.
strongSwan log with leftsourceip=%config
---------------------------------------------
[..]
IKE_SA my-sonicwall[8] established between
MY_CLIENT_LOCAL_IP[MY_CLIENT_LOCAL_IP]...MY_SONICWALL_WAN_IP[MY_SONICWALL_UNIQUE_ID]
scheduling reauthentication in 8391s
maximum IKE_SA lifetime 8931s
generating TRANSACTION response 2828732856 [ HASH CPA(X_STATUS) ]
sending packet: from MY_CLIENT_LOCAL_IP[4500] to
MY_SONICWALL_WAN_IP[4500] (124 bytes)
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
received packet: from MY_SONICWALL_WAN_IP[4500] to
MY_CLIENT_LOCAL_IP[4500] (140 bytes)
parsed INFORMATIONAL_V1 request 2162702153 [ HASH N(DPD) ]
generating INFORMATIONAL_V1 request 2224096280 [ HASH N(DPD_ACK) ]
sending packet: from MY_CLIENT_LOCAL_IP[4500] to
MY_SONICWALL_WAN_IP[4500] (140 bytes)
received packet: from MY_SONICWALL_WAN_IP[4500] to
MY_CLIENT_LOCAL_IP[4500] (124 bytes)
parsed INFORMATIONAL_V1 request 3541059705 [ HASH D ]
received DELETE for IKE_SA my-sonicwall[8]
deleting IKE_SA my-sonicwall[8] between
MY_CLIENT_LOCAL_IP[MY_CLIENT_LOCAL_IP]...MY_SONICWALL_WAN_IP[MY_SONICWALL_UNIQUE_ID]
initiating Aggressive Mode IKE_SA my-sonicwall[9] to MY_SONICWALL_WAN_IP
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
sending packet: from MY_CLIENT_LOCAL_IP[500] to MY_SONICWALL_WAN_IP[500]
(548 bytes)
establishing connection 'my-sonicwall' failed
HOWEVER, if I set rightsourceip=%config the Sonicwall does assign an IP
address according to the event logs and
something else happens but it still fails in the end.
Sonicwall log showing IP being assigned:
[..]pri=6 c=0 m=1219 msg="IP Address is allocated for Client " n=17
note="Policy: WAN GroupVPN; \
Allocated Address:10.20.2.220, DNS Server:0.0.0.0, WINS Server:0.0.0.0"
fw_action="NA"
(that IP is within the range I defined, and that IP is in the same
subnet as the Sonicwall LAN interface,
also the same subnet that I have configured to use for DHCP over VPN for
Sonicwall Global VPN client)
strongSwan with rightsourceip=%config
-------------------------------------------
IKE_SA atl-sonicwall[2] established between
MY_INTERNAL_IP[MY_INTERNAL_IP]...MY_SONICWALL_WAN_IP[MY_SONICWALL_UNIQUE_ID]
scheduling reauthentication in 8024s
maximum IKE_SA lifetime 8564s
generating TRANSACTION response 2677345200 [ HASH CPA(X_STATUS) ]
sending packet: from MY_INTERNAL_IP[4500] to MY_SONICWALL_WAN_IP[4500]
(124 bytes)
assigning virtual IP %any to peer 'MY_SONICWALL_UNIQUE_ID'
generating TRANSACTION request 272562686 [ HASH CPS(ADDR) ]
sending packet: from MY_INTERNAL_IP[4500] to MY_SONICWALL_WAN_IP[4500]
(124 bytes)
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
sending keep alive to MY_SONICWALL_WAN_IP[4500]
(I abort the connection with ^C here as I have no network connectivity
to the remote site)
So as you can see the message is a bit different, it immediately gets a
virtual IP. But then I don't know what
it is trying to do.
Just to compare here is the same strongSwan logs if I comment out both
leftsourceip/rightsourceip:
---------------------------------------
IKE_SA my-sonicwall[1] established between
MY_INTERNAL_IP[MY_INTERNAL_IP]...MY_SONICWALL_WAN_IP[MY_SONICWALL_UNIQUE_ID]
scheduling reauthentication in 8101s
maximum IKE_SA lifetime 8641s
generating TRANSACTION response 425255059 [ HASH CPA(X_STATUS) ]
sending packet: from MY_INTERNAL_IP[4500] to MY_SONICWALL_WAN_IP[4500]
(124 bytes)
generating QUICK_MODE request 3426884060 [ HASH SA No ID ID ]
sending packet: from MY_INTERNAL_IP[4500] to MY_SONICWALL_WAN_IP[4500]
(252 bytes)
received packet: from MY_SONICWALL_WAN_IP[4500] to MY_INTERNAL_IP[4500]
(204 bytes)
parsed QUICK_MODE response 3426884060 [ HASH SA No ID ID ]
selected proposal: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQ
CHILD_SA my-sonicwall{1} established with SPIs cded8856_i 08e001f4_o and
TS MY_INTERNAL_IP/32 === 10.40.0.0/16
generating QUICK_MODE request 3426884060 [ HASH ]
connection 'my-sonicwall' established successfully
(and VPN is working fine)
Also tried both leftsourceip=%config and rightsourceip=%config at the
same time and the results are
similar. I have tried assigning a static ip as well as leftsourceip but
it too fails same as
leftsourceip=%config.
I have gone down the rabbit hole a bit looking at xfrm, vti, disabling
install_routes, but so far nothing I
have done has changed the behavior. I am not sure if xfrm or vti
interfaces are needed in this configuration,
I suspect not as I didn't see it mentioned in the Cisco sample docs. But
I am not sure. To be clear I am
not forwarding/routing from any other system this is purely a single
client ipsec connection to a remote
network.
I have tried using the Ubuntu Network Manager to configure the
connection in the event it exposes something
that I'm not aware of, but the version I have doesn't seem to support
PSK+XAUTH so connection fails immediately.
Also tried connecting with native Android IPSec just to see if it would
work, to validate the config with
some 3rd party IPSec, but my Android 9 devices don't appear to support
customizing the ike/esp config.
At least it would be nice to get more debugging info as to what is going
on, but the settings I have tried
have had no impact.
Of course the GroupVPN works fine with the Sonicwall Windows-native
Global VPN client.
I may try getting this to work on OpenBSD, I guess just trying to
validate that my Sonicwall config
is correct by getting it working with something other than Sonicwall
Global VPN client. Though the
end goal is of course getting it working with Linux(am unsure if there
is any other IPSec solutions
than strongSwan on Linux I assume that is the most common).
thanks
nate
------------
Reason why I'd like to get Virtual IP working:
There is already a functional Sonicwall Site to Site VPN between the
systems that I need connected. Site
1 has two ISPs, and the site to site VPN is bound to ISP #2 (100Mbit)
mainly for isolation, ISP #1 at
Site 1 is 500Mbit. Site 2 has a single 1Gbps ISP. I'm wanting to test
getting more bandwidth for a
specific data replication job using Veeam to route that traffic over a
VPN on ISP #1 at Site 1(which
is the default ISP). So establishing a client->server VPN from Site 1 to
Site 2 would use the 500Mbit
ISP for this one use case. I have it working now without virtual IP but
I had to exclude the
source IP address of the system at Site 1 from the site to site VPN
before it would work. I am
assuming getting a virtual IP and using that for the VPN would eliminate
the routing funkiness of
having the same client IP appear on two different VPN segments on the
same Sonicwall at Site 2.
I also tried setting up a 2nd site to site VPN with Sonicwall between
the sites just for that one
IP address but ran into other issues (which I may be able to fix, but in
any case this client->server
VPN setup is less complex). The IPSec client system in question is a
Veeam backup server with tons
of local disk space and will be connecting to a remote Veeam server to
pull data, have configured
rate limiting within Veeam itself. There may be a better way to go about
doing this(without
provisioning more bandwidth or getting additional VPN gateways) I am not
sure.
