How to get the remote vpn client to "see" the lan network behind the pfsense router?
-
As a test, I turned off the firewalls for the Windows client computer. Still no access to the lan behind the pfsense router.
-
On the local LAN, that relies on broadcasts. Since broadcasts are not passed through routers, you need a domain controller, such as Active Directory, to display the remote systems. You should be able to reach the remote systems, but file explorer won't display them.
-
I tried to setup a network drive, but none of the lan computers behind the pfsense router would connect. I got "Windows cannot access \computername".
It still cannot see the lan.
-
Yeah, you don't need to push routes. This works fine for me with a properly defined IPv4 Local network(s) field. Did you leave yours blank or fill it with your LAN details?
-
In the VPN/OpenVPN/Servers edit page, I checked off Redirect IPv4 Gateway to Force all client-generated IPv4 traffic through the tunnel. After I unchecked it, the IPv4 Local network field showed up. But it did have the correct lan specified, i.e. 10.3.0.0/16. I saved it anyway, but still no luck at the client computer.
The lan is still not accessible.
-
I've seen cases where a connection occurs but traffic fails to pass due to wonky encryption settings. I use:
EncryptAlgo: AES-128-CBC
NCP: AES-128-GCM, AES-128-CBC
Auth: SHA256
Compression: Adaptive LZO [Legacy style, comp-lzo adaptive]I've set this up numerous times using the pfSense OpenVPN Remote Server guide and it works every time.
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/openvpn-remote-access-server.html
-
I used the OpenVPN Wizard. I changed the Compression to your recommendation. Do I need to redo the Client Export? or the Wizard?
Update:
Redid the wizard. No go.Got this msg at the Client Export page:
Servers configured with features that require OpenVPN 2.4 will not work with OpenVPN 2.3.x or older clients. These features include: AEAD encryption such as AES-GCM, TLS Encryption+Authentication, ECDH, LZ4 Compression and other non-legacy compression choices, IPv6 DNS servers, and more.How should I be determining if I can access the lan? Is trying to make a network drive ok?
Update 2:
Followed the instructions at that link. Still no go. (the instructions specify going to System/Package Manager and finding OpenVPN Client Export, but it is not there...this is listed in Installed Packages, should a reinstall be done?) -
What client are you using, Windows or Linux? Windows OpenVPN client must be run as administrator or else it will appear to connect but not pass traffic since non-admins can't update the Windows routing table.
I don't know which version of OpenVPN client the Export dealie dishes up, but you could grab the latest 2.4.7 from https://openvpn.net/community-downloads/
How should I be determining if I can access the lan? Is trying to make a network drive ok?
I would start by pinging something on the LAN that you know respond to pings, just to test basic connectivity. The default OpenVPN rule should allow all access so you don't have to worry about that.
the instructions specify going to System/Package Manager and finding OpenVPN Client Export, but it is not there
When this package is installed, you will have a Client Export tab showing at VPN - OpenVPN - Client Export. If you install the client manually from the OpenVPN website, you just need to export the settings (.ovpn file) and not the entire client package.
-
I'm using the Windows client ver. 2.4.7-lx03 with the Client Export process.
https://i.gyazo.com/2bec3bba5de09676f7fc0571f7467450.pngI am running the OpenVPN gui as an administrator.
The lan behind the pfsense router is 10.3.0.0/16 and the tunnel network is 10.33.0.0/16. The remote Windows client is given ip 10.33.0.2. The pfsense router's ip is 10.3.0.1. From the Windows client, I can't ping 10.3.0.1. I can ping 10.33.0.1. A computer on the lan behind the pfsense router with ip 10.3.2.122 that I can ping from inside the lan, I cannot ping from the remote Windows client. Should I be able to successfully ping 10.3.2.122 from the remote Windows client?
ipconfig /all from the remote Windows client:
https://i.gyazo.com/a19bd23e7adc607701c1a23599b5af3f.pngAt the remote Windows client I am using a home Verizon Fios router. Could some setting in that be blocking the traffic?
-
and the tunnel network is 10.33.0.0/16.
You don't need a tunnel network with that much address space unless you need to have tens of thousands of connected clients. A /24 is usually good enough.
Should I be able to successfully ping 10.3.2.122 from the remote Windows client?
It depends. Windows will not respond to pings outside its local subnet, for instance. For testing, turn OFF any client firewalls and re-enable them once your tests are done and everything is working.
-
All the firewalls were/are off on the remote Windows client when I was doing that pinging from the previous post.
-
If your connected to the vpn server.. Your isp or connection method can not block stuff inside the tunnel.
3 common problems with pinging lan stuff from your vpn client.. Firewall on the dest device you trying to ping.. Dest device you trying to ping isn't using pfsense as gateway.. VPN client your using is on a local network that overlaps the dest network.. So the device has no reason to send traffic down the tunnel to get to your lan..
-
pfsense firewall ip is 10.3.0.1 with 10.3.0.0/16 for lan
An inside lan device ip is 10.3.2.122 with all of its Windows firewalls off and it can be pinged from inside the lan.
Tunnel network is 10.33.0.0/16.
The remote Windows client has tunnel network ip of 10.33.0.2 with private ip of 198.162.1.253 and its Windows firewalls are off.- Firewalls on both ends are all off.
- Device behind the pfsense firewall is using pfsense as its gateway.
Snapshot of ipconfig /all from the device behind the pfsense firewall showing it is using pfsense as its gateway:
https://i.gyazo.com/968693b3b853c1ce1cb7b25fea3b356b.png - The remote Windows VPN client is on network 10.33.0.0/16 with ip of 10.33.0.2 and the dest network is 10.3.0.0/16 with no overlap.
-
Well do a simple sniff on pfsense..
I am on vpn now..
C:\Windows\System32>ping 192.168.9.100 Pinging 192.168.9.100 with 32 bytes of data: Reply from 192.168.9.100: bytes=32 time=115ms TTL=127 Reply from 192.168.9.100: bytes=32 time=116ms TTL=127 Reply from 192.168.9.100: bytes=32 time=117ms TTL=127 Reply from 192.168.9.100: bytes=32 time=117ms TTL=127 Ping statistics for 192.168.9.100: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 115ms, Maximum = 117ms, Average = 116ms C:\Windows\System32>
There is really nothing special to do...
C:\Windows\System32>tracert -d 192.168.9.100 Tracing route to 192.168.9.100 over a maximum of 30 hops 1 113 ms 121 ms 131 ms 10.0.8.1 2 133 ms 123 ms 117 ms 192.168.9.100 Trace complete. C:\Windows\System32>
You can see that 10.0.8/24 is the tunnel.. I would suggest you sniff on your lan interface in pfsense to validate your traffic is being sent to your client.
What do you have in your openvpn firewall rules - pretty sure that defaults to an any any rule... But yeah that could be stopping you..
if that is good - then your sniff should show you sending your pings to your client..
11:28:37.949522 IP 10.0.8.100 > 192.168.9.100: ICMP echo request, id 1, seq 453, length 40 11:28:37.949828 IP 192.168.9.100 > 10.0.8.100: ICMP echo reply, id 1, seq 453, length 40 11:28:38.944374 IP 10.0.8.100 > 192.168.9.100: ICMP echo request, id 1, seq 454, length 40 11:28:38.944678 IP 192.168.9.100 > 10.0.8.100: ICMP echo reply, id 1, seq 454, length 40 11:28:39.945453 IP 10.0.8.100 > 192.168.9.100: ICMP echo request, id 1, seq 455, length 40 11:28:39.945766 IP 192.168.9.100 > 10.0.8.100: ICMP echo reply, id 1, seq 455, length 40 11:28:40.946545 IP 10.0.8.100 > 192.168.9.100: ICMP echo request, id 1, seq 456, length 40 11:28:40.946828 IP 192.168.9.100 > 10.0.8.100: ICMP echo reply, id 1, seq 456, length 40
You can see there my vpn client 10.0.8.100 pinging the client.. If you see that go out, and no answer then you know its something on the client.. If you don't see it go out - then you have problem else where - like the openvpn firewall rule?
-
OpenVPN Firewall rule:
https://i.gyazo.com/86655b3a6f05efd4e8a7c75d5ccc1632.png
My rule is the same as yours, except in the States column I have a 0 and you have a 4, i.e. 0/1.68GiB vs. 4/819.53MiBWhen you ran ping 192.168.9.100, what is the source and what is the dest.?
At the remote Windows client, none of the pings are working:
remote Windows client to device inside lan does not ping.
remote Windows client to pfsense firewall does not ping. -
My vpn clients local IP is
IPv4 Address. . . . . . . . . . . : 10.56.152.96 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 10.56.152.1
His vpn connection is that 10.0.8.100 address.. If your not seeing any states hit your rule - then you have no traffic through the rule.. Ie you have not been able to create a state.
If you can not even ping pfsense lan IP... Then you have something wrong with the client not sending hte traffic down the vpn..
Do a simple tracert from your remote client to your pfsense lan IP... Do you see it hit the other end of your vpn as first hop - like you see in mine above?
your openpvn config you put in your local network right? Or your using forcing all traffic down the vpn? That push route in your first post is not what your still trying to do? That isn't even close to correct.
lets see your route table when your vpn client is connected
route print in windows
IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 10.56.152.1 10.56.152.96 600 0.0.0.0 128.0.0.0 10.0.8.1 10.0.8.100 276 10.0.8.0 255.255.255.0 On-link 10.0.8.100 276 10.0.8.100 255.255.255.255 On-link 10.0.8.100 276 10.0.8.255 255.255.255.255 On-link 10.0.8.100 276 10.56.152.0 255.255.255.0 On-link 10.56.152.96 556 10.56.152.96 255.255.255.255 On-link 10.56.152.96 556
See the other route default route with the 128.0.0.0 mask that is what pushes traffic down my tunnel.. to get to my 192.168.9 network..
edit:
here is another way to do - just changed mine to hand out my local networksIPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 10.56.152.1 10.56.152.96 600 10.0.8.0 255.255.255.0 On-link 10.0.8.100 276 10.0.8.100 255.255.255.255 On-link 10.0.8.100 276 10.0.8.255 255.255.255.255 On-link 10.0.8.100 276 10.56.152.0 255.255.255.0 On-link 10.56.152.96 556 10.56.152.96 255.255.255.255 On-link 10.56.152.96 556 10.56.152.255 255.255.255.255 On-link 10.56.152.96 556 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.2.0 255.255.255.0 10.0.8.1 10.0.8.100 276 192.168.3.0 255.255.255.0 10.0.8.1 10.0.8.100 276 192.168.9.0 255.255.255.0 10.0.8.1 10.0.8.100 276
Where client gets specific routes down the tunnel for the networks that are behind the vpn server.. See those 192.168.9 and 192.168.2 etc.. routes
-
The remote Windows client's vpn local ip is:
Connection-specific DNS Suffix . : localdomain
Description . . . . . . . . . . . : TAP-Windows Adapter V9
Physical Address. . . . . . . . . : 00-FF-32-6F-2A-24
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.33.0.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 10.33.255.254
DNS Servers . . . . . . . . . . . : 10.3.0.1
NetBIOS over Tcpip. . . . . . . . : EnabledFor some reason there is no Default gateway.
From the remote Windows client:
C:\WINDOWS\system32>tracert -d 10.3.0.1Tracing route to 10.3.0.1 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 192.168.1.1
2 11 ms 11 ms 11 ms 10.3.0.1Trace complete.
IPv4 Route Table
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.253 50
10.33.0.0 255.255.0.0 On-link 10.33.0.2 291
10.33.0.2 255.255.255.255 On-link 10.33.0.2 291
10.33.255.255 255.255.255.255 On-link 10.33.0.2 291
(my public ip) 255.255.255.255 192.168.1.1 192.168.1.253 50
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.1.0 255.255.255.0 On-link 192.168.1.253 306
192.168.1.253 255.255.255.255 On-link 192.168.1.253 306
192.168.1.255 255.255.255.255 On-link 192.168.1.253 306
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.1.253 306
224.0.0.0 240.0.0.0 On-link 10.33.0.2 291
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.1.253 306
255.255.255.255 255.255.255.255 On-link 10.33.0.2 291My pfsense firewall's ip is 10.3.0.1
From the remote Windows client:
C:\WINDOWS\system32>ping 10.3.0.1Pinging 10.3.0.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.Ping statistics for 10.3.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), -
@axiomcs said in How to get the remote vpn client to "see" the lan network behind the pfsense router?:
Tracing route to 10.3.0.1 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 192.168.1.1
2 11 ms 11 ms 11 ms 10.3.0.1Sure looks like your hitting something on your local network where your vpn client is that using 10.3.0.1 ;)
Since 192.168.1.1 is not your vpn tunnel... And you have nothing setup in your route to send it down your tunnel 10.33
your vpn client wouldn't have a default gateway
Connection-specific DNS Suffix . : local.lan Description . . . . . . . . . . . : TAP-Windows Adapter V9 Physical Address. . . . . . . . . : 00-FF-1F-37-23-EC DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 10.0.8.100(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Friday, October 25, 2019 12:26:30 PM Lease Expires . . . . . . . . . . : Saturday, October 24, 2020 12:26:30 PM Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 10.0.8.254 DNS Servers . . . . . . . . . . . : 192.168.9.253 192.168.9.253 NetBIOS over Tcpip. . . . . . . . : Enabled
See your trace your hitting 192.168.1.1 trying to get to 10.3.0.1 - not down the tunnel.
You need to on pfsense set vpn to send everything down the tunnel - or you need to tell the server which networks are local so it will hand that to the clients.
-
All of the IPv4 traffic was/is being forced thru the tunnel:
https://i.gyazo.com/2d3e8b70252a79664e1cb094497baa65.png -
No its not.. Not per the route table you listed...
You can see from your freaking tracert that trying to 10.3.0.1 hit your 192.168.1.1 IP.. That might be what you have it set for... But that is not what is happening..