Accessing multiple LANs with OpenVPN remote access
-
@brma said in Accessing multiple LANs with OpenVPN remote access:
I'd think Hybrid-NAT should work as well as the manual rules are executed before the automatically generated ones - or am I wrong?
Correct. However, the interface in that rule has to the VPN interface.
This should work with OpenVPN, so with the destination 192.168.1.0/24, however, I think, it doesn't with IPSec.
-
@viragomann said in Accessing multiple LANs with OpenVPN remote access:
Correct. However, the interface in that rule has to the VPN interface.
You're right, the interface has to be "where the traffic is coming from"
-
@awebster said in Accessing multiple LANs with OpenVPN remote access:
the interface has to be "where the traffic is coming from"
Where the traffic is going out from pfSense. Therfore it is called "outbound NAT". Effectivly it translates the source IP (S-NAT) in packets going out the specified interface, in this case, to the VPN interface IP (= vpn server or client).
-
I adapted/added the rules as suggested:
With the first try for a ping I thought "Resolved!" but I was too fast... there are two issues:
-
The forward into the other OpenVPN tunnel (Site C) seems to work after the reload of the rules for some time... then it suddenly stops (please see the image below). I checked the logs for issues with the firewall but there everything seems to be okay (what sounds logical to me because why should it work immediatelly after the reload of the rules...?)
The first traceroute works as expected. A ping afterwards does not work for whatever reason (but the states of pfsense show a connection!) and another traceroute delivers a different result - the OpenVPN server at site A is still reached whereas the one at site C is not anymore... do you have any idea what could cause this issue?
-
The outgoing NAT for the site B does not work at all... and I also checked the logs for firewall-rules blocking it... nothing... I can't imagine that there is a difference between NATting to an OpenVPN or an IPSec-tunnel... as we are already on a IP-routing level... or am I wrong?
I appreciate any comment as I am totally confused...
-
-
@brma said in Accessing multiple LANs with OpenVPN remote access:
The first traceroute works as expected. A ping afterwards does not work for whatever reason (but the states of pfsense show a connection!) and another traceroute delivers a different result - the OpenVPN server at site A is still reached whereas the one at site C is not anymore... do you have any idea what could cause this issue?
Possilby an asymmetric routing issue.
But you say, there is nothing in the firewall log? Have you enabled "Log firewall default blocks"?Basically I'd suggest to assign an interface to the site-to-site OpenVPN. Then move the firewall rule for this connection to the new interface tab and also change interface in the outbound NAT rule.
Did you restart the box at site A? Outbound NAT often only works properly after rebooting pfSense.
@brma said in Accessing multiple LANs with OpenVPN remote access:
The outgoing NAT for the site B does not work at all... and I also checked the logs for firewall-rules blocking it... nothing... I can't imagine that there is a difference between NATting to an OpenVPN or an IPSec-tunnel...
As I stated above, I don't think that will work for IPSec. However, the outbound NAT rule for site B is added to the OpenVPN interface (group). That won't work at all.
-
@viragomann: first of all, thank you for your support!
@viragomann said in Accessing multiple LANs with OpenVPN remote access:
Basically I'd suggest to assign an interface to the site-to-site OpenVPN. Then move the firewall rule for this connection to the new interface tab and also change interface in the outbound NAT rule.
This is exactly what made work the traffic to Site C!
@viragomann said in Accessing multiple LANs with OpenVPN remote access:
As I stated above, I don't think that will work for IPSec. However, the outbound NAT rule for site B is added to the OpenVPN interface (group). That won't work at all.
I adapted the NAT-outbound rule to site B according to the pattern of site C. I know you stated already that you don't think it will work for IPSec and you are right - it does not work. Can you please give me a hint why you see a difference and/or maybe an idea how I can resolve the remaining issue as well?
Once again - thanks a lot for the help provided so far! -
@brma
The proper way to connect a network (vpn tunnel pool) to a remote one across IPSec is to add a phase 2 for it, you may know. But this has to be done on both sites, however, as you mentioned you have no access to the remote endpoint. So that's no option for you.I think, I've read here that something like that should also be realizable by BiNAT/PAT in the IPSec phase 2, but never done it.
You may give it a try: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/phase-2-nat.htmlAnother possible solution is to switch the access VPN server to tap mode and bridge it to LAN. So clients get an IP out of the LAN subnet from the DHCP server. Also never done and it's not well supported here.
-
@viragomann: Thank you! I was able to resolve the issue!
For all having a similar problem, here is the solution:
First a phase two-entry needs to be created having the OpenVPN tunnel network as local network, the LAN network (which is the source network in the other IPSec phase-2 entry) as NAT/BINAT translation network and the IPSec target network.Next this entry must be placed before the original phase-2 entry so that the natting takes place before:
-
@brma
Consider that this setting translates the whole VPN tunnel network to your LAN network. So if the VPN client has the virtual IP 10.75.0.2 it is translated to 192.168.75.2, hence a LAN device using this translation IP cannot communicate with the remote network.
Therefore I suggested to use the PAT mode, where you pick an IP out of your LAN network which is not in use and set the translation to this single IP.
Concurrent connections between multiple VPN clients and the remote network will work anyway in that mode. -
@viragomann: another very valuable hint - thank you!
I adapted the configuration accordingly:
I also limited the ip-range of the DHCP-server to make sure this address cannot be assigned to anybody else.
