Asus RT-AC68U 362.3_2 OpenVPN TUN LAN setup?

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Cobra11Murderer

New Around Here
Okay so I have this configured just basic trying to get lan to become aviable over TUN for my macbook but I keep running into issues actually getting the Lan to show up ideas? I am guessing I need to put in a static route????
ths.png


any help will be greatly appreciated as I spent quite a bit of time trying to get this to work.
 

ColinTaylor

Part of the Furniture
... but I keep running into issues actually getting the Lan to show up ideas?
What do you mean by "show up"? What are you doing to verify the connection and what are you expecting to see that you are not?
 

Cobra11Murderer

New Around Here
What do you mean by "show up"? What are you doing to verify the connection and what are you expecting to see that you are not?
I can not access a local share via the vpn or even the router page 192.168.2.1 .. when I am on the vpn I check my public ip and it does match my home one (using cellular hotspot to verify this). However since my lan is on 192.168.2.0 /24 network I am guessing I am not able to see it while on the VPN.
 

eibgrad

Very Senior Member
What have you specified for the "Clients will use VPN to access" option on the OpenVPN server? In order to access the internet and LAN, it has to be set to Both. Also, network discovery will NOT work across a routed VPN, so you can't expect things that depend on it (e.g., Network Places in Windows) to work. You just have to directly reference those resources by their IP address. And sometimes personal firewalls on the target devices prevent access as well (very common w/ Windows machines).
 

Cobra11Murderer

New Around Here
That is set on both, but this is not for windows machines. But for mac's I have to have a TUN one to get it to work. Windows I have a tap setup and have no issues accessing the network shares there.

I can see its latching on to my public address which is nice, and I can ping those said devices but as far as connecting to the share via vpn its been tricky.. I can access the share without vpn locally but not over the vpn?
 

Attachments

  • Screen Shot 2021-10-07 at 10.49.07 AM.png
    Screen Shot 2021-10-07 at 10.49.07 AM.png
    206.7 KB · Views: 13
Last edited:

ColinTaylor

Part of the Furniture
Can you ping the IP address of any of the target machines? If so then this is likely to be a firewall issue as @eibgrad said.

I don't know anything about your Mac software but as you are using the same IP range on both LANs when your VPN client connects it needs to disable access to the local network otherwise it probably won't route to the other network.
 

Cobra11Murderer

New Around Here
Can you ping the IP address of any of the target machines? If so then this is likely to be a firewall issue as @eibgrad said.

I don't know anything about your Mac software but as you are using the same IP range on both LANs when your VPN client connects it needs to disable access to the local network otherwise it probably won't route to the other network.
I can ping the machines no problem :), yes turning the firewall off for the windows machines just to test worked.

Thats the thing you should my understanding be able to access your network resources when you use the VPN under TUN? this is where it gets tricky I can't seem to do so and I have a feeling a static route is needed because I can ping the gateway over OpenVPN but I can not access the webpage to it..
 

eibgrad

Very Senior Member
That is set on both, but this is not for windows machines. But for mac's I have to have a TUN one to get it to work. Windows I have a tap setup and have no issues accessing the network shares there.

When you use TAP, you are *bridged* to the remote network, so you become a proper member of that remote network. IOW, if the remote network is 192.168.1.0/24, your OpenVPN client is configured w/ an IP from that same network (e.g., 192.168.1.100). Therefore, accessing resources is typically much easier because for all intents and purposes, it's as if your OpenVPN client is plugged directly into the switch at home! Even network discovery works. But when you use TUN, you are *routed* to the remote network, meaning your OpenVPN client is on a *different* network (e.g., 10.8.0.0/24) from the remote network (and network discovery does NOT work). Now you are likely to run into personal firewall issues because the remote network sees your OpenVPN client as a potential threat. You will likely have to reconfigure those firewalls to allow access by the VPN's network, or disable their firewalls completely.

All that said, one "trick" to get around some of these personal firewall issues w/ TUN is to NAT the inbound traffic from the OpenVPN client w/ the LAN ip of the router as it's dropped on the private network, so it *appears* to the targeted device that the source IP is from the same local network.

Code:
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)

The above would need to be added as a nat-start script.

Many users find this quite useful since it avoids having to reconfigure personal firewalls.
 
Last edited:

Cobra11Murderer

New Around Here
Okay created a file using winscp under /jffs named it "nat-start" gave it execute permissions... rebooted still same thing can not see the network shares I have available? while I am on the local network I can see it all but not threw the vpn
When you use TAP, you are *bridged* to the remote network, so you become a proper member of that remote network. IOW, if the remote network is 192.168.1.0/24, your OpenVPN client is configured w/ an IP from that same network (e.g., 192.168.1.100). Therefore, accessing resources is typically much easier because for all intents and purposes, it's as if your OpenVPN client is plugged directly into the switch at home! Even network discovery works. But when you use TUN, you are *routed* to the remote network, meaning your OpenVPN client is on a *different* network (e.g., 10.8.0.0/24) from the remote network (and network discovery does NOT work). Now you are likely to run into personal firewall issues because the remote network sees your OpenVPN client as a potential threat. You will likely have to reconfigure those firewalls to allow access by the VPN's network, or disable their firewalls completely.

All that said, one "trick" to get around some of these personal firewall issues w/ TUN is to NAT the inbound traffic from the OpenVPN client w/ the LAN ip of the router as it's dropped on the private network, so it *appears* to the targeted device that the source IP is from the same local network.

Code:
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)

The above would need to be added as a nat-start script.

Many users find this quite useful since it avoids having to reconfigure personal firewalls.
 

eibgrad

Very Senior Member
The file must be under /jffs/scripts, specifically as /jffs/scripts/nat-start. You must also have "Enable JFFS custom scripts and configs" set to Yes under Administration->System.

If the file was executed and applied after the reboot, you should be able to see the rule in a dump of the nat table.

Code:
iptables -t nat -vnL POSTROUTING
 

Cobra11Murderer

New Around Here
The file must be under /jffs/scripts, specifically as /jffs/scripts/nat-start. You must also have "Enable JFFS custom scripts and configs" set to Yes under Administration->System.

If the file was executed and applied after the reboot, you should be able to see the rule in a dump of the nat table.

Code:
iptables -t nat -vnL POSTROUTING

Its under the right directory and the enabled jffs is on

** first two octets of my ip address.. but this is what I got when I ran the command you sent

22673 1992K PUPNP all -- * eth0 0.0.0.0/0 0.0.0.0/0
17715 1616K MASQUERADE all -- * eth0 !**.**.193.207 0.0.0.0/0
268 39300 MASQUERADE all -- * br0 192.168.2.0/24 192.168.2.0 /24
 

Attachments

  • y.png
    y.png
    150.8 KB · Views: 16
Last edited:

eibgrad

Very Senior Member
Something must still be wrong. It's not in the dump.

Try connecting via ssh to the router, then copy/paste the following into the terminal window. Then reboot.

Bash:
cat << "EOF" > /jffs/scripts/nat-start
#!/bin/sh
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)
EOF
chmod +x /jffs/scripts/nat-start
:
 

Cobra11Murderer

New Around Here

[email protected]:/tmp/home/root# iptables -t nat -vnL POSTROUTING


Chain POSTROUTING (policy ACCEPT 156 packets, 10772 bytes)


pkts bytes target prot opt in out source destination


0 0 SNAT all -- * br0 10.8.0.0/24 0.0.0.0/0 to:192.168.2.1


1164 83190 PUPNP all -- * eth0 0.0.0.0/0 0.0.0.0/0


944 67683 MASQUERADE all -- * eth0 !**.**.193.207 0.0.0.0/0


24 4829 MASQUERADE all -- * br0 192.168.2.0/24 192.168.2.0/24


[email protected]:/tmp/home/root# client_loop: send disconnect: Broken pipe

what I got this time after that
 

eibgrad

Very Senior Member
I and other users use this technique all the time, and it typically works just fine. And I don't know exactly what the following means.

Code:
[email protected]:/tmp/home/root# client_loop: send disconnect: Broken pipe

That appears to be an ssh login. Is that message being automatically generated at the point of the login? Because I see no command that triggered it. On the face of it, it seems unrelated to the NAT rule.
 

Cobra11Murderer

New Around Here
I and other users use this technique all the time, and it typically works just fine. And I don't know exactly what the following means.

Code:
[email protected]:/tmp/home/root# client_loop: send disconnect: Broken pipe

That appears to be an ssh login. Is that message being automatically generated at the point of the login? Because I see no command that triggered it. On the face of it, it seems unrelated to the NAT rule.

No problem I am still not able to access the drives.. im not sure as to why even after trying that command? yeah It said that after I ran the command
cat << "EOF" > /jffs/scripts/nat-start
#!/bin/sh
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)
EOF
chmod +x /jffs/scripts/nat-start
:

thats when it said broken pipe
 

eibgrad

Very Senior Member
No problem I am still not able to access the drives.. im not sure as to why even after trying that command? yeah It said that after I ran the command
cat << "EOF" > /jffs/scripts/nat-start
#!/bin/sh
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)
EOF
chmod +x /jffs/scripts/nat-start
:

thats when it said broken pipe

I still have no idea. Regardless, did the script get created? Did the rule get added? Did it fix your access problems?
 

eibgrad

Very Senior Member
Frankly, I don't quite know what to make of the situation. As long as you can ping devices, and specifically the device that's hosting the share(s) you wish to access, then it's a 100% guarantee to NOT be a routing issue. IOW, static routing is NOT the issue. Those device can be found via routing. But personal firewalls are commonly the culprit at that point. Or something else in the OpenVPN client/server configuration is amiss. But it's very difficult to pin down what that might be.

One possibility that needs to be eliminated is if the local and remote IP networks are the same. That's a common mistake. Esp. when the remote IP network is using the all-too-common 192.168.1.x or 192.168.0.x IP networks. You'll get connected to the remote network, but all your attempts to ping devices remain *local* to the OpenVPN client. And if it happens there's a device locally using say 192.168.1.100 and you ping it, it responds, given the impression that the other device across the tunnel that also happens to be using 192.168.1.100 is responding, when it isn't. Then you follow that up w/ request to access some share on that device and you obviously can't. You're NOT communicating w/ the device you think you are.

Now granted, the likelihood of this happening is slim, but it does happen from time to time, and need to be eliminated as a possibility so we don't waste more time on it.

The only other thing I can suggest at this point is that you just dump as much information as possible about your overall router configuration and post it here or on pastebin. Perhaps there's something in there that will reveal itself. Sometimes users have other things happening on the router they fail to mention, and don't suspect could be causing a conflict.

Code:
ifconfig
iptables -vnL
iptables -t nat -vnL
ip route
ip rule
ip route show table ovpnc1 2>/dev/null
ip route show table ovpnc2 2>/dev/null
ip route show table ovpnc3 2>/dev/null
ip route show table ovpnc4 2>/dev/null
ip route show table ovpnc5 2>/dev/null

Yes, that's a lot. But since I don't know what I'm looking for specifically, it's best to dump as much as possible in case it proves relevant.
 

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