What's new

Accessing local resources behind expressvpn tunnel from openvpn server

  • 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!

ThelostIcon

Occasional Visitor
Hello, i have openvpn server1 running and working ok from outside lan, also have vpnclient1 setup with expressvpn working ok as well. Trying to acess some local resources from outside lan via openvpn server, it connects just fine, but in order to reach the local resourse, i have to remove the device from the expressvpn tunnel on the vpn director rules, is there any way i can leave the local resources (in this case some ip cams and an nvr) in the expressvpn tunnel and still access it remotely?
 
This is my vpn director rules. The screenshot was taken with the devices routed thru wan, but id like to keep the devices in the tunnel and still access them
 

Attachments

  • 20220208_013859.jpg
    20220208_013859.jpg
    61.4 KB · Views: 140
Try adding the OpenVPN server's IP tunnel as a policy rule and bind it to the WAN.

Code:
OpenVPN server <blank> 10.8.0.0/24 WAN

I have no idea if it's actually 10.8.0.0/24. I'm just using that as an example. Adjust accordingly.
 
Try adding the OpenVPN server's IP tunnel as a policy rule and bind it to the WAN.

Code:
OpenVPN server <blank> 10.8.0.0/24 WAN

I have no idea if it's actually 10.8.0.0/24. I'm just using that as an example. Adjust accordingly.
I think OP is looking for your solution from here.

 
I think OP is looking for your solution from here.


Thanks. I realize that. But as I explained more recently in that same thread, there's an alternative solution that doesn't involve scripting that might be worth considering. Esp. before we've proven this is the OP's problem.

 
Thanks. I realize that. But as I explained more recently in that same thread, there's an alternative solution that doesn't involve scripting that might be worth considering. Esp. before we've proven this is the OP's problem.

I see. Thanks for pointing out to another solution. Your earlier script is working so well I did not even look for other option.
 
I see. Thanks for pointing out to another solution. Your earlier script is working so well I did not even look for other option.

For the long run, the script probably is the better solution. You install it, it works, you forget about it. But as I said, we don't even know for sure if this is the OP's problem. I assume it is. It probably is. But until confirmed, the easier solution is to add the policy rule rather than get involved w/ scripts (which can be problematic, such as when some other script is already being used for the same event(s)). Had the OP responded before you, I would have made all this clear. But we never got that far in the conversation.
 
Thank you guy very much, added the rule on vpn director on ui cause ssh and putty scare the the bejezus out of me
 

Attachments

  • 20220208_162011.jpg
    20220208_162011.jpg
    80.6 KB · Views: 126
Thank you guy very much, added the rule on vpn director on ui cause ssh and putty scare the the bejezus out of me

Well, actually that's NOT correct. The intent was to place 10.16.0.0/24 in the *remote-ip* field, NOT the local-ip field.

Part of the problem here is how the VPN Director names these fields. IMO, it should really be source-ip (NOT local-ip) and destination-ip (NOT remote-ip). The use of local and remote assumes a specific orientation, namely, packets are being initiated from within the router and directed outwards to the internet via the WAN, VPN, or even remote OpenVPN clients of the OpenVPN server.

The problem w/ your situation is NOT that packets that originate from the internet (local-ip) can't reach the WLAN/LAN devices (remote-ip). That works just fine. The problem is that the *replies* can't make it back to the remote OpenVPN clients because those same WLAN/LAN devices have their replies bound to the local OpenVPN client (!), which does NOT contain a route to the OpenVPN server's network interface (either tun21 or tun22, depending on which server you're using). Therefore the correct solution is to specify 10.16.0.0/24 in the remote-ip of the rule, because the orientation is from the perspective of the WLAN/LAN client.

So I don't quite understand how what you did worked, unless perhaps you rebooted and it just happened that this time the OpenVPN server got started before the OpenVPN client. Or perhaps you didn't reboot and just restarted the OpenVPN client. Either way, that would avoid the problem completely, without the need for the policy rule. But of course, the point is that you can't always control which gets started first, hence the need for the policy rule.
 
Last edited:
you are absolutely correct, i did in fact restart the client just by mistake and realized it worked, it did not prior to restarting it. so if i switch the 10.16.0.0/24 to the remote ip field, i don't need to worry about which service connects first?
 
you are absolutely correct, i did in fact restart the client just by mistake and realized it worked, it did not prior to restarting it. so if i switch the 10.16.0.0/24 to the remote ip field, i don't need to worry about which service connects first?

Correct. What the rule says is that *any* attempt by a WLAN/LAN client to access that network (10.16.0.0/24) *must* go through the main routing table, where we know w/ absolutely certainty the OpenVPN server's network interface has a route, something we can NOT guarantee about the local OpenVPN client's routing table.
 
Last edited:
Correct. What the rule says is that *any* attempt by a WLAN/LAN client to access that network (10.16.0.0/24) *must* go through the main routing table, where we know w/ absolutely certainty the OpenVPN server's network interface has a route, something we can NOT guarantee about the local OpenVPN client's routing table.1
I have tried this out. Just got nordvpn and noticed if I use the client, then the server won't work and vice versa. I see the IP address to be entered is 10.16.0.0/24.
Mine shows 10.8.3.6, so I added that IP, but It doesn't seem to be working as I still can't connect to the server if the client is enabled.

Screenshot 2022-02-27 113248.jpg

Screenshot 2022-02-27 114417.jpg
 
I have tried this out. Just got nordvpn and noticed if I use the client, then the server won't work and vice versa. I see the IP address to be entered is 10.16.0.0/24.
Mine shows 10.8.3.6, so I added that IP, but It doesn't seem to be working as I still can't connect to the server if the client is enabled.

View attachment 39864
View attachment 39865

You are getting 10.8.3.6 from NordVPN. I have seen NordVPN assigned 10.8.0.x to 10.8.3.x.
What is your VPN server subnet? If it is 10.8.0.0 then you will need to change the server IP address to a different subnet. In the previous case, it uses 10.16.0.0/24. You can try this subnet in your server configuration.
 
Ok.. I think I got it to work..but not sure if this is right...
1645982900876.png


So far it works when using my iphone to connect to the network while wifi is off. I would like to all devices be protected by the vpn, but at the same time, be able to access my security cameras when not at home. Does this look ok?

Also, I have very little experience with vpns...so, my question is. Is having all devices go through the vpn make it slower?
Meaning, the more devices are connected to it the slower it gets...or it should have no impact?
 
Ok.. I think I got it to work..but not sure if this is right...
View attachment 39867

So far it works when using my iphone to connect to the network while wifi is off. I would like to all devices be protected by the vpn, but at the same time, be able to access my security cameras when not at home. Does this look ok?

Also, I have very little experience with vpns...so, my question is. Is having all devices go through the vpn make it slower?
Meaning, the more devices are connected to it the slower it gets...or it should have no impact?

The problem you're trying to solve is NOT related to this thread! That adds to the confusion.

In your case, the problem is that anything bound to the local OpenVPN client is NOT reachable over the WAN at the same time. It's one or the other, not both. By adding 192.168.1.0/24 to the VPN Director, this has the side effect of removing the router itself from the VPN, so its OpenVPN server (based on its public IP) then becomes reachable again over the WAN. The more specific rule (192.168.1.228) is pointless since the other rule includes it.

Once connected, NOW it becomes possible you will have the problem of the OP in this thread, where any WLAN/LAN devices bound to the local OpenVPN client might not be reachable to remote OpenVPN clients of your OpenVPN server. And that's due to a timing issue between the two processes, where the OpenVPN client sometimes gets connected before the OpenVPN server on bootup.
 
Thanks @eibgrad - yeah that makes sense about having 192.168.1.228 is not needed. So what is the difference between setting it to Strict and setting it to Exclusive and adding 192.168.1.0/24?
I notice if I use Strict, then the Server won't work..but If I use Exclusive and set the way I have it now, then it works...Im just confused about that because isn't Strict = all?

Screenshot 2022-02-27 125611.jpg
 
Thanks @eibgrad - yeah that makes sense about having 192.168.1.228 is not needed. So what is the difference between setting it to Strict and setting it to Exclusive and adding 192.168.1.0/24?
I notice if I use Strict, then the Server won't work..but If I use Exclusive and set the way I have it now, then it works...Im just confused about that because isn't Strict = all?

View attachment 39868

Well that's another discussion as well.

Exclusive means that *only* those WLAN/LAN clients bound to the VPN will have their DNS bound to the VPN, while all others will continue to have their DNS bound to the WAN. Strict means *all* WLAN/LAN clients will be bound to the DNS server(s) provided by the remote OpenVPN server and routed over that VPN.

In reality, it gets a bit more complicated due to how these two options are implemented. Exclusive bypasses DNSMasq, so you lose access to all its features (local name resolution, caching, ad blocking, etc.) for those bound to the VPN. OTOH, Strict continues to provide access to DNSMasq, but it has a serious flaw; it does NOT guarantee that the OpenVPN server's DNS server(s) will be used exclusively. IOW, you run a high risk of DNS leaks w/ Strict. And it's due to Strict not being properly implemented (imo). As it stands today, Strict is effectively no different than Relaxed. What I'm hoping is the developer will *remove* the ISP's DNS servers from Strict in the next release so as to remove the risk of DNS leaks.
 
Oh that's not good. I need to be able to have access to DnsMasq as I have a few settings in there that are a must for me. Yeah, I noticed if I use Exclusive, the DnsMasq features are gone and it only works on Strict...but if you're saying using Strict is not safe, then I guess I won't be able to use a vpn then :(

I am new to this kind of stuff, so I need something I can be confident is working properly and secure. I also notice I can't access my bank while connected to Nordvpn.
I've been researching and found that not all vpns work with all banks...ugh!!
 
I can't do anything about the VPN not working w/ specific websites. You may have to dedicate a device that's off the VPN for those purposes. Or else identify the public IP(s) of those institutions and route them (as remote IPs) over the WAN using routing policy.

As far as DNS leaks, the better option these days is probably to configure DoT on the WAN and set Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" to Yes. This will encrypt all your DNS and route it over the WAN while preserving access to DNSMasq. Just be sure to set Accept DNS Configuration on the VPN to Disabled.
 

Sign Up For SNBForums Daily Digest

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