HELP NEEDED - OPENVPN NO LAN ACCESS!!***
-
Hi Guys,
Sorry for my late reply, i've been trying to scour the internet all day but haven't been able to get nowhere with it. I haven't assigned an IP to the interface as i have now deleted the interface as you mentioned it wasn't required in my setup. How would we go about NATTing the traffic as you mentioned? Would that affect anything else & is it complicated to do?
When connected my laptop is in the 10.120.0.0/24 subnet (as per the Tunnel Address Subnet) whilst my LAN is 10.1.10.0/24 but i didn't think this would make a difference? I have changed the VPN firewall rule to make Destination as the LAN subnet as you mentioned but doesn't seem to have resolved the issue. My windows 10 configuration file is below with my IP Removed:
dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-ciphers AES-256-GCM:AES-128-GCM
auth SHA1
tls-client
client
resolv-retry infinite
remote (MY IP IS HERE SO BEEN REMOVED) 1194 udp
auth-user-pass
ca pfSense-udp-1194-ca.crt
tls-auth pfSense-udp-1194-tls.key 1
remote-cert-tls serverUPDATE: I Don't seem to be able to ping ANY LAN devices now when connected to the VPN. I can see my connection in the clients list on the pfsense router however i'm unable to communicate with anything when connected. So i know the connecting is authenticating with the LDAP server and also being seen by pfSense as a connected client, but no communication is happening between my LAN devices over my VPN connection? Back to the drawing board i guess guys!
Hope somebody can help me resolve this, as it's turning into a real headache :-\
-
If you do NAT, the source address in packets coming from a VPN client and destined to a LAN device is translated to the routers LAN address. So the device sees the packets coming from its own network segment and will trust the access.
It's not difficult to enable it: Go to Firewall > NAT > Outbound, if you've never changed the NAT mode it will still be in automatic rule gen mode, so change it to hybrid mode and save this.
Then add a new NAT rule:
Interface: LAN
Source: Network - 10.120.0.0/24 (your VPN tunnel subnet)
Leave all other options at their defaults, just enter a description and save it. -
Hi Viragomann,
I did what you said with the NAT Rule however that didn't seem to work for my either. :'(
However, i just went into my OpenVPN Settings again and ticked the boxes 'Block Outside DNS' & 'Force DNS cache update'.
It now seems to be working great! Thanks again for your help with this.
-
So the problem was on hostnames?
You didn't mentioned that you use hostnames for trying to access. -
Then add a new NAT rule:
Interface: LAN
Source: Network - 10.120.0.0/24 (your VPN tunnel subnet)
Leave all other options at their defaults, just enter a description and save it.@viragomann
thanks, that solution worked for me :) -
I registered just to say thanks! What took me hours upon hours to figure out, this one thread did it for me. NATs! All the other sites failed to suggest that! They got into the weeds about tun vs. tap yadda yadda. But NATting is the fix. Thanks again!
-
@viragomann This is exactly the fix for me. I spent hours trying to figure out where the stop was.
Thank you. -
This post is deleted! -
@viragomann said in HELP NEEDED - OPENVPN NO LAN ACCESS!!***:
If you do NAT, the source address in packets coming from a VPN client and destined to a LAN device is translated to the routers LAN address. So the device sees the packets coming from its own network segment and will trust the access.
It's not difficult to enable it: Go to Firewall > NAT > Outbound, if you've never changed the NAT mode it will still be in automatic rule gen mode, so change it to hybrid mode and save this.
Then add a new NAT rule:
Interface: LAN
Source: Network - 10.120.0.0/24 (your VPN tunnel subnet)
Leave all other options at their defaults, just enter a description and save it.This solved my problem. Thank you very much
-
@viragomann 10x. Hours on google and your solution make my day. NETGATE should advertise this solution.
-
@fabiancj said in HELP NEEDED - OPENVPN NO LAN ACCESS!!***:
NETGATE should advertise this solution.
Don't agree. It's only a workaround at the end. I'd only recommend it if there is no other way to communicate with the remote device, like no gateway option on the device.
But I don't approve to use NAT to bypass firewall restictions on the destination device as lang as there is an ability to add the needed rules to it. -
Hi everyone! I just wanted to pitch in what worked for me when I ran into this problem. Perhaps this wasn't exactly the problem that any of you experienced, but it might be one more thing to consider when troubleshooting.
In my case, I unknowingly set up my VPN server to use TCP, rather than UDP. Using the wizard, I thereby automatically generated a firewall rule for that VPN server that specified TCP.
After reading through some other posts, I figured that I couldn't get access to my LAN subnet because I was trying to use TCP. So, I switched over my VPN server to UDP (and eventually figured out I also needed to change the firewall rule to UDP as well), and I finally was able to access my LAN subnet.
I don't know if this is really a solution, but it's ultimately what got my setup working how I wanted it to. Perhaps someone with more technical knowledge could explain why it wouldn't work on TCP (or why it should have).
-
What your vpn connection used be it tcp or udp had nothing to do with access to lan devices..
-
@fabiancj said in HELP NEEDED - OPENVPN NO LAN ACCESS!!***:
NETGATE should advertise this solution.
They do.. Its right there in the documentation..
I am with @viragomann really.. This shouldn't be a common sort of setup. And really shouldn't be used to circumvent some devices local firewall. It is a work around for devices that do not support a gateway - say some IP camera or something. Or if you have a scenario where a device is using a different gateway.. Which is the location in the docs where its mentioned.
Normally this would not be something needed in your typical remote vpn access.
But basic understanding of networking and the concept of how natting works in general, this sort of work around would be quite apparent.. I have suggested this sort of work around many times in many different threads.
-
@johnpoz I figured it shouldn’t matter, but is there any reason you can think of that would explain why it worked?
-
@viragomann
OMG I have been trying to get it worked since long time, thanks alot your solution worked !!! -
@viragomann You are a Genius Thanks. works perfectly for me!!
-
@viragomann Dude, thanks so much for this, i have been banging my head for 3 days now trying to get this to work
-
Hello,
The NAT workaround helped me as well. But its bugging me that its a workaround.
What would be the proper sollution to this?
My problem was with an Androind phone. I dont have much configuration options on it so would prefer to do it on the pfsense router side. -
@blyb said in HELP NEEDED - OPENVPN NO LAN ACCESS!!***:
What would be the proper sollution to this?
Proper routing and firewall rules.. If your vpn client that is remote gets a "vpn" ip of say 192.168.1.x/24 and he wants to talk to a client on your network say 192.168.2.x/24, the firewall on this 192.168.2 device should allow 192.168.1.x to talk to it on whatever ports you want it to talk to it on. And this 192.168.2 device should know to send the traffic back to pfsense to get back to the 192.168.1 device.
Source natting your vpn client so it looks like its talking to the 192.168.2 device from the 192.168.2.y pfsense IP is not proper routing or firewalling its a way to let the 192.168.2 device your trying to talk to from your vpn that your on the same network as it.. So it doesn't need to use pfsense as its default gateway or have route to use pfsense 192.168.2.y IP to get to the 192.168.1 network.
This can be a work around for something like an iot camera or something that doesn't allow you to set a gateway or routes.
But it would could be used to trick the devices firewall into thinking hey this traffic is local to you, not remote so you don't need to block it - all depends on the devices firewall settings or if it has one.
This should not be normal operation, but a method of getting something to work that can not work with normal routing and firewall rules.
