No Step Closer To A Fix.

[muffintastic]

Hello.

I've posted about this issue before and explained this issue countless times before, so I will try one more time.

Before I upgrade to the 384 branch of the firmware I was running 380.69_2 without any problems but since upgrading to the newest branch I'm constantly getting "nat: apply nat rules (/tmp/nat_rules_eth0_eth0) error!" if I change the DNS / Change Portforwarding or anything NAT related.

I have spoken to @RMerlin about this issue and followed his steps:

1. Replacing the Ethernet cable many times from router to modem.
2. Switching it off for 10 mins - Cures the problem for so long then back to square one.

This isn't an ISP issue because I used the provided router/modem combo for about 2 days without any issue, I just can't get a straight answer or being told it's my fault when clearly I've explained upgrading from 380 > 384 has broken it and I can't roll back to 380.xxx to fix this issue.

I have attached my logfile with the error. The only way to "temp" fix it is it turn off my router then back on again which gets old and tiredsome.

For some reason it won't allow me to attach files so I've uploaded my syslog.txt external to my mega account, virus scan included.

Currently on FW: 384.4_2 - Still hasn't fixed the issue.

Use Notepad++ to view the syslog.txt

virus scan: https://www.virustotal.com/#/file-a...1Y2M5OWRiMzMyYmM0OTk0YmNjNTA6MTUyMjUxMDk2Mg==

download:
https://mega.nz/#!DlE1BTiY!RGq7Tw0XwdtgpCbEAdLXvJQDtU1CsxeFR2IuxHul4eU

 

[ColinTaylor]

When the error has occurred have you tried looking at the contents of /tmp/nat_rules_eth0_eth0? It is complaining because when it tries to do an iptables-restore on that file it is getting a non-zero return code. The 380 branch of the firmware didn't bother checking the return code, so it's possible that command always returned an error for you.

 

[muffintastic]

When the error has occurred have you tried looking at the contents of /tmp/nat_rules_eth0_eth0? It is complaining because when it tries to do an iptables-restore on that file it is getting a non-zero return code. The 380 branch of the firmware didn't bother checking the return code, so it's possible that command always returned an error for you.

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:VSERVER - [0:0]
:LOCALSRV - [0:0]
:PUPNP - [0:0]
:VUPNP - [0:0]
:DNSFILTER - [0:0]
:PCREDIRECT - [0:0]
-A PREROUTING -d 5.xxx.xxx.xxx -j VSERVER
-A VSERVER  -p tcp -m tcp --dport 21875 -j DNAT --to-destination 10.0.0.18:21875
-A VSERVER  -p tcp -m tcp --dport 21876 -j DNAT --to-destination 10.0.0.18:21876
-A VSERVER  -p tcp -m tcp --dport 80:55706 -j DNAT --to 10.0.0.6
-A VSERVER  -p udp -m udp --dport 80:55706 -j DNAT --to 10.0.0.6
-A VSERVER  -p tcp -m tcp --dport 55656 -j DNAT --to-destination 10.0.0.18:55656
-A VSERVER  -p tcp -m tcp --dport 80:5223 -j DNAT --to 10.0.0.27
-A VSERVER  -p udp -m udp --dport 80:5223 -j DNAT --to 10.0.0.27
-A VSERVER  -p tcp -m tcp --dport 55413 -j DNAT --to-destination 10.0.0.17:55413
-A VSERVER -j VUPNP
-A POSTROUTING -o eth0 -j PUPNP
-A VSERVER -j TRIGGER --trigger-type dnat
-A POSTROUTING  -o eth0 ! -s 5.xxx.xxx.xxx -j MASQUERADE
-A POSTROUTING  -o br0 -s 10.0.0.0/24 -d 10.0.0.0/24 -j MASQUERADE
COMMIT

That's the contents currently with the error. Is there any fix to remove this check or anything?

 

[ColinTaylor]

Is there any fix to remove this check or anything?

I may have a workaround of sorts. Can you confirm the output of this command:

 

[RMerlin]

Try running the restore from the shell, it might give you the number of the line where the error occurs.

iptables-restore --verbose < /tmp/nat_rules_eth0_eth0

 

[muffintastic]

I may have a workaround of sorts. Can you confirm the output of this command:

View attachment 12552

Using username "admin".
[email protected]'s password:
Send automatic password


ASUSWRT-Merlin RT-AC3200 384.4-2 Sat Mar 24 17:02:27 UTC 2018
admin@RT-AC3200:/tmp/home/root# ls -1 /usr/sbin/*tables*
/usr/sbin/ebtables
/usr/sbin/ip6tables
/usr/sbin/ip6tables-restore
/usr/sbin/iptables
/usr/sbin/iptables-restore
/usr/sbin/iptables-save
/usr/sbin/xtables-multi
admin@RT-AC3200:/tmp/home/root#

 

[muffintastic]

Try running the restore from the shell, it might give you the number of the line where the error occurs.

iptables-restore --verbose < /tmp/nat_rules_eth0_eth0

If this error occurs again @RMerlin I will use that command and post my reply in my thread.

 

[ColinTaylor]

admin@RT-AC3200:/tmp/home/root# ls -1 /usr/sbin/*tables*

Sorry, it wasn't clear. That's a letter "l" not a number "1".

My workaround would only really be useful as a temporary fix and a debugging aid. But it sounds like you don't have the problem at the moment, or can't recreate it on demand?

 

[muffintastic]

Sorry, it wasn't clear. That's a letter "l" not a number "1".

My workaround would only really be useful as a temporary fix and a debugging aid. But it sounds like you don't have the problem at the moment, or can't recreate it on demand?

At this present time it working but I dare touch anything in the WAN section of the router like, DNS, PORT FORWARDING etc this will definietely create the issue. Once I get a spare five minutes when no-one is using the internet I will purposely create the problem then do the specified output.

In a working state withou the NAT ERROR! that code is like this:

 

[muffintastic]

Try running the restore from the shell, it might give you the number of the line where the error occurs.

iptables-restore --verbose < /tmp/nat_rules_eth0_eth0

@RMerlin so I had changed some settings in the WAN section and I had the error, I ran your code and got this:

I ran this without the NAT error or not changing anything in the WAN section beforehand and didn't have anything like that pop up.

Here is the error located on the specified line (high lighted):

 

[muffintastic]

I may have a workaround of sorts. Can you confirm the output of this command:

View attachment 12552

This is the output with the error when changing something in the WAN section:

 

[muffintastic]

As you can both see @RMerlin and @ColinTaylor with the detailed postings I'm stumped, now as of April 1st @ 8:26 BST I still have the error, this happens when changes are made in the WAN section of the router, dns, port forwarding, disable/enable UPNP etc and the only cure is to reboot and everything starts working again but as soon as a slight change is made in the WAN section boom it's broke. I am stumped..

 

[muffintastic]

@ 9:44 - I restarted my router and is back to normal. Here is a screenshot of /tmp/nat_rules_eth0_eth0 when the error isn’t present but changes that had been modified in the WAN section previously caused that NAT error to occur in /tmp/nat_rules_eth0_eth0:

Basically it's a loop, so if add a port forwarding now it will break on line 24 it adds something extra to
/tmp/nat_rules_eth0_eth0 and so forth. I'm not an expert in this, I'm only giving you guys whats happening and what's causing the issue when the something the WAN portion of the router is modified it breaks and the temp fix it to reboot. I can't say if it's software or hardware but hardware wise I've done everything to pin it down and can't stress enough using the ISP provided router hooked up to my external modem I don't have issues at all. I can't test official ASUS firmware because I need OPTION 60 as I'm on Sky Fibre UK which requires MAC clone, hence why I used this modded firmware from the early days.. Unless my RTAC3200 is broken I can only assume it's down to software, unless I'm wrong and if no one else can replicate the issue. It's down to something adding a line --to everytime that portion of the WAN section is modified as shown in my posts again this started happening in branch 384.xxx for me.

 

[ColinTaylor]

Looks like a bug or possibly a corrupted NVRAM variable. The code that generates the broken line is in firewall.c. But it shouldn't be doing that unless you have the DMZ enabled. Do you have DMZ enabled (WAN > DMZ)? Are you using dual-WAN or IPTV?

 

[RMerlin]

That rule is generated for the DMZ. Check your DMZ, it probably contains a space instead of being completely empty.

 

[muffintastic]

Looks like a bug or possibly a corrupted NVRAM variable. The code that generates the broken line is in firewall.c. But it shouldn't be doing that unless you have the DMZ enabled. Do you have DMZ enabled (WAN > DMZ)? Are you using dual-WAN or IPTV?

DMZ isn't enabled.

Not using dual wan or IPTV.

 

[muffintastic]

That rule is generated for the DMZ. Check your DMZ, it probably contains a space instead of being completely empty.

DMZ is disabled. I have no use for it.

 

[ColinTaylor]

Can you try this just to be sure:

echo ">"$(nvram get dmz_ip)"<"
nvram set dmz_ip=""
nvram commit

 

[muffintastic]

Can you try this just to be sure:

echo ">"$(nvram get dmz_ip)"<"
nvram set dmz_ip=""
nvram commit

Output:

 

[ColinTaylor]

You forgot this (just in case there are any invisible characters):

nvram set dmz_ip=""
nvram commit