[SOLVED] Routing (NAT) OpenVPN traffic to (multiple) IPSec
At my office I have several IPSec VPNs running, and for some of them I'd like to be able to reach the remote endpoint also when connected via OpenVPN.
I managed to setup such routing for an IPSec endpoint, but I'm unable to replicate the configuration for a second tunnel.
On the first working tunnel I:
added a second Phase2 entry with the OpenVPN subnet, but at NAT/BINAT translation I chose Network and entered the LAN network (10.0.0.0/24)
added the route option to the OpenVPN additional config option
So I did the same for the second tunnel but it won't work. If I traceroute from OpenVPN to the second tunnel's LAN I see packets going to pfSense and next hop is WAN gateway!
An update: I noticed the working tunnel is IKEv1, while the non working one is v2. In /var/etc/ipsec/ipsec.conf for the first tunnel there are two conn, while for the second only one.
For the v1 I have the first conn with
leftsubnet = 10.0.0.0/24and a second one with```
leftsubnet = 10.0.0.0/24|10.17.17.0/24
For the v2 I just have one _conn_ with``` leftsubnet = 10.0.0.0/24,10.0.0.0/24|10.17.17.0/24
(being 10.0.0.0 the LAN and 10.17.17.0 the OpenVPN).
con8000: 18.104.22.168...22.214.171.124 IKEv1, dpddelay=10s
con8000: local: [126.96.36.199] uses pre-shared key authentication
con8000: remote: [192.168.5.2] uses pre-shared key authentication
con8000: child: 10.0.0.0/24|/0 === 10.55.0.128/25|/0 TUNNEL, dpdaction=restart
con8001: child: 10.0.0.0/24|10.17.17.0/24 === 10.55.0.128/25|/0 TUNNEL, dpdaction=restart
con7: 188.8.131.52...184.108.40.206 IKEv2, dpddelay=10s
con7: local: [220.127.116.11] uses pre-shared key authentication
con7: remote: [18.104.22.168] uses pre-shared key authentication
con7: child: 10.0.0.0/24|/0 === 192.168.14.0/24|/0 TUNNEL, dpdaction=restart
The second _child_ is missing.
Opened an issue: https://redmine.pfsense.org/issues/7187
After some more debugging and digging into pfSense sources I found out that for IKEv2 in some cases the Split connections option in P1 is required.
After enabling this option I was able to access the tunnel from the OpenVPN subnet!