How to have VPN clients connect to LAN clients when the LAN default gateway is not pfSense?
-
I have PC clients successfully connecting into pfSense using OpenVPN. I can see the firewall states being created on the "OpenVPN" interface after a client connects and tries to access LAN resources, but traffic doesn't pass through.
The gateway provided to the LAN clients through pfSense DHCP is not pfSense; it is an external gateway. pfSense is in a bridge configuration, if that matters. WAN is set for no IP address and the LAN interface has the IP address.
- OpenVPN Tunnel network: 192.168.49.0/24
- LAN network: 172.16.0/24
- LAN gateway: 172.16.0.1 (external)
- pfsense LAN address: 172.16.0.2
OpenVPN clients are set to enter into the LAN interface. OpenVPN is set to funnel all traffic through the VPN, so the VPN client receives a gateway of 192.168.49.1 when connecting.
Loading Wireshark on a LAN client shows the ping packets coming in from the VPN client, but the VPN client is not receiving the ping responses.
The VPN client is able to access the web interface of pfSense just fine.
I assigned the available OpenVPN interface to OPT6 (and then renamed to VPN), and then configured a Static Route for the OpenVPN Tunnel network to the VPN_VPNV4 gateway that was added when I created the OPT6->VPN interface.
I'd appreciate any assistance on what needs to be added to my configuration.
-
@321liftoff
This route is useless. You should remove it.There are three solutions, best on top:
-
Remove pfSense from LAN and put it into a separate network segment (transit network), if your gateway router is capable to handle this. Then add a static route to the router for the OpenVPN tunnel network pointing to pfSense. On pfSense set your router as default gateway.
-
Add a static route for the OpenVPN tunnel network to each of your local devices you want to access from VPN clients and point it to pfSense LAN IP.
-
Add a masquerading rule (Outbound NAT) to pfSense to translate source addresses in packets going out on LAN into the interface address.
The latter one might be the simplest, but has the drawback that there is no way on the destination devices to determine where the traffic is originating. All packets from VPN clients seem to come from pfSense. If that is no issue for you, you may do this.
-
-
@viragomann Thank you for the options. Outbound NAT looks to be the best for my particular situation.
Below is my attempted configuration on Firewall->NAT->Outbound:
- Outbound NAT Mode: Manual Outbound NAT (I had it disabled before since I'm bridging and not routing/NAT'ing)
- Add a new mapping with the following settings
*Interface = LAN - Source = 192.168.49.0/24
- Source Port = *
- Destination = 172.16.0.0/24
- Destination Port = *
- NAT Address = "LAN address"
- NAT Port = 50000:55000
With this setup, I'm doing a ping test from the VPN client. With the NAT rule enabled and Wireshark running on the LAN client, the source IP has changed from the 192.168.49.2 (VPN client) to the LAN address of pfSense.
Unfortunately, the VPN client is not receiving the ping replies. Thoughts?
-
@321liftoff said in How to have VPN clients connect to LAN clients when the LAN default gateway is not pfSense?:
Unfortunately, the VPN client is not receiving the ping replies. Thoughts?
Check if the destination device allow access from remote. By default any OS is blocking such access by own firewall.
You can also use Diagnostic > Packet Capture to sniff the packets on LAN interface.
NAT Port = 50000:55000
Why are you restricting the port range? Better to let pfSense manage port translation.
-
@viragomann I'm okay letting pfSense manage the ports. I just leave it blank, then?
Doing a packet capture from within pfSense, I see the VPN device sending the ping with the source address being the pfSense LAN address, and I also see the LAN device responding to the ping with the destination address as the LAN address of pfSense.
I don't see ICMP making use of ports like TCP or UDP does, so does NAT not work in this instance?
-
@321liftoff
So on the remote side it seems to work as excepted.
Don't you get the reply back to the vpn client?ICMP doesn't use ports.
-
@viragomann I'll have to try again with Wireshark running on the VPN client, but the command prompt on that PC was showing a timeout.
At first glance, it seems to be an issue of translating back from the LAN subnet to the VPN Tunnel subnet.