OVPN Server and no remote access to local network (except to router GUI)

Chuckles67

Regular Contributor
I used to be able to connect remotely into my home router VPN Server and access router GUI and network devices on the LAN DHCP Server (NAS, Mac).
e.g.: this was my post https://www.snbforums.com/threads/vpn-instructions-for-a-newbie.59478/post-670584
Unfortunately in my current setup running Merlin 386.7 I can still connect remotely into the router GUI but not to anything else on the local network.

UPDATE: I can connect to some devices - just not those behind a LAN switch (presumed faulty). There's really helpful suggestions in this thread, so leaving this up for the curious.

Current setup:
- home local network: AX-86U Merlin 386.7 running
VPN Server 1 on UDP/1194 (LAN only)
VPN Server 2 on TCP/443 (Both)
Various network devices: NAS devices x 2, Mac computer
- remote devices: Mac using Tunnelblick, iOS using OpenVPN

What still works
- web access to router GUI and ping to the router IP
- I can uses VPN Server 2 to remotely access the public internet through home network.

What does not work any more
- remote pinging and web access to local network devices (NAS/MAC) behind a LAN switch (likely faulty)

What’ve I tried:
1) checked my VPN Server settings are to Advertise DNS to Clients

2) stopped all VPN Clients (was 2x NordVPN), removed kill switch(es), and removed the VPN Director enable ticks. Note I did used to be able to have several VPN Clients running and access local network for all devices that were not routed through VPN clients.

3) tried adding policy-based routing in the VPN Director
192.168.50.0/24 10.99.0.0/24 WAN <or> 192.168.50.0/24 10.8.0.0/24 WAN
e.g.: https://www.snbforums.com/threads/s...allowed-at-same-time.66726/page-2#post-737620
192.168.50.0 0.0.0.0 WAN
e.g.: https://www.snbforums.com/threads/site-to-site-vpn-issue.66141/post-615436

Any other suggestions to restore remote access to local network through VPN Server?
 
Last edited:

eibgrad

Part of the Furniture
The fact you're running OpenVPN client (2x for that matter) at the same time as the OpenVPN server can cause issues. But before determining if that is the main culprit, when the OpenVPN clients are ALL stopped, do you still have these access problems? Because if you do, then we need to zero in on that particular situation before adding to the complexity by running multiple, concurrent OpenVPN clients at the same time. That can lead to IP conflicts between tunnels. There's even a known bug that denies access to WLAN/LAN devices via the OpenVPN server if those devices are bound to the local OpenVPN client(s). I even have a script to fix it.
 

elorimer

Very Senior Member
Hmm. Nothing changed for me after upgrading to .7. This is an inbound problem, so I guess it is good to get rid of all the VPN director (that is outbound stuff) and VPN client stuff.

So the problem looks to be pushing the route, for both VPN1 & 2, to your local LAN. Logs offer any insight?
 

elorimer

Very Senior Member

eibgrad

Part of the Furniture
FWIW, here's the script. And according to @RMerlin, there will be a fix in the next firmware to address the problem.


But again, this is only addressing a known problem when the OpenVPN client an server when running at the same time. If you have an access problem even when ONLY running the OpenVPN server by itself, then you have some other issue there.
 

eibgrad

Part of the Furniture
Like any such issue, the more details the better, including syslogs. Plus a dump of the various system data structures is going to help as well.

Code:
ifconfig
ip route show table main
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
ip rule
iptables -t nat -vnL
iptables -vnL

That's a lot, but I don't know what we're looking for at the moment either.
 

Chuckles67

Regular Contributor
The fact you're running OpenVPN client (2x for that matter) at the same time as the OpenVPN server can cause issues. But before determining if that is the main culprit, when the OpenVPN clients are ALL stopped, do you still have these access problems? Because if you do, then we need to zero in on that particular situation before adding to the complexity by running multiple, concurrent OpenVPN clients at the same time. That can lead to IP conflicts between tunnels. There's even a known bug that denies access to WLAN/LAN devices via the OpenVPN server if those devices are bound to the local OpenVPN client(s). I even have a script to fix it.
Thanks for the reply. All OpenVPN clients are stopped. All entries in VPN Director are deleted. I still have the access problems to all local network devices (except router GUI is working fine).

This is what I see when I remotely ping:

Code:
MacBookPro2020:~ $ ping 192.168.50.21
PING 192.168.50.21 (192.168.50.21): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
92 bytes from 10.16.0.1: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 a367   0 0000  3f  01 db72 10.16.0.2  192.168.50.21

92 bytes from 10.16.0.1: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 8717   0 0000  3f  01 f7c2 10.16.0.2  192.168.50.21

92 bytes from 10.16.0.1: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 7847   0 0000  3f  01 0693 10.16.0.2  192.168.50.21

Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6

The Destination Host Unreachable looks suspicious.
 
Last edited:

Chuckles67

Regular Contributor
Hmm. Nothing changed for me after upgrading to .7. This is an inbound problem, so I guess it is good to get rid of all the VPN director (that is outbound stuff) and VPN client stuff.

So the problem looks to be pushing the route, for both VPN1 & 2, to your local LAN. Logs offer any insight?
The logs during attempts to ping, Remote Desktop and web GUI access:

Code:
Jul 24 06:31:52 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xe832 (36/160)
Jul 24 06:31:52 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xe832 (36/160)
Jul 24 06:31:52 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xe832 (36/160)
Jul 24 06:31:52 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xe932 (40/160)
Jul 24 06:31:52 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xe932 (40/160)
Jul 24 06:31:52 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xe932 (40/160)
Jul 24 06:31:52 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xea32 (44/160)
Jul 24 06:31:52 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xea32 (44/160)
Jul 24 06:31:52 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xea32 (44/160)
Jul 24 06:31:52 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xeb32 (48/160)
Jul 24 06:31:52 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xeb32 (48/160)
Jul 24 06:31:52 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xeb32 (48/160)
Jul 24 06:36:40 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 98:46:0A:0D:7A:65, status: 0, reason: Unspecified reason (1)
Jul 24 06:36:40 wlceventd: wlceventd_proc_event(505): eth7: Auth 98:46:0A:0D:7A:65, status: Successful (0)
Jul 24 06:36:40 wlceventd: wlceventd_proc_event(515): eth7: ReAssoc 98:46:0A:0D:7A:65, status: Successful (0)
Jul 24 06:36:40 hostapd: eth7: STA 98:46:0a:0d:7a:65 IEEE 802.11: associated
Jul 24 06:36:40 hostapd: eth7: STA 98:46:0a:0d:7a:65 RADIUS: starting accounting session DA979CBA9269789D
Jul 24 06:36:40 hostapd: eth7: STA 98:46:0a:0d:7a:65 WPA: pairwise key handshake completed (RSN)
Jul 24 06:36:41 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind EE:7A:83:C6:94:B2, status: 0, reason: Unspecified reason (1)
Jul 24 06:36:41 wlceventd: wlceventd_proc_event(505): eth7: Auth EE:7A:83:C6:94:B2, status: Successful (0)
Jul 24 06:36:41 wlceventd: wlceventd_proc_event(515): eth7: ReAssoc EE:7A:83:C6:94:B2, status: Successful (0)
Jul 24 06:36:41 hostapd: eth7: STA ee:7a:83:c6:94:b2 IEEE 802.11: associated
Jul 24 06:36:41 hostapd: eth7: STA ee:7a:83:c6:94:b2 RADIUS: starting accounting session 49715AFF516B2FF5
Jul 24 06:36:41 hostapd: eth7: STA ee:7a:83:c6:94:b2 WPA: pairwise key handshake completed (RSN)
Jul 24 06:36:57 acsd: eth7: NONACSD channel switching to channel spec: 0xe02a (36/80)

I'm not getting much diagnostic help from this - anything suspicious here?
 

Chuckles67

Regular Contributor
I am able to ssh into the router. Various dumps to follow where XX.XX.XXX.XX replaces my IP address.
 
Last edited:

Chuckles67

Regular Contributor
Like any such issue, the more details the better, including syslogs. Plus a dump of the various system data structures is going to help as well.

Code:
ifconfig
ifconfig (link)

ip route show table main:
XX.XX.134.1 is not my WAN IP (XX.XX.XXX.XX is my WAN IP)
10.8.0.1 is OPVN server1
10.16.0.1 is OVPN server2
192.168.50.0 is local network
192.168.101.0 is guest network
Code:
[email protected]:/tmp/home/root# ip route show table main
default via XX.XX.134.1 dev eth0
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
10.16.0.0/24 dev tun22 proto kernel scope link src 10.16.0.1
XX.XX.134.0/23 dev eth0 proto kernel scope link src XX.XX.XXX.XX
XX.XX.134.1 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
192.168.50.0/24 dev br0 proto kernel scope link src 192.168.50.1
192.168.101.0/24 dev br1 proto kernel scope link src 192.168.101.1
239.0.0.0/8 dev br0 scope link
[email protected]:/tmp/home/root#

ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
Code:
[email protected]:/tmp/home/root# ip route show table ovpnc1
[email protected]:/tmp/home/root# ip route show table ovpnc2
[email protected]:/tmp/home/root# ip route show table ovpnc3
[email protected]:/tmp/home/root# ip route show table ovpnc4
[email protected]:/tmp/home/root# ip route show table ovpnc5
[email protected]:/tmp/home/root#

ip rule
Code:
[email protected]:/tmp/home/root# ip rule
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default
[email protected]:/tmp/home/root#
 
Last edited:

Chuckles67

Regular Contributor
Like any such issue, the more details the better, including syslogs. Plus a dump of the various system data structures is going to help as well.

Code:
iptables -t nat -vnL
iptables -t nat -vnL

Code:
[email protected]:/tmp/home/root# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 58037 packets, 4079K bytes)
pkts bytes target     prot opt in     out     source               destination       
2634  127K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
    3   206 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194
5905  316K GAME_VSERVER  all  --  *      *       0.0.0.0/0            XX.XX.XXX.XX     
5905  316K VSERVER    all  --  *      *       0.0.0.0/0            XX.XX.XXX.XX     
6283  389K DNSFILTER  udp  --  br+    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
  107  6848 DNSFILTER  tcp  --  br+    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53

Chain INPUT (policy ACCEPT 40706 packets, 2824K bytes)
pkts bytes target     prot opt in     out     source               destination       

Chain OUTPUT (policy ACCEPT 14046 packets, 1210K bytes)
pkts bytes target     prot opt in     out     source               destination       

Chain POSTROUTING (policy ACCEPT 13539 packets, 1156K bytes)
pkts bytes target     prot opt in     out     source               destination       
8337  524K PUPNP      all  --  *      eth0    0.0.0.0/0            0.0.0.0/0         
5853  371K MASQUERADE  all  --  *      eth0   !XX.XX.XXX.XX         0.0.0.0/0         
  603 61816 MASQUERADE  all  --  *      br0     192.168.50.0/24      192.168.50.0/24   

Chain DNSFILTER (2 references)
pkts bytes target     prot opt in     out     source               destination       
    0     0 DNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MAC 14:7D:DA:30:D1:4E to:192.168.50.1
    0     0 DNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MAC C8:3C:85:DB:41:B1 to:192.168.50.1
  500 35081 DNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MAC 98:46:0A:0D:7A:65 to:192.168.50.1
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            MAC 60:45:CB:AD:83:00
    0     0 DNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MAC 06:79:AE:E4:A5:AD to:192.168.50.1
    0     0 DNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MAC 0E:FC:D1:7F:93:AF to:192.168.50.1
5890  360K DNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            to:192.168.50.3

Chain GAME_VSERVER (1 references)
pkts bytes target     prot opt in     out     source               destination       

Chain LOCALSRV (0 references)
pkts bytes target     prot opt in     out     source               destination       

Chain MAPE (0 references)
pkts bytes target     prot opt in     out     source               destination       

Chain PCREDIRECT (0 references)
pkts bytes target     prot opt in     out     source               destination       

Chain PUPNP (1 references)
pkts bytes target     prot opt in     out     source               destination       

Chain VSERVER (1 references)
pkts bytes target     prot opt in     out     source               destination       
   27  1604 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpts:37777:37778 to:192.168.50.30
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:37777:37778 to:192.168.50.30
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpts:47777:47778 to:192.168.50.34
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:47777:47778 to:192.168.50.34
5878  314K VUPNP      all  --  *      *       0.0.0.0/0            0.0.0.0/0         

Chain VUPNP (1 references)
pkts bytes target     prot opt in     out     source               destination       
[email protected]:/tmp/home/root#

This looks a bit suspicious (see exclamation mark where XX.XX.XXX.XX is my IP)
Code:
5853  371K MASQUERADE  all  --  *      eth0   !XX.XX.XXX.XX         0.0.0.0/0
 
Last edited:

Chuckles67

Regular Contributor
iptables -vnL (link)
 

Chuckles67

Regular Contributor
I do have a USB drive connected for swap and scripts (Diversion). The last two upgrades were dirty, and I forgot to disconnect the USB drive when updating to 386.7. I'm thinking time for a fresh Merlin install including wiping the USB drive.
 

eibgrad

Part of the Furniture
I can see you have several individual devices on the WLAN/LAN that are being blocked (based on their MAC address) from accessing any outbound network interfaces. That's in the FORWARD chain of the filter table, even before the ESTABLISHED rule, so those will remain inaccessible even by remote access over the WAN or OpenVPN server. Of the five (5) devices being block, three (3) of them show hits (i.e., active blocking).

Once that hurdle is crossed, I can see that OpenVPN server #2 is configured to allow routing to ALL outbound network interfaces, although there are NO hits on that rule at this time (it's as if it's not been attempted). I can also see that OpenVPN server #1 is limited to the LAN (192.168.50.0/24), w/ plenty of hits, indicating it's working just fine.

I can also see that Parental Controls is blocking access to ALL outbound network interfaces for those on br1 (the first guest network), also based on MAC address. But at the moment, there are no hits on those rules.

So at first blush, I don't see any obvious problems. Of course, if you're trying to access any of those devices being blocked, then obviously that's going to be a problem.
 

eibgrad

Part of the Furniture
P.S. You also need to be aware of another common issue. Many devices (esp. Windows) have a same-origin policy when it comes to their own personal firewalls. They will reject access by any device from another *private* IP network other than the one on which the device is running. Again, very common w/ Windows, and I know other platforms are doing the same. That could explain why things otherwise look normal on the router, yet you have problems; it's possibly personal firewalls on the target devices blocking access.

And as far as dirty upgrades, they are a common source of *weird* and otherwise unexplainable problems. As I always say, it's a roll of the dice whether such upgrades will work. Just too many opportunities for strange interactions to take place, esp. the more AddOns you're relying on. Once things get weird, it's probably time to reset to factory defaults and reconfigure *manually* (no backup files!).
 

Chuckles67

Regular Contributor
I can see you have several individual devices on the WLAN/LAN that are being blocked (based on their MAC address) from accessing any outbound network interfaces. That's in the FORWARD chain of the filter table, even before the ESTABLISHED rule, so those will remain inaccessible even by remote access over the WAN or OpenVPN server. Of the five (5) devices being block, three (3) of them show hits (i.e., active blocking).
Thanks for taking time to look at this.

All five blocked devices are intentionally blocked via Parental Controls > Time Scheduling (these are home automation devices from Chinese brands such as Koogeek and Meross that need to be on the main network to connect to HomeKit, but I don't want to grant internet access).
 

Chuckles67

Regular Contributor
Once that hurdle is crossed, I can see that OpenVPN server #2 is configured to allow routing to ALL outbound network interfaces, although there are NO hits on that rule at this time (it's as if it's not been attempted). I can also see that OpenVPN server #1 is limited to the LAN (192.168.50.0/24), w/ plenty of hits, indicating it's working just fine.
I am using the OpenVPN server #1 and I can access the router GUI so that is working fine -but with no access to all the other local network devices.
 

Chuckles67

Regular Contributor
P.S. You also need to be aware of another common issue. Many devices (esp. Windows) have a same-origin policy when it comes to their own personal firewalls. They will reject access by any device from another *private* IP network other than the one on which the device is running. Again, very common w/ Windows, and I know other platforms are doing the same. That could explain why things otherwise look normal on the router, yet you have problems; it's possibly personal firewalls on the target devices blocking access.
Good to know - thank you. I can not connect to devices with different OS (e.g.: Seagate Linux NAS, WD Linux NAS, Mac OS) and don't use any Windows devices - anyway firewalls need checking.
 

Chuckles67

Regular Contributor
And as far as dirty upgrades, they are a common source of *weird* and otherwise unexplainable problems. As I always say, it's a roll of the dice whether such upgrades will work. Just too many opportunities for strange interactions to take place, esp. the more AddOns you're relying on. Once things get weird, it's probably time to reset to factory defaults and reconfigure *manually* (no backup files!).
Agreed - unfortunately I am remote, so will have to do a clean reset and manual reinstall of everything router-wise when I return next week.

Thanks for the suggestions and ideas.
 

eibgrad

Part of the Furniture
If it is personal firewalls causing the problem, you can ssh into the router and copy/paste the following rules.

Code:
iptables -t nat -I POSTROUTING -s $(nvram get vpn_server1_sn)/$(nvram get vpn_server1_nm) -o br0 -j SNAT --to $(nvram get lan_ipaddr)
iptables -t nat -I POSTROUTING -s $(nvram get vpn_server2_sn)/$(nvram get vpn_server2_nm) -o br0 -j SNAT --to $(nvram get lan_ipaddr)

If everything then starts working, you KNOW for certain personal firewalls are to blame.

Note, the above is NOT persistent. It will NOT survive a reboot. That would require a nat-start script. But for now, we just want to see if it helps.
 

Similar threads

Sign Up For SNBForums Daily Digest

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