1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

Issue with VPN and Merlin 384.9

Discussion in 'Asuswrt-Merlin' started by baronet, Mar 21, 2019.

  1. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
    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?
     
  2. Martineau

    Martineau Part of the Furniture

    Joined:
    Jul 8, 2012
    Messages:
    2,046
    Location:
    UK
    Does this help?
    OpenVPN - unable to reach subnets attached to LAN
     
  3. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
    Hi,
    I tried it but not works.

    But there is already a iptables rules:
    Code:
    [email protected]:/tmp/home/root# iptables -L OVPN
    Chain OVPN (2 references)
    target     prot opt source               destination
    ACCEPT     all  --  anywhere             anywhere
     
  4. Martineau

    Martineau Part of the Furniture

    Joined:
    Jul 8, 2012
    Messages:
    2,046
    Location:
    UK
    Post the output of
    Code:
    iptables  --line -t filter -nvL OVPN
     
  5. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
    Code:
    [email protected]:/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
     
  6. elorimer

    elorimer Very Senior Member

    Joined:
    Dec 16, 2013
    Messages:
    673
    Do you have the radio button on the general tab set to "Lan Only", "Internet Only" or "Both"?
     
  7. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
    It set to "Both"
     
  8. Martineau

    Martineau Part of the Furniture

    Joined:
    Jul 8, 2012
    Messages:
    2,046
    Location:
    UK
    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: Mar 22, 2019
  9. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
    There is no traffic for the rule 1, the modem's subnet:
    Code:
    [email protected]:/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  
    no changes, the modem's subnet is always the same.
     
  10. Martineau

    Martineau Part of the Furniture

    Joined:
    Jul 8, 2012
    Messages:
    2,046
    Location:
    UK
    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.
     
    octopus likes this.
  11. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
    All the rules:
    Code:
    [email protected]:/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?
     
  12. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    8,104
    Location:
    UK
    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.
     
  13. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
    Yes, now works!
    Now I don't understand where that rule came from

    Many thanks :)
     
  14. Pizzy09

    Pizzy09 New Around Here

    Joined:
    Jan 31, 2019
    Messages:
    6
    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?
     
  15. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
    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.
     
  16. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    8,104
    Location:
    UK
    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.
     
  17. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
    Yes, you are right.
    (but I thought that with the new version it was resolved)
     
    Last edited: Mar 27, 2019
  18. Martineau

    Martineau Part of the Furniture

    Joined:
    Jul 8, 2012
    Messages:
    2,046
    Location:
    UK
    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?
     
  19. baronet

    baronet Occasional Visitor

    Joined:
    Mar 21, 2019
    Messages:
    12
  20. octopus

    octopus Very Senior Member

    Joined:
    Jul 17, 2012
    Messages:
    1,108
    service restart_firewall