Client connects, but no access to LAN. Take a peek at my configs? :)
I've spent a good deal of time on this but am a bit new to pFsense and OpenVPN. Any help is greatly appreciated.
I can connect a client to the OpenVPN server, and I can ping the default gateway, but cannot ping or access any other LAN resources. I have ensured that firewall rules are allowing traffic through the VPN. Here are my configs:
keepalive 10 60
local (our WAN IP is here)
server 172.16.31.0 255.255.255.0
auth-user-pass-verify /var/etc/openvpn/server1.php via-env
management /var/etc/openvpn/server1.sock unix
push "route 172.16.0.0 255.255.0.0"
push "dhcp-option DOMAIN ourdomain.local"
push "dhcp-option DNS 172.16.0.2"
push "dhcp-option DNS 172.16.0.3"
tls-auth /var/etc/openvpn/server1.tls-auth 0
remote (our WAN IP) 1194 udp
verify-x509-name "OurServerCert" name
tls-auth firewall-udp-1194-testvpnuser-tls.key 1
What am I doing wrong here?
That all looks OK. I also use a summarised route in the "Local Network/s" field that points to all my internal network space behind the server, so I believe 172.16.0.0/16 should work OK, even though the tunnel is inside that at 172.16.31.0/24
I would do "route print" on the (Windows?) client and make sure the 172.16.0.0/16 route is there.
Then check that the device in the LAN does not have a firewall blocking you (e.g. some Windows firewall settings will allow access by other systems in the same subnet, but not from outside).
Then start doing packet capture at each point to see where the packets appear and disappear (Diagnostics menu).
Thank you Phil,
Yes, I am testing this with a Windows client. I have disabled the Windows firewall for testing purposes.
A screenshot of the IPV4 routes are attached. It says that there is a route for 172.16.0.0 but points it to the gateway of 172.16.31.5. Shouldn't this gateway be the pfsense (172.16.0.1)?
Also, when you say that you use a summarized route, do you mean that you explicitly define each subnet of your internal network in that field? EG: 172.16.0.0/16, 172.16.1.0/24, 172.16.2.0/24 et cetera?
Finally, when I am looking at packet captures on the pfsense side of things, should I be looking at packets coming over the WAN, or the OpenVPN tunnel itself?
The gateway from the client side should be an address at the other end of the tunnel network. You would think 172.16.31.1, but OpenVPN internally chops up the tunnel into /30 pieces (chunks of 4 addresses). The first client gets ".6" and talks back to ".5" like in your route print output.
By "summarised route" I mean that 172.16.0.0/16 covers all the addresses from 172.16.0.0 to 172.16.255.255 in one go. If you have lots of LAN subnets inside that then it saves you bothering to list them all separately.
I didn't ask at first - what is your actual LAN subnet/s?
Because you can't use the whole of 172.16.0.0/16 on LAN then also reuse part of it, 172.16.31.0/24 again as a tunnel network.
I see what you mean about the gateway. I am currently using 172.16.0-30 for our LAN subnets. So I picked the next in line available for the OpenVPN range. It shouldn't be conflicting with anything else on the network.
After running wireshark on the windows client, and packet capture via pfsense for the OpenVPN tunnel and WAN it appears that traffic is flowing through to the LAN okay. However, when I look at the ARP table on pfsense, it is unaware of the OpenVPN client's IP or MAC.
Do I need to do something related to Proxy ARP here?
If you are confused, why don't you simply disable the /30 nonsense? (I don't even know why that topology 30 BS is the default.)
And no, you do NOT need any proxy ARP or similar nonsense either.
P.S. Would strongly suggest to move the whole OVPN subnet out of the 172.16/12 range used on LAN. Use 10/8 or 192.168/16 instead.
Well, that was it. After switching the OVPN subnet to an arbitrary 192.168.xxx.0/24 subnet the traffic is flowing properly. Thank you so much for your help.