RT-AC88U drops the OpenVPN inbound ACCEPT iptables rule after a time

[JDA]

This is for ASUS Merlin running latest version on two RT-AC88U routers, one as an openvpn server, and the other as a client.
I route 10.0.0.0/8 subnets on either side of the openvpn link.
When the link is established, the client route iptables has the following line in it:

Chain OVPNSI
ACCEPT udp -- anywhere anywhere udp dpt:1194

So I can ping from 10.0.server.50 -> 10.0.client.20 no problem.

But after a time, with an active openvpn link still running, and everything else as normal, this iptables line disappears, and that same ping does not work.
If I go to the client router "firewall" page and change nothing, and click "Apply", the iptables rule is restored, and all works fine.
When the iptables rule is gone, the 10.0.client.20 computer has no problem reaching or pinging 10.0.server.50, so it is a problem with openvpn INCOMING to the client and OUTGOING works fine.
There is no NAT on the openvpn internal routing.
If I ssh into the client router, and enter "service firewall_restart", this line is restored, and the ping to the client works again.

thank you for any advice!

 

[ColinTaylor]

When the link is established, the client route iptables has the following line in it:

I assume this is a typo and you really meant "router".

Chain OVPNSI
ACCEPT udp -- anywhere anywhere udp dpt:1194

That is the firewall rule that allows a remote client to connect to an OpenVPN server on this router. As you said this is the client machine this rule is redundant and shouldn't be there, unless you're also running a server on this router.

 

[JDA]

Thank you Colin, I do have a server enabled on the client router, for access when the router is somehow not working properly as a client. I did turn off the server, and did see that line go away. I confirmed when the server was disabled on the client router that the pings work fine from a server router host to a client router host with that line absent.

So now the problem changes to: why after a time can I not ping from a server router host to a client router host, and doing a "server firewall_restart" on the client router restores the ping functionality? The "iptables -L" output is identical when working or not working.

 

[ColinTaylor]

So now the problem changes to: why after a time can I not ping from a server router host to a client router host, and doing a "server firewall_restart" on the client router restores the ping functionality? The "iptables -L" output is identical when working or not working.

Another typo, should be "service restart_firewall".

Your iptables command will only show the filter table. I suggest you dump all the rules with the following command and then compare the working/non-working versions.

iptables-save

 

[JDA]

I used iptables-save when the ping worked and saved as 1.txt. Then again today when the ping did not work, saved as 2.txt.
Then "diff 1.txt 2.txt".

The "OVPNCF" and "OVPNCI" lines that go missing after a time seem the culprit. Why would they disappear?
The "OVPNSF" lines also disappear for the openvpn server on that router; why is that?

The output is:

1c1
< # Generated by iptables-save v1.4.15 on Thu Jan 16 08:58:25 2025
---
> # Generated by iptables-save v1.4.15 on Fri Jan 17 08:48:09 2025
3,4c3,4
< PREROUTING ACCEPT [212963:85595831]
< :OUTPUT ACCEPT [158844:66595907]
---
> PREROUTING ACCEPT [123545:21735562]
> :OUTPUT ACCEPT [99858:20624368]
6,7c6,7
< # Completed on Thu Jan 16 08:58:25 2025
< # Generated by iptables-save v1.4.15 on Thu Jan 16 08:58:25 2025
---
> # Completed on Fri Jan 17 08:48:09 2025
> # Generated by iptables-save v1.4.15 on Fri Jan 17 08:48:09 2025
9,12c9,12
< PREROUTING ACCEPT [921:82149]
< :INPUT ACCEPT [459:31193]
< :OUTPUT ACCEPT [78:10225]
< POSTROUTING ACCEPT [336:23826]
---
> PREROUTING ACCEPT [11346:679784]
> :INPUT ACCEPT [1158:87620]
> :OUTPUT ACCEPT [2383:302649]
> POSTROUTING ACCEPT [9013:696501]
29,30c29,30
< # Completed on Thu Jan 16 08:58:25 2025
< # Generated by iptables-save v1.4.15 on Thu Jan 16 08:58:25 2025
---
> # Completed on Fri Jan 17 08:48:09 2025
> # Generated by iptables-save v1.4.15 on Fri Jan 17 08:48:09 2025
32,36c32,36
< PREROUTING ACCEPT [69875:39364999]
< :INPUT ACCEPT [51397:23379528]
< :FORWARD ACCEPT [18478:15985471]
< :OUTPUT ACCEPT [51168:31189315]
< POSTROUTING ACCEPT [69761:47211894]
---
> PREROUTING ACCEPT [122931:21416621]
> :INPUT ACCEPT [96002:18174232]
> :FORWARD ACCEPT [26746:3218393]
> :OUTPUT ACCEPT [99272:20318443]
> POSTROUTING ACCEPT [126626:23748700]
39,40c39,40
< # Completed on Thu Jan 16 08:58:25 2025
< # Generated by iptables-save v1.4.15 on Thu Jan 16 08:58:25 2025
---
> # Completed on Fri Jan 17 08:48:09 2025
> # Generated by iptables-save v1.4.15 on Fri Jan 17 08:48:09 2025
44c44
< :OUTPUT ACCEPT [15565:8843579]
---
> :OUTPUT ACCEPT [99058:20278930]
70a71
> -A INPUT -s 66.220.2.74/32 -p icmp -j ACCEPT
132,138d132
< -A OVPNCF -o tun12 -j ACCEPT
< -A OVPNCF -i tun12 -j ACCEPT
< -A OVPNCI -i tun12 -j ACCEPT
< -A OVPNSF -o tun21 -j ACCEPT
< -A OVPNSF -i tun21 -j ACCEPT
< -A OVPNSI -i tun21 -j ACCEPT
< -A OVPNSI -p udp -m udp --dport 1194 -j ACCEPT
157c151
< # Completed on Thu Jan 16 08:58:25 2025
---
> # Completed on Fri Jan 17 08:48:09 2025

 

[ColinTaylor]

The most common reason would be that the OpenVPN client and server on that router died, perhaps because of a network problem. If that were the case it should be obvious by looking in the router's System Log - General Log and also checking the VPN - Status page.

 

[JDA]

That isn't the case. I can ssh and ping and anything I want from an openvpn client network host to a server network host. I can access either router from the other. The openvpn link is up and working, it is just that these firewall rules are dropped and the specific limitation is this server network host to client network host problem. I don't stop and restart the openvpn to restore function. Stopping and restarting the firewall to put these rules back in corrects it, until after a time they drop again.

 

[JDA]

And these rules are present when working, and then absent after a time; they just disappear and the openvpn link hasn't gone anywhere.

iptables -L -n:

Chain OVPNCF (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain OVPNCI (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

 

[ColinTaylor]

Maybe a bug, although it seems unlikely nobody else has noticed it after all this time.

Or perhaps a conflict with some other third party script running on the router?

I would go to System Log - General Log and set "Log only messages more urgent than" to "all" and see if you can find some corelation between the rules disappearing and events in the log. Are you using DDNS perhaps?

 

[JDA]

I do have DDNS, and it wasn't successful because it was setup to keep a tunnel broker IPv6 link active. I had IPv6 turned off, but hadn't turned off the DDNS. So I turned the IPv6 back on, and it is working, and so is the DDNS. Lets see if the behavior changes.

How would DDNS be related to openvpn? I'm not using it to update the openvpn client or server target domain name.

 

[JDA]

But maybe we are onto something. I have the tunnel broker tunnel up, and ddns says successful. I can log into the router and ping foreign ipv6 addresses. But I get this log entry over and over:

Jan 17 09:42:00 watchdog: start ddns.
Jan 17 09:42:00 ddns: eth0 has not yet obtained an WAN IPv6 address.(4)
Jan 17 09:42:00 ddns: IP address, server and hostname have not changed since the last update.

And now the firewall rules dropped a few minutes after turning the IPv6 back on.

 

[ColinTaylor]

How would DDNS be related to openvpn?

There are a few edge cases (DDNS may be one of them but I'm not 100% sure - the other being HE tunnels) where the firewall rules could be erased and restored without re-applying OpenVPN changes.

Correction: This particular case with tunnelbroker was patched but I suspect there may be other edge cases.

 

[JDA]

I think that the ipv6 tunnel is working fine, and the ddns to tunnelbroker is working fine, but the software is complaining because it somehow thinks that eth0 should get a new ipv6. With a tunnel, the ipv6 address is assigned to interface v6tun0, not eth0. Perhaps that causes the problem....

 

[JDA]

So I guess the next step is to disable ddns and see what happens. But it would be nice if this played together properly

 

[JDA]

I'm going to say now that the root cause of this problem was having DDNS setup to keep HE tunnelbroker updated. With DDNS off, there are no eth0 assignment errors in the log, and the firewall rules permitting traffic inbound over openvpn to the client subnet are persisting. I wonder if there would be an iptables rule drop if IPv6 were enabled over the openvpn link with the DDNS updating tunnelbroker; but I don't want IPv6 over the tunnel, and I don't need DDNS for tunnelbroker. I just added a script line in the relevant startup script on the router so it will update that way.