OpenVPN user access to networks behind IPSEC tunnels
-
I need help with with OpenVPN users access to networks on the other side of IPSEC VPN tunnels.
Currently, 50+ IPSEC VPN tunnels are established from VPN router on LAN (10.254.0.1), plan is to transfer them all to pfSense. Diagram:
With all IPSEC tunnels behind VPN router, on pfSense I have VPN router as gateway and static routes to all A, B and C private networks over VPN router. OpenVPN user's network 10.250.1.0/24 is NATed on pfSense LAN IP 10.254.0.15, all OpenVPN users can access all networks behing VPN router tunnels.
I transfered one of those tunnels directly on pfSense, network behind it is 192.168.114.0/24, LAN users can access it, OpenPVN users cannot. How can I enable that?
-
@ivica.glavocic said in OpenVPN user access to networks behind IPSEC tunnels:
OpenVPN user's network 10.250.1.0/24 is NATed on pfSense LAN IP 10.254.0.15
This seems like the culprit. If all inbound OVPN traffic has its destination NAT'ed to pfSense's LAN address, then that traffic will then follow the static routes configured to send it downstream to "VPN router".
Can you be more specific and/or show what you mean by "static routes to all A, B and C private networks"?
-
@tinfoilmatt said in OpenVPN user access to networks behind IPSEC tunnels:
This seems like the culprit. If all inbound OVPN traffic has its destination NAT'ed to pfSense's LAN address, then that traffic will then follow the static routes configured to send it downstream to "VPN router".
Correct, all traffic for IPSEC VPN tunnel 192.168.114.0/24 on pfSense goes trough "VPN router".
Can you be more specific and/or show what you mean by "static routes to all A, B and C private networks"?
All static routes for private networks are routed via "VPN router":
10.255.255.255 /8
172.31.255.255 /12
192.168.255.255 /16I hoped that IPSEC VPN tunnel on pfSense, will have precedence over those status routes, it does not.
-
@ivica.glavocic said in OpenVPN user access to networks behind IPSEC tunnels:
I hoped that IPSEC VPN tunnel on pfSense, will have precedence over those status routes, it does not.
That's correct. 'Precedence' is not a technical term.
The most obvious solution would be to exclude subnet
192.168.114.0/24from your static routes. There's obviously a couple ways to do that.You may still need a NAT rule on WAN interface to translate incoming OVPN traffic to the applicable IPsec interface on pfSense.
-
@tinfoilmatt said in OpenVPN user access to networks behind IPSEC tunnels:
You may still need a NAT rule on WAN interface to translate incoming OVPN traffic to the applicable IPsec interface on pfSense.
I excluded subnet 192.168.114.0/24 from static routes. Can you please give me an example of NAT rule on WAN interface to translate incoming OVPN traffic to the applicable IPsec interface on pfSense? Still no reply from devices on that subnet, 10.250.0.0/22 is included in phase 2 of IPSEC tunnel, mode is Tunnel, not Routed.
-
@ivica.glavocic What's happening to OVPN traffic arriving on the WAN interface at this point? How does it appear?
-
@tinfoilmatt as visible on diagram, OpenVPN user gets IP 10.250.1.2/22, server has 10.250.0.1/22, traffic looks like it's allowed in firewall logs:
-
@tinfoilmatt found a source of the problem - on the remote side I added route trough IPSEC VPN tunnel for my OpenVpn net 10.250.0.0/22, after that I got a response from remote 192.168.114.0/24 network.
Since I have 50+ active IPSEC tunnels, adding OpenVPN subnet in all of them is going to be difficult specially since I don't control routers on the other side.
Is there a way to NAT incoming OpenVPN traffic from 10.250.0.0/22 subnet to firewall NAT IP 10.254.0.15 and then redirect it trough IPSEC tunnel on pfSense?
-
@ivica.glavocic said in OpenVPN user access to networks behind IPSEC tunnels:
Is there a way to NAT incoming OpenVPN traffic from 10.250.0.0/22 subnet to firewall NAT IP 10.254.0.15 and then redirect it trough IPSEC tunnel on pfSense?
Probably—using 'Manual Outbound NAT' 'Mode'.
I think you mean 'NAT incoming OVPN traffic to WAN interface so it can follow configured static routing to "VPN router" (i.e.,
10.254.0.1).' -
@tinfoilmatt said in OpenVPN user access to networks behind IPSEC tunnels:
I think you mean 'NAT incoming OVPN traffic to WAN interface so it can follow configured static routing to "VPN router" (i.e.,
10.254.0.1).'I meant NAT incoming OpenVPN traffic to pfSense LAN interface and then send it trough IPSEC VPN tunnel terminated on same pfSense.
-
@ivica.glavocic said in OpenVPN user access to networks behind IPSEC tunnels:
NAT incoming OpenVPN traffic to pfSense LAN interface and then send it trough IPSEC VPN tunnel terminated on same pfSense.
Why would you need to do this? What would that IPsec configuration look like? What does that mean, "IPSEC [sic] VPN tunnel terminated on same pfSense"?
-
@tinfoilmatt said in OpenVPN user access to networks behind IPSEC tunnels:
Why would you need to do this? What would that IPsec configuration look like? What does that mean, "IPSEC [sic] VPN tunnel terminated on same pfSense"?
Look at the diagram, on "VPN router" I have 50+ configured VPN tunnels that will in the future be transfered (terminated) on pfSense. All of those tunnels are configured with only my LAN subnet in phase 2, now I have to add OpenVPN subnet in every one of them and I don't control all remote VPN endpoints.
If I NAT OpenVPN subnet to pfSense LAN address and then redirect that traffic to IPSEC VPN tunnel terminated on pfSense, I won't have to reconfigure those tunnels (add OpenVPN subnet to every tunnel).
-
@ivica.glavocic I understand. I did become momentarily confused by your diagram.
So yes, 'Manual Outbound NAT' 'Mode' will allow you to translate OVPN traffic to the LAN (or the WAN) interface address, which traffic will then follow the system routing table I believe. Inbound OVPN traffic NAT'ed to the LAN (or the WAN) interface should be able to 'find' any configured IPsec tunnels that way. And you would not need to touch the remote side of any IPsec tunnels.
-
@tinfoilmatt said in OpenVPN user access to networks behind IPSEC tunnels:
So yes, 'Manual Outbound NAT' 'Mode' will allow you to translate OVPN traffic to the LAN (or the WAN) interface address, which traffic will then follow the system routing table I believe. Inbound OVPN traffic NAT'ed to the LAN (or the WAN) interface should be able to 'find' any configured IPsec tunnels that way. And you would not need to touch the remote side of any IPsec tunnels.
That's what I thought, but looks like traffic goes directly from OpenVPN tunnel network to IPSEC VPN tunnel and is not NAT-ed, although there is a manual outbound NAT rule for OpenVPN network to pfSense LAN IP.
I had an idea to use policy routing on OpenVPN interface, but what gateway do I put there? IPSEC tunnels are policy based.
-
@ivica.glavocic Check out this article from the documentation, Assigning OpenVPN Interfaces. That's one way to get OVPN traffic onto an interface that can then be NAT'ed to/from.
(This confusingly-named subsection, Allowing traffic over OpenVPN Tunnels, then becomes relevant, too.)
