What's new

Curious behaviour after opening ports with iptables - RTAX86U - Asus Wrt Merlin

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

juanantonio

Regular Contributor
Good afternooon everyone.

I needed opening port 8123 on my RT-AX86U. I did in the way I already have more than a dozen open ports, which I learned from @ZebMcKayhan , (Thanks mate!).

The thing is:

The port shows as open on https://www.connected.app/port-checker, as seen on image:

1734965190297.png


Also, the counters are not zero on my iptables command:

Code:
juanantonio@RT-AX86U-6C38:/jffs/scripts# iptables -nvL -t nat | grep 8123
   11   644 DNAT       tcp  --  wgc1   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:51821 to:192.168.1.213:8123
juanantonio@RT-AX86U-6C38:/jffs/scripts#

So, the thing works at the beginning. But, after a while (I don't know how much time is, several minutes), the port appears to close magically and the only thing that solve the issue is restarting the firewall, as follows:

Bash:
juanantonio@RT-AX86U-6C38:/jffs/scripts# service restart_firewall

Done.
juanantonio@RT-AX86U-6C38:/jffs/scripts#

So, for making this change permanent, the only thing I could thought of was creating a cron job, so I didn't need to lauch the command every so and then, in order to make my Home Assistant accesible to the mobile app (it is called companion).

Bash:
juanantonio@RT-AX86U-6C38:/jffs/scripts# cru l
*/5 * * * * service restart_firewall>/tmp/log_firewall #rst_firewall#
juanantonio@RT-AX86U-6C38:/jffs/scripts#

My question is: Is there any other way to achieve this connectivity from the mobile app to the server which avoid this constant restarting of the firewall? I don't believe this is a normal behaviour.

Thanks in advance.
 
Last edited:
My question is: Is there any other way to achieve this connectivity from the mobile app to the server which avoid this constant restarting of the firewall? I don't believe this is a normal behaviour.
Obviously something happens that makes it don't work. Do the counters on both dnat rule and forward rule continue to increase even though its not working?

For debug purpose you could turn on logging of martians and keep an eye in the syslog after it stops working and see if it may give a clue:
Code:
 echo 1 >/proc/sys/net/ipv4/conf/wgc1/log_martians
 
Well, I did as you suggested, but the output on syslog.log doesn't mean much for me, here it is:

Bash:
Dec 24 13:26:25 kernel: IPv4: martian source 10.151.13.172 from 193.176.87.164, on dev wgc1
Dec 24 13:26:25 kernel: IPv4: martian source 10.151.13.172 from 37.186.4.16, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 89.40.212.249, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 149.22.80.40, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 47.144.243.119, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 86.48.14.159, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 81.43.103.144, on dev wgc1
Dec 24 13:26:27 kernel: IPv4: martian source 10.151.13.172 from 45.148.17.50, on dev wgc1
Dec 24 13:26:28 kernel: IPv4: martian source 10.151.13.172 from 45.14.195.64, on dev wgc1
Dec 24 13:26:30 kernel: net_ratelimit: 12 callbacks suppressed
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 84.239.6.18, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 209.216.123.32, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 38.57.195.125, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 31.124.59.242, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 91.246.58.171, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 192.145.116.161, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 91.246.58.171, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 173.239.203.78, on dev wgc1
Dec 24 13:26:31 kernel: IPv4: martian source 10.151.13.172 from 94.26.188.103, on dev wgc1
Dec 24 13:26:31 kernel: IPv4: martian source 10.151.13.172 from 45.14.195.64, on dev wgc1
Dec 24 13:26:35 kernel: net_ratelimit: 18 callbacks suppressed
Dec 24 13:26:35 kernel: IPv4: martian source 10.151.13.172 from 194.88.100.22, on dev wgc1
Dec 24 13:26:35 kernel: IPv4: martian source 10.151.13.172 from 185.232.21.34, on dev wgc1
Dec 24 13:26:36 kernel: IPv4: martian source 10.151.13.172 from 181.214.166.111, on dev wgc1
Dec 24 13:26:36 kernel: IPv4: martian source 10.151.13.172 from 204.93.149.138, on dev wgc1
Dec 24 13:26:36 kernel: IPv4: martian source 10.151.13.172 from 155.133.17.123, on dev wgc1
Dec 24 13:26:37 kernel: IPv4: martian source 10.151.13.172 from 181.214.70.55, on dev wgc1
Dec 24 13:26:37 kernel: IPv4: martian source 10.151.13.172 from 85.145.224.230, on dev wgc1
Dec 24 13:26:37 kernel: IPv4: martian source 10.151.13.172 from 185.65.134.198, on dev wgc1
Dec 24 13:26:37 kernel: IPv4: martian source 10.151.13.172 from 98.159.226.216, on dev wgc1
Dec 24 13:26:38 kernel: IPv4: martian source 10.151.13.172 from 94.140.5.156, on dev wgc1
Dec 24 13:26:41 kernel: net_ratelimit: 15 callbacks suppressed
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 179.61.197.184, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 194.34.235.149, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 93.170.240.19, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 154.47.19.181, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 188.214.122.104, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 37.19.211.133, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 193.138.218.211, on dev wgc1
Dec 24 13:26:42 kernel: IPv4: martian source 10.151.13.172 from 45.13.235.119, on dev wgc1
Dec 24 13:26:42 kernel: IPv4: martian source 10.151.13.172 from 185.203.219.200, on dev wgc1
Dec 24 13:26:43 kernel: IPv4: martian source 10.151.13.172 from 61.6.46.169, on dev wgc1
Dec 24 13:26:46 kernel: net_ratelimit: 24 callbacks suppressed
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 89.238.128.86, on dev wgc1
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 146.70.134.184, on dev wgc1
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 61.6.46.169, on dev wgc1
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 188.214.122.104, on dev wgc1
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 217.148.140.138, on dev wgc1
Dec 24 13:26:47 kernel: IPv4: martian source 10.151.13.172 from 185.65.134.239, on dev wgc1
Dec 24 13:26:48 kernel: IPv4: martian source 10.151.13.172 from 86.48.14.159, on dev wgc1
Dec 24 13:26:48 kernel: IPv4: martian source 10.151.13.172 from 190.53.100.34, on dev wgc1
Dec 24 13:26:48 kernel: IPv4: martian source 10.151.13.172 from 217.10.213.94, on dev wgc1
Dec 24 13:26:48 kernel: IPv4: martian source 10.151.13.172 from 185.203.219.200, on dev wgc1

About your other question, yes, counters are increasing, especially if I try to verify that the ports are opened.
Here are the outputs:
Bash:
juanantonio@RT-AX86U-6C38:/jffs/scripts# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 2753 packets, 270K bytes)
 pkts bytes target     prot opt in     out     source               destination
    1    60 DNAT       tcp  --  wgc1   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:51821 to:192.168.1.213:8123

And after 2 tries of verifying port state:

Bash:
juanantonio@RT-AX86U-6C38:/jffs/scripts# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 1875 packets, 197K bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   180 DNAT       tcp  --  wgc1   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:51821 to:192.168.1.213:8123

It seems to me that every packet is 60 bytes of payload.

Regards, and infinite thanks for your time.
 
Well, I did as you suggested, but the output on syslog.log doesn't mean much for me, here it is:

Bash:
Dec 24 13:26:25 kernel: IPv4: martian source 10.151.13.172 from 193.176.87.164, on dev wgc1
Dec 24 13:26:25 kernel: IPv4: martian source 10.151.13.172 from 37.186.4.16, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 89.40.212.249, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 149.22.80.40, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 47.144.243.119, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 86.48.14.159, on dev wgc1
Dec 24 13:26:26 kernel: IPv4: martian source 10.151.13.172 from 81.43.103.144, on dev wgc1
Dec 24 13:26:27 kernel: IPv4: martian source 10.151.13.172 from 45.148.17.50, on dev wgc1
Dec 24 13:26:28 kernel: IPv4: martian source 10.151.13.172 from 45.14.195.64, on dev wgc1
Dec 24 13:26:30 kernel: net_ratelimit: 12 callbacks suppressed
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 84.239.6.18, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 209.216.123.32, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 38.57.195.125, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 31.124.59.242, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 91.246.58.171, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 192.145.116.161, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 91.246.58.171, on dev wgc1
Dec 24 13:26:30 kernel: IPv4: martian source 10.151.13.172 from 173.239.203.78, on dev wgc1
Dec 24 13:26:31 kernel: IPv4: martian source 10.151.13.172 from 94.26.188.103, on dev wgc1
Dec 24 13:26:31 kernel: IPv4: martian source 10.151.13.172 from 45.14.195.64, on dev wgc1
Dec 24 13:26:35 kernel: net_ratelimit: 18 callbacks suppressed
Dec 24 13:26:35 kernel: IPv4: martian source 10.151.13.172 from 194.88.100.22, on dev wgc1
Dec 24 13:26:35 kernel: IPv4: martian source 10.151.13.172 from 185.232.21.34, on dev wgc1
Dec 24 13:26:36 kernel: IPv4: martian source 10.151.13.172 from 181.214.166.111, on dev wgc1
Dec 24 13:26:36 kernel: IPv4: martian source 10.151.13.172 from 204.93.149.138, on dev wgc1
Dec 24 13:26:36 kernel: IPv4: martian source 10.151.13.172 from 155.133.17.123, on dev wgc1
Dec 24 13:26:37 kernel: IPv4: martian source 10.151.13.172 from 181.214.70.55, on dev wgc1
Dec 24 13:26:37 kernel: IPv4: martian source 10.151.13.172 from 85.145.224.230, on dev wgc1
Dec 24 13:26:37 kernel: IPv4: martian source 10.151.13.172 from 185.65.134.198, on dev wgc1
Dec 24 13:26:37 kernel: IPv4: martian source 10.151.13.172 from 98.159.226.216, on dev wgc1
Dec 24 13:26:38 kernel: IPv4: martian source 10.151.13.172 from 94.140.5.156, on dev wgc1
Dec 24 13:26:41 kernel: net_ratelimit: 15 callbacks suppressed
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 179.61.197.184, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 194.34.235.149, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 93.170.240.19, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 154.47.19.181, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 188.214.122.104, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 37.19.211.133, on dev wgc1
Dec 24 13:26:41 kernel: IPv4: martian source 10.151.13.172 from 193.138.218.211, on dev wgc1
Dec 24 13:26:42 kernel: IPv4: martian source 10.151.13.172 from 45.13.235.119, on dev wgc1
Dec 24 13:26:42 kernel: IPv4: martian source 10.151.13.172 from 185.203.219.200, on dev wgc1
Dec 24 13:26:43 kernel: IPv4: martian source 10.151.13.172 from 61.6.46.169, on dev wgc1
Dec 24 13:26:46 kernel: net_ratelimit: 24 callbacks suppressed
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 89.238.128.86, on dev wgc1
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 146.70.134.184, on dev wgc1
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 61.6.46.169, on dev wgc1
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 188.214.122.104, on dev wgc1
Dec 24 13:26:46 kernel: IPv4: martian source 10.151.13.172 from 217.148.140.138, on dev wgc1
Dec 24 13:26:47 kernel: IPv4: martian source 10.151.13.172 from 185.65.134.239, on dev wgc1
Dec 24 13:26:48 kernel: IPv4: martian source 10.151.13.172 from 86.48.14.159, on dev wgc1
Dec 24 13:26:48 kernel: IPv4: martian source 10.151.13.172 from 190.53.100.34, on dev wgc1
Dec 24 13:26:48 kernel: IPv4: martian source 10.151.13.172 from 217.10.213.94, on dev wgc1
Dec 24 13:26:48 kernel: IPv4: martian source 10.151.13.172 from 185.203.219.200, on dev wgc1

About your other question, yes, counters are increasing, especially if I try to verify that the ports are opened.
Here are the outputs:
Bash:
juanantonio@RT-AX86U-6C38:/jffs/scripts# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 2753 packets, 270K bytes)
 pkts bytes target     prot opt in     out     source               destination
    1    60 DNAT       tcp  --  wgc1   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:51821 to:192.168.1.213:8123

And after 2 tries of verifying port state:

Bash:
juanantonio@RT-AX86U-6C38:/jffs/scripts# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 1875 packets, 197K bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   180 DNAT       tcp  --  wgc1   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:51821 to:192.168.1.213:8123

It seems to me that every packet is 60 bytes of payload.

Regards, and infinite thanks for your time.
I'm guessing 10.151.13.172 is the ip of your wgc1 interface?

Martian means that rp filter is dropping these packets as it appears a reply would not be routed back to where it comes from.

What if you add a vpndirector rule local ip 10.151.13.172 to interface wgc1? Would that change anything?

Another option is to adjust rp filter option but lets test this first.
 
Certainly, that is my wireguard client's ip, it is showed by ipconfig command's output:

Bash:
juanantonio@RT-AX86U-6C38:/tmp/home/root# ifconfig wgc1
wgc1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.151.13.172  P-t-P:10.151.13.172  Mask:255.192.0.0
          inet6 addr: fd7d:76ee:e68f:a993:d0c0:1334:273a:628b/48 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
          RX packets:1822021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1319566 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1779940260 (1.6 GiB)  TX bytes:652575816 (622.3 MiB)

juanantonio@RT-AX86U-6C38:/tmp/home/root#

I tried adding to VPN Director the rule you suggested and suddenly, at that precise moment, my log file stopped showing those annoying messages.

I also deleted the cron job so as to verify that all is working, and luckily, after almost half an hour, my forwarded ports no longer disappear from iptables output.

Thanks again!
 
Certainly, that is my wireguard client's ip, it is showed by ipconfig command's output:

Bash:
juanantonio@RT-AX86U-6C38:/tmp/home/root# ifconfig wgc1
wgc1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.151.13.172  P-t-P:10.151.13.172  Mask:255.192.0.0
          inet6 addr: fd7d:76ee:e68f:a993:d0c0:1334:273a:628b/48 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
          RX packets:1822021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1319566 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1779940260 (1.6 GiB)  TX bytes:652575816 (622.3 MiB)

juanantonio@RT-AX86U-6C38:/tmp/home/root#

I tried adding to VPN Director the rule you suggested and suddenly, at that precise moment, my log file stopped showing those annoying messages.

I also deleted the cron job so as to verify that all is working, and luckily, after almost half an hour, my forwarded ports no longer disappear from iptables output.

Thanks again!
Great news!

I have had my fair share of fights with rp filter, altough I always imagine the filtering happening during routing, as after the dnat. But apparently not.

There are various nuances to how suppliers does port forwarding, some requires removal of routes as the are masquaraded to come from wg endpoint. But this would apply to all wg port forward I guess.
I would suggest using this rule instead of disabling rp filter as I see no harm or conflict by doing this.
 
As long as my home assistant mobile app can connect to my server, I'm more than satisfied and I have no intention of disabling rp filter, whatever it can be.
 
Similar threads
Thread starter Title Forum Replies Date
el_pedr0 Please harmonise killswitch behaviour Asuswrt-Merlin 1

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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