Asus AC68-u iptable rule question

[SomeWhereOverTheRainBow]

Awesome, I think this is a bit better then using dnsfilter. Maybe it works the same but I feel anything obviously is hardcoded to be force redirected. So primary rpi will be XX:XX mac and secondary rpi will be YY:YY mac? just double checking

It doesn't matter the order or preference on these as long as they are inserted after the first rule gets inserted. They were mainly examples to show you needed a rule for each one.

 

[josh3003]

It doesn't matter the order or preference on these as long as they are inserted after the first rule gets inserted. They were mainly examples to show you needed a rule for each one.

Do I run 'iptables -L' and that should show me that it has taken effect?

 

[ColinTaylor]

correct, skip the #3 one since you are only using #1 and #2.

Just to simplify, consider this in your nat-start script.

iptables -D PREROUTING ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.1.20 2>/dev/null
iptables -D PREROUTING ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.20 2>/dev/null
iptables -D PREROUTING -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN 2>/dev/null
iptables -D PREROUTING -i br0 -p udp -m udp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN 2>/dev/null
iptables -D PREROUTING -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN 2>/dev/null
iptables -D PREROUTING -i br0 -p udp -m udp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN 2>/dev/null
iptables -I PREROUTING ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.1.20
iptables -I PREROUTING ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.20
iptables -I PREROUTING -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN
iptables -I PREROUTING -i br0 -p udp -m udp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN
iptables -I PREROUTING -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN
iptables -I PREROUTING -i br0 -p udp -m udp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN

The first set of rules will delete the chains incase your nat-start script is somehow invoked more than once. I have not clue how many times the script gets invoked so it is always a good practice to prevent duplicate chains.

There's no need to delete existing rules in nat-start or firewall-start as each time the router runs them any existing rules are wiped out prior to building the new rules.

Of course if you're just running the script manually from the command line (rather than using service restart_firewall) that's a different matter (and the name of the script is irrelevant).

 

[dave14305]

This all should be happening in the nat table, not the filter table. Somewhere along the way the -t nat got lost in the iptables command.

 

[SomeWhereOverTheRainBow]

There's no need to delete existing rules in nat-start or firewall-start as each time the router runs them any existing rules are wiped out prior to building the new rules.

Of course if you're just running the script manually from the command line (rather than using service restart_firewall) that's a different matter (and the name of the script is irrelevant).

That may very well be the case. Are there instances you could think of where firewall-start runs without clearing the iptables?

 

[SomeWhereOverTheRainBow]

This all should be happening in the nat table, not the filter table. Somewhere along the way the -t nat got lost in the iptables command.

Added it to the last list of rules , nice catch. And as mentioned, I don't think they should be in firewall-start either without the deletes because I do not believe the nat table will be cleared as well on a firewall restart.

 

[josh3003]

I can just as easily place it in the different path.

Was there a modification made to the iptables rules with the -t Nat mentioned above??

 

[SomeWhereOverTheRainBow]

Do I run 'iptables -L' and that should show me that it has taken effect?

You should relook at the previous post and use the new rule format, I added -t nat to them. To view the rules you can do,

iptables -t nat -nvL

Rules should look like

iptables -D PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.1.20 2>/dev/null
iptables -D PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.20 2>/dev/null
iptables -D PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN 2>/dev/null
iptables -D PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN 2>/dev/null
iptables -D PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN 2>/dev/null
iptables -D PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN 2>/dev/null
iptables -I PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.1.20
iptables -I PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.20
iptables -I PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN
iptables -I PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN
iptables -I PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN
iptables -I PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN

 

[ColinTaylor]

Are there instances you could think of where firewall-start runs without clearing the iptables?

No, they're always reset using iptables-restore.

 

[SomeWhereOverTheRainBow]

No, they're always reset with the new rules (using iptables-restore).

This includes both nat and filter table operations I would assume then.

 

[dave14305]

Still not sure this is any better than DNSFilter, unless the HA VIP would have a different source MAC address than that of the 2 Pi-Holes.

 

[ColinTaylor]

This includes both nat and filter table operations I would assume then.

Yes. The rules are reloaded from /tmp/nat_rules and /tmp/filter_rules (and the IPv6 files if applicable)

That's not to say other processes/services won't come along and add their own rules. e.g. OpenVPN. But that's a separate thing.

P.S. I re-phrased my previous answer.

 

[SomeWhereOverTheRainBow]

Still not sure this is any better than DNSFilter, unless the HA VIP would have a different source MAC address than that of the 2 Pi-Holes.

May not have a different source, but it sounds like it possibly has a different IP address than the source mac addresses. At which case you must account for that which is done so at the end of the chain. Let's wait for the user to test it and report back.

 

[ColinTaylor]

Still not sure this is any better than DNSFilter, unless the HA VIP would have a different source MAC address than that of the 2 Pi-Holes.

One possible "advantage" of using DNSFilter is that it also blocks DoT traffic. The assumption being that the client will fall back to traditional DNS. But that could also be added to the custom script if required.

 

[SomeWhereOverTheRainBow]

One possible "advantage" of using DNSFilter is that it also blocks DoT traffic. The assumption being that the client will fall back to traditional DNS. But that could also be added to the custom script if required.

The only problem I could see with using dnsfilter is I am not sure it will account for not trying to redirect communications between the client pihole and the HI availability source itself, since it does not account for source and destination in the final rule of the chain before it applies its redirection..

 

[ColinTaylor]

The only problem I could see with using dnsfilter is I am not sure it will account for not trying to redirect communications between the client pihole and the HI availability source itself, since it does not account for source and destination in the final rule of the chain before it applies its redirection..

I didn't really understand how his devices are setup. For a "normal" LAN PiHole setup you'd need to create two separate DNSfilter rules, one being an exclusion for the PiHole and the other being for everything else. So DNSFiler creates two rules whereas the script above combines them into a single iptables statement.

 

[eibgrad]

Do NOT use firewall-start for NAT rules, or vice versa, use nat-start for NON NAT rules!

This is KNOWN to cause corruption of the firewall. I've been through this before w/ users who didn't even know it. They were getting weird behavior until I discovered they had done this and entire sections of their firewall were missing!

RT-AC86U - Firewall problem WAN

The asus router (192.168.1.1) is connected via the WAN interface with my other network (FritzBox; 192.168.178.1). The configured VPN tunnel will be established on my ASUS and all devices use the VPN provider for surfing and streaming. Everything is working except the access to my FritzBox...

www.snbforums.com

 

[SomeWhereOverTheRainBow]

Keeping in mind what everyone has said about placing the rules in nat-start @josh3003 have you had a chance to try this out?

 

[josh3003]

Keeping in mind what everyone has said about placing the rules in nat-start @josh3003 have you had a chance to try this out?

I haven't had a chance to change it yet. Though, now I am wondering whether to just delete the rule and run with DNSFilter as the others in the thread have mentioned..

 

[josh3003]

Also, I am on a 1000Mbps connection and have hw acceleration enabled. I find sometimes the speed does fluctuate a bit. Is it at these sorts of speeds that the router is beginning to show its age? Is it worth getting a more powerful router to support these speeds more consistently? Could imagine with the traffic redirection and other rules etc setup that looking at the cpu usage I am probably hitting the ceiling with this router?

Is that fair to say? I was contemplating looking at a newer model asus router or even the unifi dream machine as I do like the look of ubiquiti interface as well.