What's new

OpenVPN won’t connect from LAN

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Khadanja

Senior Member
OpenVPN server running and I can connect from outside the LAN but not from inside. Don’t really have any use for it but I’m just curious and also would like it it connect as when I get home logs are full of errors as my phone keeps trying to connect since it was connected to VPN when I was outside. Don’t really want to remember to disconnect so it would be good to be able to connect from LAN too.
If I choose TCP it works from inside LAN but I thought UDP is better and why won't it work with UDP?
 
Last edited:
If it's only effecting UDP connections it sounds like this problem with NAT loopback. Try disabling NAT acceleration and see if it now works. John applied a fix for this problem in his firmware.
 
Are we talking about a routed (tun) or bridged (tap) OpenVPN tunnel here?

It makes no sense to be using the OpenVPN server *internally*. I understand why someone would do it from the perspective of NAT loopback, which is to avoid having to reconfigure the client when moving back and forth between the home and remotely. But a VPN is an entirely different beast than your typical port forwarded service. It's changing the routing tables! And depending on how you've configured the tunnel, you can end up having the same network accessible on *both* sides of the tunnel! And now you have a routing ambiguity. This is why I tell users to NOT test their OpenVPN configurations while *inside* the same network as the OpenVPN server. At best, it's meaningless since you're probably being routed outside the tunnel anyway. At worst, it won't work at all. IMO, this is just one of those services that's never going to consistently play nice w/ NAT loopback given its nature.
 
If it's only effecting UDP connections it sounds like this problem with NAT loopback. Try disabling NAT acceleration and see if it now works. John applied a fix for this problem in his firmware.
tried that still won't work over UDP. Also what does this mean - could not determine ipv4/ipv6 protocol. using af_inet
Also this shows in logs when it doesn't connect -
May 5 08:41:34 RT-AC68U-20E0 ovpn-server1[793]: 192.168.1.4:55832 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:192.168.1.4:55832
 
I had the same issue, workaround was to add below to the OpenVPN custom configuration. After that you have to restart the server.

local <your DDNS hostname>
 
I had the same issue, workaround was to add below to the OpenVPN custom configuration. After that you have to restart the server.

local <your DDNS hostname>

But that defeats the purpose of the OP wanting to NOT have to reconfigure anything as he moves between home and remotely. All the above does is move the required change from the client to the server. Once he hits the road, he has to reconfigure the server again. You might as well leave the server as-is and just reconfigure the client.

Only way I could see this helping if perhaps the OP is the only one using the OpenVPN server and has several devices he need to reconfigures on the client side. This would reduce the number of changes from several (clients) to one (server). But he stills ends up making changes, somewhere.
 
Last edited:
OpenVPN server running and I can connect from outside the LAN but not from inside. Don’t really have any use for it but I’m just curious and also would like it it connect as when I get home logs are full of errors as my phone keeps trying to connect since it was connected to VPN when I was outside. Don’t really want to remember to disconnect so it would be good to be able to connect from LAN too.
If I choose TCP it works from inside LAN but I thought UDP is better and why won't it work with UDP?
Works here with my rt-ax88u through UDP.
 
But that defeats the purpose of the OP wanting to NOT have to reconfigure anything as he moves between home and remotely. All the above does is move the required change from the client to the server. Once he hits the road, he has to reconfigure the server again. You might as well leave the server as-is and just reconfigure the client.

Only way I could see this helping if perhaps the OP is the only one using the OpenVPN server and has several devices he need to reconfigures on the client side. This would reduce the number of changes from several (clients) to one (server). But he stills ends up making changes, somewhere.
Mmmhhh, it works for me, after applying that one-time change on the server side I can connect remotely and from LAN without changing any configuration on the client side.
 
To the extent anyone has it working w/ NAT loopback (udp, tcp, or both), I hope you have a powerful router, because as most ppl know these days, OpenVPN places a particularly hard hit on your performance since has to run in user-space rather than the kernel. On top of that, in this given scenario, you take *twice* the hit since it requires *both* the OpenVPN client and server to be operational! Then add in the encryption, perhaps lack of hardware-assisted crypto (AES-NI), and well…, it just doesn't make a whole lot of sense to be leaving any client bound to the VPN *locally* merely to avoid having to turn off the VPN on the client. Not unless you're jumping in and out the house all day long. As I said, OpenVPN (like any VPN) is NOT just another service like FTP, RDP, etc. It's a *heavy* service that you want to avoid invoking unless given no choice.

Heck, I'm so paranoid these days, I don't even run my OpenVPN server when I'm NOT remote for security reasons. I run it off a separate router, w/ a smart wifi-enabled AC plug so I can turn it ON only when I actually need it! Otherwise, it spends 99.9% of its life OFF.

But if that's what ppl insist on doing, to each his own I suppose.
 
Last edited:
Mmmhhh, it works for me, after applying that one-time change on the server side I can connect remotely and from LAN without changing any configuration on the client side.

Ahh, I think I see the difference here. I was assuming you bound it to the local network, but I see now it you bound it to the WAN. Normally it's bound to *all* network interfaces. So that's probably why it works. You never give it the chance to be bound to the LAN.

But as I said above, I can't see keeping any client bound to the VPN locally merely to avoid reconfiguration. Not unless you're talking about some extraordinary situation.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top