OpenVPN and IPsec (IKEv2)

Business solution to host your own OpenVPN server with web management interface and bundled clients.
Post Reply
dan_moody
OpenVpn Newbie
Posts: 6
Joined: Mon Jun 14, 2021 12:32 am

OpenVPN and IPsec (IKEv2)

Post by dan_moody » Mon Jun 14, 2021 12:46 am

Hi,

I am trying to set up additional routing for my OpenVPN clients and would like to know from some experts if I am on a right track.

Currently, my VPN clients can connect to cloud OpenVPN and route to the internal subnet (10.1.10.0/24) just fine. However, we have another VPN server (on-prem) running strongswan and my approach was to add an ipsec connection from OpenVPN access server to this strongswan server.

I was able to set up this connection on OpenVPN server itself and now it can reach another private subnet (10.0.0.0/23). This only works from the openvpn server itself where the ipsec connection is established. Now, I would like my OpenVPN clients to also be able to reach hosts on this second private subnet (10.0.0.0/23). Is it possible? And if so, how do I set up routing for clients so they can reach this other subnet, which is using ipsec VPN connection.

Thanks so much in advance!

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 228
Joined: Tue Feb 16, 2021 10:41 am

Re: OpenVPN and IPsec (IKEv2)

Post by openvpn_inc » Mon Jun 14, 2021 7:54 am

Hello dan_moody,

If you use OpenVPN Access Server's capability to give VPN clients access to resources using NAT, then all resources that this Access Server itself can reach, can now also be made reachable for VPN clients. The source address for the packets from the VPN clients will be replaced by the one of the Access Server itself. Therefore no additional routing is necessary.

If however you use the routing capability, then that part is easily done on Access Server and the VPN clients by simply giving VPN clients access to these resources via routing. But the problem is that your other networks must cooperate with this. The source address of the packets from the VPN clients will have the VPN client subnet IP address kept intact. Therefore you need to make your other networks aware how to respond to these - by going through the Access Server back to the VPN client. And that requires additional routing.

Kind regards,
Johan
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

dan_moody
OpenVpn Newbie
Posts: 6
Joined: Mon Jun 14, 2021 12:32 am

Re: OpenVPN and IPsec (IKEv2)

Post by dan_moody » Mon Jun 14, 2021 1:36 pm

openvpn_inc wrote:
Mon Jun 14, 2021 7:54 am
Hello dan_moody,

If you use OpenVPN Access Server's capability to give VPN clients access to resources using NAT, then all resources that this Access Server itself can reach, can now also be made reachable for VPN clients. The source address for the packets from the VPN clients will be replaced by the one of the Access Server itself. Therefore no additional routing is necessary.

If however you use the routing capability, then that part is easily done on Access Server and the VPN clients by simply giving VPN clients access to these resources via routing. But the problem is that your other networks must cooperate with this. The source address of the packets from the VPN clients will have the VPN client subnet IP address kept intact. Therefore you need to make your other networks aware how to respond to these - by going through the Access Server back to the VPN client. And that requires additional routing.

Kind regards,
Johan

Hi Johan,

Appreciate your response. I am using NAT and my assumption was also that clients should be able to reach any subnet that OpenVPN AS can but it is not working as expected.

Here's what I get when I try to ping a host in (10.0.0.0/23) subnet:

Code: Select all

92 bytes from 172.27.232.1: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 6844   0 0000  3f  01 7415 172.27.232.2  10.0.1.50


In VPN settings, for under NAT in "Specify the private subnets to which all clients should be given access (one per line):" I have "10.0.0.0/8" so access should be allowed. Not sure what I am missing.

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 228
Joined: Tue Feb 16, 2021 10:41 am

Re: OpenVPN and IPsec (IKEv2)

Post by openvpn_inc » Mon Jun 14, 2021 1:47 pm

Hello dan_moody,

I'd suggest checking with tcpdump. For example run tcpdump -eni any icmp on the Access Server and then ping from your VPN client to the target subnet. Verify that the packet is coming in on the server via OpenVPN Access Server VPN and leaving the server via the IPSEC tunnel. See if there are any messages reported that could indicate a failure.

OpenVPN Access Server will use the operating system routing table to route packets. So if the operating system knows where to send packets, then Access Server should know too.

Kind regards,
Johan
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

dan_moody
OpenVpn Newbie
Posts: 6
Joined: Mon Jun 14, 2021 12:32 am

Re: OpenVPN and IPsec (IKEv2)

Post by dan_moody » Mon Jun 14, 2021 2:45 pm

openvpn_inc wrote:
Mon Jun 14, 2021 1:47 pm
Hello dan_moody,

I'd suggest checking with tcpdump. For example run tcpdump -eni any icmp on the Access Server and then ping from your VPN client to the target subnet. Verify that the packet is coming in on the server via OpenVPN Access Server VPN and leaving the server via the IPSEC tunnel. See if there are any messages reported that could indicate a failure.

OpenVPN Access Server will use the operating system routing table to route packets. So if the operating system knows where to send packets, then Access Server should know too.

Kind regards,
Johan
Hi Johan,

Here's what I get with tcpdump

Code: Select all

00:21:46.543113 IP 172.27.232.2 > 10.0.1.50: ICMP echo request, id 7241, seq 563, length 64
00:21:49.597564 IP openvpn-01 > 172.27.232.2: ICMP host 10.0.1.50 unreachable, length 92
how do I check if the traffic to "10.0.1.50" is leaving over IPSEC tunnel? Do I need to set a route table rule to force traffic leaving to (10.0.0.0/23) to be routed to IPSEC tunnel?

chilinux
OpenVPN Power User
Posts: 113
Joined: Thu Mar 28, 2013 8:31 am

Re: OpenVPN and IPsec (IKEv2)

Post by chilinux » Wed Jun 16, 2021 2:22 pm

What Linux distribution are you running OpenVPN AS on?

Are you running strongSwan on both servers or using the distribution provided IPSEC stack on the OpenVPN AS server?

dan_moody
OpenVpn Newbie
Posts: 6
Joined: Mon Jun 14, 2021 12:32 am

Re: OpenVPN and IPsec (IKEv2)

Post by dan_moody » Thu Jun 17, 2021 12:30 am

I am running AS on Ubuntu 18.04. Strongswan is also installed on both (remote VPN server and OpenVPN AS) to establish the IPSec tunnel from AS to strongswan VPN server.

chilinux
OpenVPN Power User
Posts: 113
Joined: Thu Mar 28, 2013 8:31 am

Re: OpenVPN and IPsec (IKEv2)

Post by chilinux » Thu Jun 17, 2021 6:49 pm

On Ubuntu 18.04, you are likely still using Linux kernel version 4.15. The Strongswan documentation indicates previous to kernel version 4.19, routing through the VPN tunnel is accomplished via VTI device. From version 4.19 and higher they switch to XFRM interfaces which is much cleaner.

Documentation you might find helpful include:
https://wiki.strongswan.org/projects/st ... based-VPNs
https://wiki.strongswan.org/projects/st ... l-Shunting

Based on that documentation, I would recommend upgrading to Ubuntu 20.04 which will supply you with kernel version 5.4 (and therefore also get you XFRM interfaces).

I would also recommend trying to configure things with OpenVPN Access Server set with NAT disabled. I think having the additional NAT rules injected into iptables by AS may be further complicating things. It might be easier to get things working without NAT.

For further help in configuring the IPSec route policies for Strongswan, I would recommend posting to the Strongswan users mailing list or asking on their IRC channel. Information for both of those are available here:
https://www.strongswan.org/support.html

dan_moody
OpenVpn Newbie
Posts: 6
Joined: Mon Jun 14, 2021 12:32 am

Re: OpenVPN and IPsec (IKEv2)

Post by dan_moody » Sat Jun 26, 2021 9:10 pm

chilinux wrote:
Thu Jun 17, 2021 6:49 pm
On Ubuntu 18.04, you are likely still using Linux kernel version 4.15. The Strongswan documentation indicates previous to kernel version 4.19, routing through the VPN tunnel is accomplished via VTI device. From version 4.19 and higher they switch to XFRM interfaces which is much cleaner.

Documentation you might find helpful include:
https://wiki.strongswan.org/projects/st ... based-VPNs
https://wiki.strongswan.org/projects/st ... l-Shunting

Based on that documentation, I would recommend upgrading to Ubuntu 20.04 which will supply you with kernel version 5.4 (and therefore also get you XFRM interfaces).

I would also recommend trying to configure things with OpenVPN Access Server set with NAT disabled. I think having the additional NAT rules injected into iptables by AS may be further complicating things. It might be easier to get things working without NAT.

For further help in configuring the IPSec route policies for Strongswan, I would recommend posting to the Strongswan users mailing list or asking on their IRC channel. Information for both of those are available here:
https://www.strongswan.org/support.html

I am on Ubuntu 18 but the kernel version is `5.4.0-1051-azure` (I am running the server in azure).

Here's my route table:

Code: Select all

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.1.1        0.0.0.0         UG    100    0        0 eth0
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
168.63.129.16   10.1.1.1        255.255.255.255 UGH   100    0        0 eth0
169.254.169.254 10.1.1.1        255.255.255.255 UGH   100    0        0 eth0
172.27.224.0    0.0.0.0         255.255.248.0   U     0      0        0 as0t0
172.27.232.0    0.0.0.0         255.255.248.0   U     0      0        0 as0t1
I am still having a hard time making it work. Any help/hints on how to troubleshoot it is appreciated.

chilinux
OpenVPN Power User
Posts: 113
Joined: Thu Mar 28, 2013 8:31 am

Re: OpenVPN and IPsec (IKEv2)

Post by chilinux » Sun Jun 27, 2021 2:49 pm

The prefer way of directing traffic to/from IPsec is not via the route table.

As explained in strongswan's documentation, when using IPsec the kernel also uses a Security Policy Database (SPD) to then generate a Security Associations (SA) database. These databases are use by the kernel in addition to the routing table.

The ipsec-tools package for Ubuntu supplies a setkey command which can be used to show and manually manipulate these databases. However, the way you really should get entries added to the SPD is via the ipsec.conf in which you put the left/right (or leftsubnet/rightsubnet) of the connections.

To see the SPD, try running:

Code: Select all

setkey spddump
If you really want to do it via route-based, I linked previously to the documentation on how to do that.

Take note that Ubuntu 18.04 supplies strongswan version 5.6.2 and iproute2 4.15.0.

To use XFRM interfaces you need to be on strongswan 5.8.0 or higher. To work with XFRM interfaces via iproute2 requires the iproute2 to be 5.1.0 or higher.

So, despite the version of the kernel azure supplies, for the versions of strongswan/iproute2 supplied by 18.04, you are going to want to focus on the documentation for VTI devices.

I looked over my own use of IPsec and I have never actually done route-based IPsec (with either VTI or XFRM) before. Instead I have always configured it via the ipsec.conf.

As far as I know, route-based IPsec doesn't replace the SPD and you still need to make sure your ipsec.conf and SPD is configured to permit the traffic.

I again recommend using the Strongswan support options to get further help with Strongswan IPsec. You could also look into contacting Canonical support.

OpenVPN AS does not prohibit you from doing what you are trying to do. Your issues seem to largely be with use of Strongswan.

dan_moody
OpenVpn Newbie
Posts: 6
Joined: Mon Jun 14, 2021 12:32 am

Re: OpenVPN and IPsec (IKEv2)

Post by dan_moody » Thu Jul 22, 2021 12:47 pm

I'm working with strongswan support atm but in case someone can spot an issue and provide some guidance based on my ipsec.conf I'd appreciate it:

Code: Select all

conn vpn-connection-ikev2
    auto=start
    type=tunnel
    right=x.x.x.x (IP of remote VPN server running strongswan)
    rightid=myremotestrongswanserver.com
    rightsubnet=10.0.0.1/23 (subnet on remote vpn server side)
    rightauth=pubkey
    leftsourceip=%config,172.27.224.0/20 (IP CIDR of OpeVPN clients)
    leftid=somename
    leftauth=pubkey
    leftcert=vpnclient.cer
    leftsubnet=0.0.0.0/0
    ike=aes256gcm16-prfsha512-ecp384!
    esp=aes256gcm16-ecp384!
    dpdaction=restart
    closeaction=restart

chilinux
OpenVPN Power User
Posts: 113
Joined: Thu Mar 28, 2013 8:31 am

Re: OpenVPN and IPsec (IKEv2)

Post by chilinux » Thu Jul 22, 2021 7:13 pm

I am shooting from the hip but I think you need a rightcert (just the public key, not the private) in addition to the leftcert.

I'm also confused by your use of leftsourceip. This should be set to a virtual IP that gets bound to the immediate server IPSEC is running on. You seem to be attempting to create an IP conflict with the IP that should or already is assigned to the OpenVPN client. I don't think leftsourceip can work that way.

Are you getting anything revealing in the IKE logs when attempting to bring the IPSEC tunnel up?

As a side question outside of the discussion of getting this working, do you control all the devices on 10.0.0.0/23? Is it possible just to restrict communications from the OpenVPN client IPs to only allow protocols over TLS to force end to end encryption? Is IPSEC really needed?

Post Reply