Cannot reach LAN network via OpenVPN tun
-
Something's not adding up… you said:
I have the tunnel network set to 172.16.1.0/27
I have the IPv4 local network set to 10.0.0.0/24 (network address of my LAN)and your config shows you're not routing all traffic down the tunnel, but the routing table from your PC shows your default gateway is 10.10.1.1 and the IP of your PC is 10.10.3.196. So, your local network is NOT 10.0.0.0/24, but looks like it's probably 10.10.0.0/16.
-
You need to re-verify what your LAN subnet is and edit your config accordingly.
-
check the OpenVPN tab under Firewall -> Rules and make sure there's an any/any rule in place.
-
You do not have a Peer Certificate Revocation List listed. That will need to be configured as well.
-
-
Something's not adding up… you said:
I have the tunnel network set to 172.16.1.0/27
I have the IPv4 local network set to 10.0.0.0/24 (network address of my LAN)and your config shows you're not routing all traffic down the tunnel, but the routing table from your PC shows your default gateway is 10.10.1.1 and the IP of your PC is 10.10.3.196. So, your local network is NOT 10.0.0.0/24, but looks like it's probably 10.10.0.0/16.
-
You need to re-verify what your LAN subnet is and edit your config accordingly.
-
check the OpenVPN tab under Firewall -> Rules and make sure there's an any/any rule in place.
-
You do not have a Peer Certificate Revocation List listed. That will need to be configured as well.
LAN on the REMOTE PC is 10.10.0.0/16. I can see where that would be confusing.
-
-
This could also EASILY be a problem with your client. Is the client freshly installed on either win8 or win7?
yes.
-
Win8 requires special treatment to get it to work correctly - google for windows 8 openvpn client. You will see.
It can also happen with windows 7 that a connection seems to be established and looks green on both ends but the connection isn't used for routing traffic. This usually happens when you didn't right click the client install file and run as admin.
The remedy for that is uninstall it, then reinstall it as admin (run as admin).
Depends on which openvpn client you used. I think its always best to use the pfsense client export tool.
-
Win8 requires special treatment to get it to work correctly - google for windows 8 openvpn client. You will see.
It can also happen with windows 7 that a connection seems to be established and looks green on both ends but the connection isn't used for routing traffic. This usually happens when you didn't right click the client install file and run as admin.
The remedy for that is uninstall it, then reinstall it as admin (run as admin).
Depends on which openvpn client you used. I think its always best to use the pfsense client export tool.
This happened to me earlier. I figured that one out pretty easily. When I didn't install as admin it wouldn't set up the virtual interface correctly. I have already uninstalled and installed again running as admin.
-
Yeah - But for windows8 there is an extra hitch sometimes:
Look at very bottom of this page.
http://www.vpntutorials.com/tutorials/openvpn-client-setup-tutorial-for-windows-8/
-
The rule you show is on WAN to let the VPN client connect in - a good thing.
You also need rule/s on the OpenVPN tab to pass traffic flowing inside the tunnel from clients to the LAN…
You have also assigned an interface to one of your VPNs - called OPENVPNTAP. In the config we are discussing, I don't think that is necessary. If you have a reason to need it, then it is the thing that will need rule/s to pass traffic arriving inside the tunnel.I just added an Any/Any rule to the OpenVPN tab, as well as the openvpntap tab. I think you're right though. This is NOT being used as a TAP Bridge, so this isn't necessary.
Either way with the any any rules added, nothing changed. I just uninstalled the client and reinstalled with admin rights and then ran the GUI with admin rights to be sure.
I feel like I'm missing something stupid simple.
Yeah - But for windows8 there is an extra hitch sometimes:
Look at very bottom of this page.
http://www.vpntutorials.com/tutorials/openvpn-client-setup-tutorial-for-windows-8/
I followed that tutorial to the T. The only think I didn't do is the route-method.exe on my config file. but only because I don't have an OpenVPN config file. I used the PfSense client export.
-
strange - Is this an issue where you can reach your LAN by IP directly or is it only when relying of DNS?
-
Tick the Topology checkbox, disconnect, reconnect and try again.
P.S. Ping is NOT a good test with Windows boxes. At all. Mostly blocked.
-
What I always try to do is reach a windows share by IP - if that works pretty much anything will.
But that doesn't mean DNS will resolve correctly if there is something wrong elsewhere on the windows box.
-
strange - Is this an issue where you can reach your LAN by IP directly or is it only when relying of DNS?
I can't reach it at all. I'm not even allowing DNS over the vpn. this is all IP based trouble shooting. I cannot reach the LAN gateway, and I also cannot ping the IP addr the firewall should have in the VPN tunnel
Tick the Topology checkbox, disconnect, reconnect and try again.
P.S. Ping is NOT a good test with Windows boxes. At all. Mostly blocked.
I know windows firewall and all, but I can't even ping the gateway on the LAN interface
-
What I always try to do is reach a windows share by IP - if that works pretty much anything will.
But that doesn't mean DNS will resolve correctly if there is something wrong elsewhere on the windows box.
can't reach any shares.
-
Let me state again: Tick the Topology checkbox, disconnect, reconnect and try again.
-
Let me state again: Tick the Topology checkbox, disconnect, reconnect and try again.
I already did. It didn't work
-
I already did. It didn't work
On another note, NetBIOS is disabled by default as well (yet another checkbox). And on yet another note, turn off the Windows firewall before doing any of these tests.
-
I already did. It didn't work
On another note, NetBIOS is disabled by default as well (yet another checkbox). And on yet another note, turn off the Windows firewall before doing any of these tests.
okay, but this doesn't solve that I can't PING THE GATEWAY.
My tests include
- attempt to reach a windows share by IP - Server 2012 definitely has this and hosts on the LAN are definitely able to reach it
- RDP to the machines - RDP is DEFINITELY allowed. if I port forward over WAN I can RDP to the machines
- ping the LAN gateway - hosts on the LAN are able to do this.
- ping the machines - hosts on LAN are able to do this.
-
And you are re-exporting and reinstalling the client config after you make changes to openvpn server?
-
As said above. And in addition:
Simplify the thing for basic testing so that stupid things like "I'm not even allowing DNS over the vpn" are out of the way! Get the crappy Windows firewalls out of way as well. Make the things wide open UNTIL you can get basic things working. You can tighten things up AFTER that. Noone's interested in debugging something for days only to turn out that the issue is totally unrelated to pfSense. (And on that note, getting a sane OVPN client for testing would help as well. No, W8 is not one.)
-
As said above. And in addition:
Simplify the thing for basic testing so that stupid things like "I'm not even allowing DNS over the vpn" are out of the way! Get the crappy Windows firewalls out of way as well. Make the things wide open UNTIL you can get basic things working. You can tighten things up AFTER that. Noone's interested in debugging something for days only to turn out that the issue is totally unrelated to pfSense. (And on that note, getting a sane OVPN client for testing would help as well. No, W8 is not one.)
I feel like I should really worry about being able to ping the LAN gateway before worrying about anything else, but fine firewalls are off.
I have a win 7 client too. same deal.
-
I just got a road warrior OpenVPN going on my Win8 laptop again. It uses tunnel 10.50.80.0/24 and I get allocated 10.
4950.80.4/30 (server .5 client .6) OpenVPN manages these IP addresses inside the tunnel.
I can ping 10.50.80.1 but NOT 10.50.80.5
So I suggest you try ping 172.16.1.1 - that should work, not the .5 IP.