Port Forward routes not sticking AC86U 386.1_2

[nexus12345]

The port forwarding routes on my router disappear after every 2-3 days. I usually have to run the nat-script again to get the routes added and ports open up again for a few hours/days. I have checked the NVRAM <50% used. JFFS <10% used.

Router : AC86U
Merlin Ver. : 386.1_2 ( Upgraded and then complete reset with power removed and reconfigured from base)

The script below adds routes that open port from VPN connection.


#!/bin/sh

iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 49589 -j DNAT --to-destination 172.16.0.78
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 49589 -j DNAT --to-destination 172.16.0.78
iptables -I FORWARD -i tun11 -p udp -d 172.16.0.78 --dport 49589 -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 172.16.0.78 --dport 49589 -j ACCEPT


iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 32400 -j DNAT --to-destination 172.16.0.78
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 32400 -j DNAT --to-destination 172.16.0.78
iptables -I FORWARD -i tun11 -p udp -d 172.16.0.78 --dport 32400 -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 172.16.0.78 --dport 32400 -j ACCEPT

 

[GSpock]

Have you checked you have something like this in syslog:

Mar 11 14:18:33 custom_script: Running /jffs/scripts/nat-start

 

[eibgrad]

Sounds like a classic case of NOT using the correct script (you did say nat-script, which isn't correct).

/jffs/scripts/nat-start

 

[Jack Yaz]

Also try adding

sleep 5

before your rules (assuming you are using nat-start)

 

[eibgrad]

I'd also be interested if it's *all* the rules that disappear, or only specific ones, like only the NAT rules, or only the FORWARD rules.

The reason I'm asking is because *technically*, I assume the NAT rules should be applied w/ the nat-start script, and the FORWARD rules w/ the firewall-start script. Why Merlin separates these events I don't know, but I have to assume it's for a reason, and it suggests to me there may be circumstances in which only one or other script is triggered. Or there's some other timing issue, perhaps leading to changes being lost.

I can't be more specific since I'm just speculating, but Merlin is a bit unusual in how it divides these operations into two separate events when compared to other third-party firmware, and I'm always a bit leery about assuming that you can safely apply rules to other tables (e.g., filter) in the NAT script. That *might* be a bad assumption.

Perhaps @RMerlin can enlighten us.

 

[nexus12345]

Thanks for the reply folks!! , I'll add my observations below.

@GSpock @eibgrad @Jack Yaz
Sorry for the confusion about nat-script, it indeed is nat-start located in /jffs/scripts. Also, I can see the script getting triggered and rules being applied. They just vanish after a while, also if i run the script manually by going though SSH , the rules come back but vanish again after few hours.

@eibgrad ( the 2nd post)
That's an interesting observation, I didn't think of looking at both the rule sets. I checked the forwarding rules in iptables and UI but where do i check the NAT rules. Also, i will try separating the forward and nat rules in different scripts and give it a go.


Just for more clarity, i don't want to be this an X Y problem . The goal that I'm trying to pursue is following.

- Set OpenVPN on strict policy rule and add my raspberrypi to this. ( I have already had the ports opened from my VPN provider and that works)
- Open ports ( FRWD and NAT ) so that external users can reach the device / service.


Again, I'm extremely grateful that you folks took time to reply to my question. Any help would be much appreciated. Have a wonderful day folks.

 

[john9527]

Do you have QoS enabled? If it's on, try disabling it and see if it makes a difference.

 

[eibgrad]

@eibgrad ( the 2nd post)
That's an interesting observation, I didn't think of looking at both the rule sets. I checked the forwarding rules in iptables and UI but where do i check the NAT rules. Also, i will try separating the forward and nat rules in different scripts and give it a go.

You can dump the relevant NAT rules using the folliwing command.

iptables -t nat -vnL PREROUTING

And for completeness, the FORWARD rules w/ the following.

iptables -vnL FORWARD

Just for more clarity, i don't want to be this an X Y problem . The goal that I'm trying to pursue is following.

- Set OpenVPN on strict policy rule and add my raspberrypi to this. ( I have already had the ports opened from my VPN provider and that works)
- Open ports ( FRWD and NAT ) so that external users can reach the device / service.

I see nothing wrong with your intent or the rules specifically. They appear correct.

 

[john9527]

Do you have QoS enabled? If it's on, try disabling it and see if it makes a difference.

 

[eibgrad]

Discovered something interesting while working on an unrelated matter.

I noticed when using the GUI to create a port forward, it is NOT specific as to the input network interface, except in one location; the VSERVER rule (based on the WAN ip, 192.168.63.102 in my case). For example, consider the following port forward ...

external port: 20000
internal port: 21000
internal ip: 192.168.1.7
protocol: tcp

... and a dump of the relevant tables.

admin@RT-AC68U-0960:/tmp/home/root# iptables -t nat -vnL PREROUTING
Chain PREROUTING (policy ACCEPT 1453 packets, 272K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 GAME_VSERVER  all  --  *      *       0.0.0.0/0            192.168.63.102
    0     0 VSERVER    all  --  *      *       0.0.0.0/0            192.168.63.102

admin@RT-AC68U-0960:/tmp/home/root# iptables -t nat -vnL VSERVER
Chain VSERVER (1 references)
pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:20000 to:192.168.1.7:21000
    0     0 VUPNP      all  --  *      *       0.0.0.0/0            0.0.0.0/0  

admin@RT-AC68U-0960:/tmp/home/root# iptables -vnL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 other2wan  all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0  
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0  
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0  
    0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0  
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
    0     0 OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

That dump tells me the FORWARD rules aren't necessary, since the 'ctstate DNAT' rule is sufficient to enable forwarding, regardless of the incoming network interface. And I suspect it's this way so it can support NAT loopback (which would make the input network interface br0).

To make thing even more interesting, it appears you could probably use the GUI's port forwarding for the VPN by adding the following rule.

iptables -t nat -A PREROUTING -i tun1+ -j VSERVER

I suppose you could even go so far as to add the DNAT rules to the VSERVER chain rather than PREROUTING.

Of course, the downside is you can't restrict your port forwards to one or the other network interface (WAN vs. VPN). But perhaps replicating the port forward(s) across both network interfaces might be desirable to some ppl, esp. if you can manage it all via the GUI.

At the very least, if your problem is *only* w/ the FORWARD rules disappearing, seems to me you could just eliminate them. They're superfluous.

Note, I haven't tested any of this since my OpenVPN provider doesn't support port forwarding. But just based upon observation, I think it would work.

P.S. The necessary rules (VSERVER and 'ctstate DNAT') are there even if port forwarding is disabled in the GUI.