[SOLVED] Routing (NAT) OpenVPN traffic to (multiple) IPSec
-
Hi.
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!
What's wrong?
Thanks
-
-
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/24
and a second one with```
leftsubnet = 10.0.0.0/24|10.17.17.0/24For 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).
And with```
ipsec statusallcon8000: 79.1.2.3...31.1.1.1 IKEv1, dpddelay=10s
con8000: local: [79.1.2.3] 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: 79.1.2.3...83.1.2.3 IKEv2, dpddelay=10s
con7: local: [79.1.2.3] uses pre-shared key authentication
con7: remote: [83.1.2.3] uses pre-shared key authentication
con7: child: 10.0.0.0/24|/0 === 192.168.14.0/24|/0 TUNNEL, dpdaction=restartThe second _child_ is missing.
-
Opened an issue: https://redmine.pfsense.org/issues/7187
-
Solved.
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!