Help needed to make a router on LAN accessible remotely

[ColinTaylor]

I think to get any further with this you'll need to run Wireshark on a PC that's having problems an see what the incoming traffic looks like.

 

[andres99]

I launched the official OpenVPN client on a PC in the remote (192.168.0.0) network. The OpenVPN client connected and could ping 192.168.10.7 but not e.g. 192.168.10.1. When I look at the traffic, using Wireshark, I see that Echo (ping) requests from 192.168.8.2 (or, hypothetically 10.8.0.2) to 192.168.10.1 just remain unreplied. Echo (ping) requests from 192.168.8.2 (or, hypothetically 10.8.0.2) to 192.168.10.7 get replied.

Before that there was an ARP broadcast, described by Wireshark as "Who has 192.168.8.1? Tell 192.168.8.2", and an ARP reply "192.168.8.1 is at <the respective MAC>".

Otherwise, what should I be looking for in Wireshark more specifically?

As for now, devices in the 192.168.0.0 network can ping the ASUS (192.168.10.7), one printer in the same network (192.168.10.8) and apparently ping the devices in the OpenVPN network (192.168.8.1 and 192.168.8.2).

Or is there a way to achieve my objective (make an ASUS RT-AC68U router serve WiFi and OpenVPN from the same LAN as the primary router) by some other method of physical connection / mode, perhaps using the WAN port of the Asus?

 

[ColinTaylor]

Otherwise, what should I be looking for in Wireshark more specifically?

I would look at a Wireshark capture running on one of the target devices in 192.168.10.x, not the device running the VPN client. My belief is that the pings are reaching their target but not returning for some reason.

Using a single-device VPN client (as you did) rather that using another router will simplify troubleshooting because NATing an entire subnet though the VPN adds a whole extra level of complexity.

I suspect that this is basically working as you said before that you could ping "some devices". If it weren't configured correctly you wouldn't be able to ping any remote clients.

 

[andres99]

I tested with Wireshark on a PC (192.168.10.12) while the PC’s firewall was turned off. That PC did not receive any ping packets from the OpenVPN network (from a PC 192.168.8.2 running the OpenVPN client). At the same time, test pings that I made directly from devices in the 192.168.10.0 network (including Linksys 192.168.10.1 and Asus 192.168.10.7) were always visible in Wireshark.

I found this old thread: https://www.snbforums.com/threads/static-routes-not-working-as-expected-in-asuswrt-merlin.11429/

However, that is a bit complicated for my level of skills. If any of that is pertinent, what solution should I try from there?

EDIT: After an unsuccessful static route addition (and later removal - just for testing) and a reboot of the Asus router (192.168.10.7), the OpenVPN still connects but now I cannot ping anything in the 192.168.10.0 network from a remote device connected to the OpenVPN network. Although the settings are exactly the same as before.

EDIT2: The pingability of 192.168.10.7 and 192.168.10.8 returned after I had to force the OpenVPN router (192.168.10.7) to synchronise time from an NTP server.

 

[ColinTaylor]

I found this old thread: https://www.snbforums.com/threads/static-routes-not-working-as-expected-in-asuswrt-merlin.11429/

However, that is a bit complicated for my level of skills. If any of that is pertinent, what solution should I try from there?

Maybe SSH into the router (192.168.10.7) and issue the following command. The output might give us a clue to something.

iptables-save

EDIT2: The pingability of 192.168.10.7 and 192.168.10.8 returned after I had to force the OpenVPN router (192.168.10.7) to synchronise time from an NTP server.

192.168.10.8 ?

From the PC (192.168.10.12) and with the VPN tunnel connected, can you ping 192.168.10.7 and 192.168.8.1 and 192.168.8.2 ?

 

[andres99]

Maybe SSH into the router (192.168.10.7) and issue the following command. The output might give us a clue to something.

iptables-save

/tmp/home/root# iptables-save
# Generated by iptables-save v1.4.15 on Sat Nov 30 06:00:50 2019
*raw
:PREROUTING ACCEPT [62661:7171578]
:OUTPUT ACCEPT [44796:58942521]
COMMIT
# Completed on Sat Nov 30 06:00:50 2019
# Generated by iptables-save v1.4.15 on Sat Nov 30 06:00:50 2019
*nat
:PREROUTING ACCEPT [776:55021]
:INPUT ACCEPT [715:44553]
:OUTPUT ACCEPT [131:10343]
:POSTROUTING ACCEPT [131:10343]
-A PREROUTING -p udp -m udp --dport 1194 -j ACCEPT
-A PREROUTING -p tcp -m tcp --dport 1194 -j ACCEPT
COMMIT
# Completed on Sat Nov 30 06:00:50 2019
# Generated by iptables-save v1.4.15 on Sat Nov 30 06:00:50 2019
*mangle
:PREROUTING ACCEPT [10628:1404903]
:INPUT ACCEPT [10540:1391217]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7694:4917973]
:POSTROUTING ACCEPT [7694:4917973]
-A PREROUTING -i tun21 -j MARK --set-xmark 0x1/0x7
-A FORWARD -p udp -m udp --dport 5060 -j MARK --set-xmark 0x1/0x7
-A FORWARD -p tcp -m tcp --dport 5060 -j MARK --set-xmark 0x1/0x7
COMMIT
# Completed on Sat Nov 30 06:00:51 2019
# Generated by iptables-save v1.4.15 on Sat Nov 30 06:00:51 2019
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [7695:4918461]
:ACCESS_RESTRICTION - [0:0]
:DNSFILTER_DOT - [0:0]
:FUPNP - [0:0]
:INPUT_ICMP - [0:0]
:NSFW - [0:0]
:OVPN - [0:0]
:PControls - [0:0]
:PTCSRVLAN - [0:0]
:PTCSRVWAN - [0:0]
:SECURITY - [0:0]
:default_block - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
:other2wan - [0:0]
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j logaccept
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j logaccept
-A INPUT -p icmp -j logaccept
-A INPUT -j logdrop
-A FORWARD -m state --state RELATED,ESTABLISHED -j logaccept
-A FORWARD ! -i br0 -o eth0 -j other2wan
-A FORWARD -i br0 -o br0 -j logaccept
-A FORWARD -s 192.168.10.0/24 -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -j NSFW
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m state --state NEW -j OVPN
-A FORWARD -j logdrop
-A OVPN -d 192.168.10.0/24 -i tun21 -j ACCEPT
-A PControls -j logaccept
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j logdrop
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j logdrop
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
-A other2wan -i tun+ -j RETURN
-A other2wan -j logdrop
COMMIT
# Completed on Sat Nov 30 06:00:51 2019

192.168.10.8 ?

That is a random printer. Really a random one. There is another printer at 192.168.10.9 but that is not pingable.

From the PC (192.168.10.12) and with the VPN tunnel connected, can you ping 192.168.10.7 and 192.168.8.1 and 192.168.8.2 ?

192.168.10.7 and 192.168.8.1 are pingable, 192.168.8.2 is not.

 

[ColinTaylor]

EDIT2: The pingability of 192.168.10.7 and 192.168.10.8 returned after I had to force the OpenVPN router (192.168.10.7) to synchronise time from an NTP server.

That is a random printer. Really a random one. There is another printer at 192.168.10.9 but that is not pingable.

I believe this is significant. What you're saying is that as far as the printer at 192.168.10.8 is concerned the VPN connection is working. So what is different about that device compared to another that isn't working?

I see you have logging of dropped and accepted packets turned on. Do you see any of these messages in the router's syslog when pinging across the tunnel (in either direction)?

Another thing you could try (just because you can) is to manually add a static route on one of the target Windows PCs. This would eliminate the local Linksys router from the redirect process for that PC. So from an administrator command prompt:

route ADD 192.168.8.0 MASK 255.255.255.0 192.168.10.7

 

[andres99]

I believe this is significant. What you're saying is that as far as the printer at 192.168.10.8 is concerned the VPN connection is working. So what is different about that device compared to another that isn't working?

I do not know any difference except for the IP address and that they are different models (Canon vs. Brother). Everything else is the same, even the way they are connected to the Linksys (192.168.10.1).

I see you have logging of dropped and accepted packets turned on. Do you see any of these messages in the router's syslog when pinging across the tunnel (in either direction)?

No.

Another thing you could try (just because you can) is to manually add a static route on one of the target Windows PCs. This would eliminate the local Linksys router from the redirect process for that PC. So from an administrator command prompt:

route ADD 192.168.8.0 MASK 255.255.255.0 192.168.10.7

After I added that route in 192.168.10.12, which is a normal Windows PC, that PC is now able to ping 192.168.8.1 and 192.168.8.2. And that PC (192.168.10.12) can now be pinged from 192.168.8.2, a remote PC in the OpenVPN network (connected by the official OpenVPN client for Windows). In other words, there are now 3 pingable devices in the 192.168.10.0 network.

EDIT: When I added the same static route in Linksys (192.168.10.1, the primary router), nothing changed. But when I enabled "Receive RIP versions: RIP2" and "Transmit RIP versions: RIP2 Broadcast" in Linksys, about half of the devices in 192.168.10.0 suddenly became pingable from the OpenVPN network. The other half is still not pingable. And I still cannot browse the file systems of the PC’s. When I had OpenVPN working from a NAS, 192.168.10.5, in the same network, everything was browsable and pingable, and with the NAS OpenVPN, enabling RIP on the Linksys was not necessary.

 

[ColinTaylor]

Given everything you just said I'm inclined to believe that ICMP Redirect isn't working properly, or even worse - intermittently.

ICMP Redirect should be being performed by the Linksys, the effect of which is to dynamically update the routing tables of the 192.168.10.x clients when needed. Whether the blame can be laid on the Linksys or the clients I couldn't say, but my gut feeling says Linksys.

The only problem with this theory is the fact that when you ran Wireshark on 192.168.10.12 you didn't see any incoming ICMP packets. I can't explain that.

If you could replace the Linksys with a different router you might be able to prove/disprove this theory. But other than that I'm going to have to call it a day on this problem.

 

[andres99]

Thank you for your help and patience. It was much more than I expected, thanks a lot!

I would be quite ready to concur with you as regards the Linksys but the only thing that still holds me back is that I had an OpenVPN server (namely that of the QNAP NAS, 192.168.10.5) working flawlessly in the same network with the same Linksys for years. All other conditions were basically the same. Since the NAS’s workload was quite heavy, I decided to move the OpenVPN server to Asus, 192.168.10.7, which was running as a wifi access point in the same subnet anyway. It was then when the problems with OpenVPN started.

 

[ColinTaylor]

Regarding the difference between the OpenVPN server running on the NAS and the Asus, there was a similar discussion here.

As a quick test you could try issuing the following command on the Asus and see if it magically makes a difference.

iptables -t nat -A POSTROUTING -s 192.168.8.0/24 -o br0 -j MASQUERADE

The change will be lost if the router is rebooted or you apply any changes in the router's GUI.

 

[andres99]

That command quite made a difference. It made all devices in 192.168.10.0 pingable from the OpenVPN. And besides, now all devices are browsable too. This continues even when I disabled RIP in the Linksys and removed the 192.168.8.0 static route from the Linksys.

Which seems to mean that the Linksys was not the problem? But what exactly is the problem and how can I make the solution permanent?

 

[ColinTaylor]

Which seems to mean that the Linksys was not the problem?

Not at all . It just means we've completely ignored the problems with (presumably) the Linksys and taken a completely different approach.

But what exactly is the problem and how can I make the solution permanent?

So rather than trying to solve the problem of the clients not being able to find a route back to the VPN tunnel (192.168.8.1), we've told the router to masquerade (change the source IP address of) everything coming out of the tunnel and pretend it's coming from the router's address (192.168.10.7) instead. The router keeps track of these address changes so that when the traffic tries to return it "undoes" the changes to the IP address.

So to make this permanant you would have to enable custom script support on the Asus and create a /jffs/scripts/nat-start script that contains that iptables command.

#!/bin/sh
iptables -t nat -A POSTROUTING -s 192.168.8.0/24 -o br0 -j MASQUERADE

 

[andres99]

I am not sure if I can find the right words to appropriately thank you for the huge help. By what you are doing here, you are making the world a better place. Inter alia, for routers and for those stubborn people who still try to configure them.

I added the script but it seems to me that it did not take. After I rebooted the router, I was back to pinging only 192.168.10.7, 192.168.10.8 and 192.168.10.12. As soon as I enter the magical command, everything works, though. Maybe it is because the router has NAT off because of not using WAN, and the script file should have some other title?

I have just one more question. Every time I reboot the Asus router, it loses track of time and refuses to synchronise with the NTP server automatically. It is probably a DNS problem as the DNS fails entirely but I have added the NTP server as an IP address. It only syncs when I go to Administration - System and click Apply. Is there an easy way to force NTP at every reboot or regularly?

 

[ColinTaylor]

Ah yes. I forgot that you have NAT disabled. Try re-enabling NAT and the firewall.

You can check whether it's worked by looking at the output of the following command:

iptables-save -t nat

If it doesn't work, or it messes things up try renaming the script to firewall-start instead.

I'll think about the NTP issue.

 

[ColinTaylor]

Regarding NTP (and by association OpenVPN); There a lot of router functions that are interdependent and/or rely on the presence of a working WAN interface (which you don't have). The exact sequence these functions are triggered is complex and has changed over time.

So with that said, make sure your router is running at least firmware version 384.12 as there were significant changes in this regard. Then look at the WAN page and make sure "Connect to DNS Server automatically" is set to No. Enter a valid DNS server address for server #1, either 192.168.10.1 if that is running a local DNS server, otherwise use 8.8.8.8.

Also check the settings on the Tools -> Other Settings page and make sure "Use local caching DNS server as system resolver" is set to No.

Now reboot and see if you can resolve names from the router itself. e.g. from an SSH session: nslookup google.com

The outcome of the above will dictate the next step.

 

[andres99]

The script did not function in nat-start nor in firewall-start. However, the script works when I use it in openvpn-event. That matter is resolved, I suppose. Thank you very very much!

The instructions for DNS did not work. DNS still fails (in SSH and I can also see it from Network Tools when I ping an alphabetical address like google.com; it says "bad address"). Time is not synced upon reboot, I have to sync time manually by pressing "Apply" at the "System" page.

I am running FW version 384.13. In Tools -> Other Settings, "Use local caching DNS server as system resolver" has always been set to No.

"Connect to DNS Server automatically" is now set to "No" with DNS Server 1 being the Linksys (192.168.10.1) and DNS Server 2 being that of my ISP (proven to work all right). "Forward local domain queries to upstream DNS" is set to "Yes". "Enable DNS Rebind protection" and "Enable DNSSEC support" are set to no and "DNS Privacy Protocol" is set to none. I have switched off NAT and Firewall since it seemed that they did not work properly anyway (as the scripts did not take).

 

[ColinTaylor]

Can you post the output of these two commands on the router:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

 

[andres99]

ls -l /etc/resolv.conf

outputs

lrwxrwxrwx    1 admin    root            16 May  5  2018 /etc/resolv.conf -> /tmp/resolv.conf

and

cat /etc/resolv.conf

outputs nothing.

 

[ColinTaylor]

OK try this. Create a /jffs/scripts/services-start script and then reboot the router.

#!/bin/sh

echo "nameserver 192.168.10.1" > /tmp/resolv.conf
ntpclient -h pool.ntp.org -i 3 -l -s
service restart_vpnserver1