What's new

Issue with VPN and Merlin 384.9

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

baronet

Occasional Visitor
Hi all,

I have a RT-AC86U running Merlin version 384.9. The router is connected at the VDSL modem, WAN-LAN port. The router and the modem have IP on different subnet.
From the lan behind the router I can access to the modem without problem.

Now the issue: until Merlin version 384.8 when I connected via VPN to the router I was able to access also the modem, but with the version 384.9 I can't access it anymore. The modem doesn't even respond to the ping

Any ideas?
 
Hi all,

I have a RT-AC86U running Merlin version 384.9. The router is connected at the VDSL modem, WAN-LAN port. The router and the modem have IP on different subnet.
From the lan behind the router I can access to the modem without problem.

Now the issue: until Merlin version 384.8 when I connected via VPN to the router I was able to access also the modem, but with the version 384.9 I can't access it anymore. The modem doesn't even respond to the ping

Any ideas?
Does this help?
OpenVPN - unable to reach subnets attached to LAN
 
Hi,
I tried it but not works.

But there is already a iptables rules:
Code:
admin_RT@RT-AC86U-AF10:/tmp/home/root# iptables -L OVPN
Chain OVPN (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
 
Hi,
I tried it but not works.

But there is already a iptables rules:
Code:
admin_RT@RT-AC86U-AF10:/tmp/home/root# iptables -L OVPN
Chain OVPN (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Post the output of
Code:
iptables  --line -t filter -nvL OVPN
 
Post the output of
Code:
iptables  --line -t filter -nvL OVPN

Code:
admin_RT@RT-AC86U-AF10:/tmp/home/root# iptables  --line -t filter -nvL OVPN
Chain OVPN (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1     7190  467K ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0
 
Do you have the radio button on the general tab set to "Lan Only", "Internet Only" or "Both"?
 
Code:
admin_RT@RT-AC86U-AF10:/tmp/home/root# iptables  --line -t filter -nvL OVPN
Chain OVPN (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1     7190  467K ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0

Thanks, using a more detailed iptables query command shows the actual interfaces concerned.

If you explicitly INSERT the rule to access the Modem's subnet at the top of the OVPN chain, you should be able to see if there is any inbound traffic from the OpenVPN server 1 (tun21)

It may be worthwhile to restore to v384.8 and use iptables logging to see how the iptables/route rules are applied in that environment.
NOTE: I used to use the alias technique on 'br0:' and add a POSTROUTING MASQUERADE rule via the WAN interface for the modem.

P.S. : I assume you have not made any subnet changes since v384.8, as some modem interfaces will reject access from a different subnet.
 
Last edited:
If you explicitly INSERT the rule to access the Modem's subnet at the top of the OVPN chain, you should be able to see if there is any inbound traffic from the OpenVPN server 1 (tun21)

There is no traffic for the rule 1, the modem's subnet:
Code:
admin_RT@RT-AC86U-AF10:/tmp/home/root# iptables --line -t filter -nvL OVPN
Chain OVPN (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            192.168.1.0/24
2     7392  477K ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0

P.S. : I assume you have not made any subnet changes since v384.8, as some modem interfaces will reject access from a different subnet.

no changes, the modem's subnet is always the same.
 
There is no traffic for the rule 1, the modem's subnet:
Code:
admin_RT@RT-AC86U-AF10:/tmp/home/root# iptables --line -t filter -nvL OVPN
Chain OVPN (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            192.168.1.0/24
2     7392  477K ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0

Hmmmm, perhaps there is a 192.168.1.0/24 DROP rule that is being processed before the OVPN chain?:eek:...you will need to examine the higher priority firewall rules/logs etc., or you may have to resort to installing tcpdump to assist in finding the issue.
 
All the rules:
Code:
admin_RT@RT-AC86U-AF10:/tmp/home/root# iptables --line -t filter -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        1    42 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194
2      236  9124 DROP       icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0            icmptype 8
3    2313K  593M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
4     8918  363K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
5    2770K  781M PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0
6    72531 6049K PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0
7    72531 6049K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
8    2700K  765M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
9    69526   16M OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
10       2    80 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0
11   60696   15M DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    73444 3876K TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x02 TCPMSS clamp to PMTU
2    1346K  653M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
3      549 99976 other2wan  all  --  !br0   ppp0    0.0.0.0/0            0.0.0.0/0
4      345 20310 DROP       all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0
5     3463  186K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
6        0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
7    37912 4668K NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0
8        1    44 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
9    37911 4668K OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
10   37160 4556K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 104K packets, 29M bytes)
num   pkts bytes target     prot opt in     out     source               destination

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

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

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

Chain INPUT_ICMP (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
2        2    80 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 13
3        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0

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

Chain OVPN (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0
2        0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            192.168.1.0/24

Chain PControls (0 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

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

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

Chain SECURITY (0 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02 limit: avg 1/sec burst 5
2        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
3        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04 limit: avg 1/sec burst 5
4        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
5        0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
6        0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
7        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

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

Chain logaccept (0 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "
2        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain logdrop (0 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "DROP "
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain other2wan (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1      549 99976 RETURN     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Do you know where I can download tcpdump for the RT-AC86U?
 
I suspect this is your problem:
Code:
3      549 99976 other2wan  all  --  !br0   ppp0    0.0.0.0/0            0.0.0.0/0
4      345 20310 DROP       all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0
Line 3 allows non-LAN (i.e. VPN) traffic to go out through the ppp tunnel. Line 4 blocks non-LAN traffic going out through eth0. I'm guessing that to access the VDSL modem you need to do it through eth0. Try deleting line 4 and see if it now works.
 
I suspect this is your problem:
Code:
3      549 99976 other2wan  all  --  !br0   ppp0    0.0.0.0/0            0.0.0.0/0
4      345 20310 DROP       all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0
Line 3 allows non-LAN (i.e. VPN) traffic to go out through the ppp tunnel. Line 4 blocks non-LAN traffic going out through eth0. I'm guessing that to access the VDSL modem you need to do it through eth0. Try deleting line 4 and see if it now works.

Yes, now works!
Now I don't understand where that rule came from

Many thanks :)
 
Hi, i have the same problem of the original poster since v384.9 (and also with the newer v384.10, both with factory reset and manual setup).
With 384.7_2 was fine. So the only solution is to delete that roule? Has the rule been introduced after 384.7_2?
 
Hi, i have the same problem of the original poster since v384.9 (and also with the newer v384.10, both with factory reset and manual setup).
With 384.7_2 was fine. So the only solution is to delete that roule? Has the rule been introduced after 384.7_2?

Until version v384.8_2 I don't know if that rule was there, but it worked.

I have found no other solutions than to delete it

And after the update to v384.10 that rule is back.
 
And after the update to v384.10 that rule is back.
Deleting the rule is only temporary until the firewall (or router) is restarted. To make the change persistent you would have to put it in a firewall-start script.
 
Deleting the rule is only temporary until the firewall (or router) is restarted. To make the change persistent you would have to put it in a firewall-start script.

Yes, you are right.
(but I thought that with the new version it was resolved)
 
Last edited:
Yes, you are right.
(but I thought that with the new version it was resolved)

I would suggest rather than delete the rule (presumably deliberately enforced by ASUS for PPP WAN connections) that you add an explicit rule to exclusively access the modem's specific IP inbound from 'tun2+' outbound via 'eth0' only when there is a valid/authorised OpenVPN client (preferably with a static OpenVPN pool IP) connection and delete the rule when the OpenVPN client disconnects?
 

Similar threads

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