What's new

Asus RT-AC68U 362.3_2 OpenVPN TUN LAN setup?

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

Cobra11Murderer

Occasional Visitor
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.
 
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.
 
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).
 
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: 122
Last edited:
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.
 
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..
 
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:
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.
 
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
 
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: 130
Last edited:
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
:
 

Asus@RT-AC68U-PF:/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


Asus@RT-AC68U-PF:/tmp/home/root# client_loop: send disconnect: Broken pipe

what I got this time after that
 
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:
Asus@RT-AC68U-PF:/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.
 
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:
Asus@RT-AC68U-PF:/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
 
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?
 
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.
 
Well I looked through the dump (btw, it still contains your public IP, see the ifconfig dump specifically), and I don't see anything that would explain a lack of access to shares, or anything else for that matter.

I can tell you were NOT actively using the VPN when you made the dump, which might have been a bit better, just so I could follow the path of traffic.

It also looks like you heavily edited the VSERVER chain to remove any specific port forwards (all it shows is something is being DNAT'd, but not what). I will say that's a LOT of port forwarding, which I don't generally recommend. But it doesn't account for any of your problems.

I can also see the rule I recommended for NAT'ing inbound traffic from the tunnel as it's dumped on the private network. So that's good (but again, no actual traffic).

I can also see you have some of the guest networks enabled. I assume those are denied intranet access and are NOT hosting shares/services you need to access.

I just don't see any glaring issues that would explain your situation. As I said before, most of the time these things come down to personal firewalls. And the fact you are NOT have access issues when connected over TAP (bridged) further suggests that's the problem. Sometimes the target sees access by a foreign private network (10.8.0.0/24 in this case) as a potential threat, and blocks it by default. It might even block it from within the service itself. But that's why we added the rule to NAT that traffic over the private network (br0), just to avoid that possibility.
 
Thanks so much eibgrad

I ended up figuring it out!, so wanted to chime back in.. T-Mobile hotspot (well I have mint but still same network) is blocking or messing with OpenVPN and Wireguard.. I tried on a regular wifi network to test the connection and the drive shares.. all showed up fine :)


It's unfortunate that the carriers are still messing with this type of thing.
 

Sign Up For SNBForums Daily Digest

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