Asus RT-AC86U (merlin 384.14_2) / VPN server / Clients do not access to LAN devices

[Sébastien GEOFFROY]

Hi all,

I configured out VPN server on my Asus router (Merlin fw).
I exported openvpn file from it and then I imported this file to my Android smartphone (openvpn client installed).

Connection is ok but when launching apps to connect to some of my LAN devices (cam, asus router app,..), I'm not able to have those app working (connexion ko).

I suppose it's something related to proxy or route settings. I tried to add a static route but I lost connection to my router (I had to reset it and reinstall firmware...I suppose I did something wrong).

My infra is :

ISP router (192.168.0.1 / wifi off / Asus router set up as DMZ host) ---> Asus Router (192.168.0.2 / 192.168.1.1) --> LAN devices (192.168.1.0/24)

Can you please help me in making my VPN configuration working ?

Regards.
Sebastien

Here below my settings.

On client side (android smartphone connected to GSM / Wifi off):

I did the setup for port fowarding:

IFCONFIG shows:

=> Asus LAN network
br0 Link encap:Ethernet HWaddr 044:C4:46:15:A8
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:1924667 errors:0 dropped:500 overruns:0 frame:0
TX packets:7074642 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:274554439 (261.8 MiB) TX bytes:9136506930 (8.5 GiB)

=> ISP LAN
eth0 Link encap:Ethernet HWaddr 044:C4:46:15:A8
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:7038830 errors:0 dropped:3464 overruns:0 frame:0
TX packets:1732704 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9134578510 (8.5 GiB) TX bytes:262497817 (250.3 MiB)

=> VPN VLAN
tun21 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 -00
inet addr:10.8.0.1 P-t-P:10.8.0.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP PROMISC MULTICAST MTU:1500 Metric:1
RX packets:431 errors:0 dropped:0 overruns:0 frame:0
TX packets:477 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:71519 (69.8 KiB) TX bytes:127536 (124.5 KiB)

ROUTE shows:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 * 255.255.255.0 U 0 0 0 tun21
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.0.1 * 255.255.255.255 UH 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 br0

IPTABLE stuff (what I did):
iptables -I INPUT 2 -p udp --dport 1194 -j ACCEPT
iptables -I FORWARD -i br0 -o tun21 -j ACCEPT
iptables -I FORWARD -i tun21 -o br0 -j ACCEPT

OPENVPN config file (Asus side) :
# Automatically generated configuration
daemon ovpn-server1
topology subnet
server 10.8.0.0 255.255.255.0
proto udp
port 1194
dev tun21
txqueuelen 1000
ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC
cipher AES-128-CBC
keepalive 15 60
verb 3
push "route 192.168.1.0 255.255.255.0 vpn_gateway 500"
client-config-dir ccd
client-to-client
duplicate-cn
push "redirect-gateway def1"
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn
ca ca.crt
dh dh.pem
cert server.crt
key server.key
script-security 2
up updown.sh
down updown.sh
status-version 2
status status 5

 

[madfusker]

I don't believe you need the port forward (I never used it and can access internal clients), but you'll need to mark the packets to route to clients.

 

[madfusker]

https://r.tapatalk.com/shareLink/to...&share_fid=52425&share_type=t&link_source=app

 

[Sébastien GEOFFROY]

I don't believe you need the port forward (I never used it and can access internal clients), but you'll need to mark the packets to route to clients.

Thanks for this reply. Can you please tell me how doing that ?

 

[madfusker]

See link above, or look at my posts on how to get RDP working over the same connection you are using. You have to specify the direct IPs to mark. This could be a little different for you since I'm using VPN client on my whole network along with openVPN server to connect remotely at the same time. Maybe your setup is a bit different.

 

[Sébastien GEOFFROY]

Best is to use TAP VPN instead of TUN. With TAP all devices (vpn client and LAN) are on the same subnet.
But looks like TAP is not supported by Android smartphone (except if it is rooted).

 

[Sébastien GEOFFROY]

See link above, or look at my posts on how to get RDP working over the same connection you are using. You have to specify the direct IPs to mark. This could be a little different for you since I'm using VPN client on my whole network along with openVPN server to connect remotely at the same time. Maybe your setup is a bit different.

Your example if for RDP port... I don't know what port is used for my apps hosted on my smartphone.
What I want to do is to able communication between my smartphone (10.8.0.0/24 subnet) and all my LAN devices (192.168.1.0/24), whatever the port.

 

[elorimer]

Your setup is more complicated than mine, since my ISP modem is in bridge mode, so my 86U on the WAN side sees the internet address.

But I do not need to do anything beyond your OpenVPN settings for my clients to see the LAN devices. That is, my client connects and that "Both" setting pushes the route to the internal LAN network without any further need. My 86U lan side is the default 192.168.50.xx network, and so long as I don't have another such network in the mix, I'm ok. (The 192.168.0.xx networks and 192.168.1.xx networks are vulnerable to this.)

I think your issue might be in that manual route, and in the path between the internet and the WAN side of the 86U. Does your ISP router block VPN? Why do you need to have the ASUS router in a DMZ?

Hope that is useful.

 

[Sébastien GEOFFROY]

Hi,

My Asus router is in ISP router DMZ to avoid issues on ISP router itself.
Placing it in DMZ disable all protections/restrictions done by the ISP router for my Asus router.

 

[elorimer]

Yes, but I didn't think a DMZ worked like that. Something in it is reachable from the internet, but can't reach the LAN or the LAN reach it. So putting the router WAN side in the DMZ is why you need the additional routing instructions. But honestly, I don't have any experience with that stuff.

Have you tried putting the ISP router in bridge mode? Or perhaps just have it hand out an address to the WAN side of the router (i.e., double-NATted)?

 

[Sébastien GEOFFROY]

I'm not able to set ISP router in bridge mode (missing feature on this device).

 

[L&LD]

Did you call your ISP and ask them to do it? They may be able to remotely.

 

[madfusker]

They can do it. Just a matter of if they're willing. Otherwise tell them you want a modem only. Not router.

 

[Maverickcdn]

Best is to use TAP VPN instead of TUN. With TAP all devices (vpn client and LAN) are on the same subnet.
But looks like TAP is not supported by Android smartphone (except if it is rooted).

https://play.google.com/store/apps/details?id=it.colucciweb.vpnclientpro&hl=en_CA

Hes updated his app apparently. I have the old 'OpenVPN Client' app he developed. It works great for Android/Tap setups

 

[Dee dee]

I'm in kind of the same boat. I set it to tap and the Android openvpn app now won't connect.

I will set it back to what I had it before when i get home tonight.

Please see my pics any other ideas?

 

[Dee dee]

I downloaded the Android app specified and paid extra to enable tap.

I can connect and see the internet but now the IP it shows is my real ip(172.*.*.*) not a virtual ip from VPN (10.8.0.*).

I also wanted to route traffic through VPN client so I put 10.8.0.0/24 when it was not in tap mode but couldn't access Internet/wan.

Any idea what I need to do.

 

[Maverickcdn]

TAP setups will issue IP addresses from your regular IP pool

IE. if your network is a 172.x.x.x your VPN clients will get a 172.x.x.x address

TUN setups will issues IPs in the 10.8.0.0 spectrum

If you've successfully remote connected to your VPN with a TAP setup and you have allow client-client selected you should be able to access anything on your network and vice versa and you should have internet access through the VPN, if you google 'my ip' on the remote device it should show your home WAN IP address....

 

[faria]

try this:
Go back to Tun And change the protocol to Tcp in the vpn server page, reload the new openvpn server config onto a client device , then try to access the services or devices .

 

[jfbourne]

Has anyone solved this issue? Im still experiencing this. I cant get to any of my LAN devices when connected to VPN

 

[eibgrad]

Has anyone solved this issue? Im still experiencing this. I cant get to any of my LAN devices when connected to VPN

Given the complexity of any given OpenVPN configuration, the devil is often in the details as to why something doesn't work. But I can think of a few possible problems, ones I often see.

A common mistake is to use the all-too-common 192.168.0.x and 192.168.1.x networks for your home or business. The problem comes when the location from which you are attempting to access your OpenVPN server is already using either of those IP networks. If so, any references to those IP networks remain *local* to the OpenVPN client and are never routed over the VPN. It's far better to choose a more obscure network for your home or office and minimize the risk of creating such a conflict (e.g., 172.16.99.0/24, 10.10.88.0/24).

Another common problem is particular to Windows. By default, its firewall will only allow access by clients using the *same* private IP network. IOW, if the Windows machine is running on the 192.168.1.0/24 network, but the OpenVPN tunnel is using 10.8.0.0/24, the Windows firewall rejects it. Rather than reconfiguring the firewall on those machines, some ppl prefer to NAT the inbound traffic from the OpenVPN clients w/ the LAN ip of the router, so it *appears* to those Windows machines the client is actually on its own network (specifically, the router itself).

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

Of course, you need to substitute *your* OpenVPN server's IP network on the tunnel for 10.8.0.0/24 if it's different.

One of the oversights by the OP was not providing a dump of the firewall, both the INPUT and FORWARD chains, minimally. Because these types of problems usually come down to one of two things; routing conflicts or firewalls. By only telling us the rules he *added* (which shouldn't even be necessary), we're left to guess the actual state of the firewall. For all we know, something we're unaware of is causing the blockage.