What's new

Voxel Help needed with iptables rules

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

@HELLO_wORLD , not to highjack someone elses thread here, but can I get you to check my iptables? DNS forward to both my piholes ( 10.0.0.3 & 10.0.04)

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p udp --dport 53 -j DNAT --to-destination 10.0.0.4
iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p udp --dport 53 -j DNAT --to-destination 10.0.0.4
iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 53 -j SNAT --to-source 8.8.8.8
iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 53 -j SNAT --to-source 8.8.4.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p tcp --dport 53 -j DNAT --to-destination 10.0.0.3
iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p tcp --dport 53 -j DNAT --to-destination 10.0.0.3
iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 53 -j SNAT --to-source 8.8.8.8
iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 53 -j SNAT --to-source 8.8.4.4

iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.3 -p tcp --dport 53 -j DNAT --to 10.0.0.3
iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.4 -p udp --dport 53 -j DNAT --to 10.0.0.4
iptables -t nat -A POSTROUTING -j MASQUERADE

iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.3 -p tcp --dport 853 -j DNAT --to 10.0.0.3
iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.4 -p udp --dport 853 -j DNAT --to 10.0.0.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p udp --dport 853 -j DNAT --to-destination 10.0.0.4
iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p udp --dport 853 -j DNAT --to-destination 10.0.0.4
iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 853 -j SNAT --to-source 8.8.8.8
iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 853 -j SNAT --to-source 8.8.4.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p tcp --dport 853 -j DNAT --to-destination 10.0.0.3
iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p tcp --dport 853 -j DNAT --to-destination 10.0.0.3
iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 853 -j SNAT --to-source 8.8.8.8
iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 853 -j SNAT --to-source 8.8.4.4

iptables -t mangle -N bolemo_ddos
iptables -t mangle -A PREROUTING -i brwan -j bolemo_ddos
iptables -t mangle -A bolemo_ddos -m conntrack --ctstate INVALID -j DROP
iptables -t mangle -A bolemo_ddos -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
iptables -t mangle -A bolemo_ddos -p icmp -m icmp --icmp-type 8 -m limit --limit 20/sec -j RETURN
iptables -t mangle -A bolemo_ddos -p icmp -m icmp --icmp-type 8 -j DROP
iptables -t mangle -A bolemo_ddos -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
iptables -t mangle -A bolemo_ddos -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
iptables -t mangle -A bolemo_ddos -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 10000/sec --limit-burst 100 -j RETURN
iptables -t mangle -A bolemo_ddos -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP


Thanks
I will look into this likely tomorrow, but to do so, can you tell me what your design (intent) is?
I see one pihole for UDP, another for TCP? Any particular reason?
 
1) Let's see what these rules are doing, putting them in the order they will be in your tables:

NAT PREROUTING

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p udp --dport 53 -j DNAT --to-destination 10.0.0.4
Any UDP DNS packet arriving through br0 (LAN) that are intended for 8.8.8.8 will be redirected to 10.0.0.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p udp --dport 53 -j DNAT --to-destination 10.0.0.4
Any UDP DNS packet arriving through br0 (LAN) that are intended for 8.8.4.4 will be redirected to 10.0.0.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p tcp --dport 53 -j DNAT --to-destination 10.0.0.3
Any TCP DNS packet arriving through br0 (LAN) that are intended for 8.8.8.8 will be redirected to 10.0.0.3

iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p tcp --dport 53 -j DNAT --to-destination 10.0.0.3
Any TCP DNS packet arriving through br0 (LAN) that are intended for 8.8.4.4 will be redirected to 10.0.0.3

iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.3 -p tcp --dport 53 -j DNAT --to 10.0.0.3
Any TCP DNS packet arriving through br-lan that are not coming from 10.0.0.3 will be redirected to 10.0.0.3
This makes previous rules about TCP DNS useless.
Do you have a br-lan interface?


iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.4 -p udp --dport 53 -j DNAT --to 10.0.0.4
Any UDP DNS packet arriving through br-lan that are not coming from 10.0.0.4 will be redirected to 10.0.0.3
This makes previous rules about UDP DNS useless.
Do you have a br-lan interface?


iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.3 -p tcp --dport 853 -j DNAT --to 10.0.0.3
Any TCP DoT (DNS over TLS) packet arriving through br-lan that are not coming from 10.0.0.3 will be redirected to 10.0.0.3
This makes previous rules about TCP DoT useless.
Do you have a br-lan interface?


iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.4 -p udp --dport 853 -j DNAT --to 10.0.0.4
Any UDP DoT (DNS over TLS) packet arriving through br-lan that are not coming from 10.0.0.4 will be redirected to 10.0.0.4
This makes previous rules about UDP DoT useless.
Do you have a br-lan interface?


iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p udp --dport 853 -j DNAT --to-destination 10.0.0.4
Any UDP DoT packet arriving through br0 (LAN) that are intended for 8.8.8.8 will be redirected to 10.0.0.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p udp --dport 853 -j DNAT --to-destination 10.0.0.4
Any UDP DoT packet arriving through br0 (LAN) that are intended for 8.8.4.4 will be redirected to 10.0.0.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p tcp --dport 853 -j DNAT --to-destination 10.0.0.3
Any TCP DoT packet arriving through br0 (LAN) that are intended for 8.8.8.8 will be redirected to 10.0.0.3

iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p tcp --dport 853 -j DNAT --to-destination 10.0.0.3
Any TCP DoT packet arriving through br0 (LAN) that are intended for 8.8.4.4 will be redirected to 10.0.0.4


NAT POSTROUTING

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 53 -j SNAT --to-source 8.8.8.8
Any UDP DNS packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 53 -j SNAT --to-source 8.8.4.4
Any UDP DNS packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.4.4
This rule is superseded by the previous one: it will never trigger as all concerned packets have already been changed to look like they came from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 53 -j SNAT --to-source 8.8.8.8
Any TCP DNS packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 53 -j SNAT --to-source 8.8.4.4
Any TCP DNS packet leaving through br0 (LAN) that are coming from 10.0.0.3 will be made that they are coming from 8.8.4.4
This rule is superseded by the previous one: it will never trigger as all concerned packets have already been changed to look like they came from 8.8.8.8

iptables -t nat -A POSTROUTING -j MASQUERADE
All packets leaving the router through any interface are made that they are coming from the router.
This rule does not make sense to me here.

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 853 -j SNAT --to-source 8.8.8.8
Any UDP DoT packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 853 -j SNAT --to-source 8.8.4.4
Any UDP DoT packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.4.4
This rule is superseded by the previous one: it will never trigger as all concerned packets have already been changed to look like they came from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 853 -j SNAT --to-source 8.8.8.8
Any TCP DoT packet leaving through br0 (LAN) that are coming from 10.0.0.3 will be made that they are coming from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 853 -j SNAT --to-source 8.8.4.4
Any TCP DoT packet leaving through br0 (LAN) that are coming from 10.0.0.3 will be made that they are coming from 8.8.4.4
This rule is superseded by the previous one: it will never trigger as all concerned packets have already been changed to look like they came from 8.8.8.8



2) Questions/remarks:

The rules are clearly not optimized.

  • why using two piHoles and separate UDP from TCP requests? One piHole would be enough…
  • you are diverting all DNS requests from your LAN to 8.8.8.8 and 8.8.4.4 to your piHoles. What about the requests to any other DNS resolver like 1.1.1.1? Do you want them to go through? or do you want all your LAN DNS requests to be diverted to your piHoles? Or only to some resolvers?
  • after that, you have rules that redirect any DNS requests to your piHoles anyway (the ones with br-lan, if the interface exists), making all the previous rules useless.
  • there are other issues, like the need of SNAT and masquerade…
  • to be able to help you with your rules, it is important to know what you want exactly: what do you want your piHole(s) to do? What do you want to divert and not, etc…
 
1) Let's see what these rules are doing, putting them in the order they will be in your tables:

NAT PREROUTING

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p udp --dport 53 -j DNAT --to-destination 10.0.0.4
Any UDP DNS packet arriving through br0 (LAN) that are intended for 8.8.8.8 will be redirected to 10.0.0.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p udp --dport 53 -j DNAT --to-destination 10.0.0.4
Any UDP DNS packet arriving through br0 (LAN) that are intended for 8.8.4.4 will be redirected to 10.0.0.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p tcp --dport 53 -j DNAT --to-destination 10.0.0.3
Any TCP DNS packet arriving through br0 (LAN) that are intended for 8.8.8.8 will be redirected to 10.0.0.3

iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p tcp --dport 53 -j DNAT --to-destination 10.0.0.3
Any TCP DNS packet arriving through br0 (LAN) that are intended for 8.8.4.4 will be redirected to 10.0.0.3

iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.3 -p tcp --dport 53 -j DNAT --to 10.0.0.3
Any TCP DNS packet arriving through br-lan that are not coming from 10.0.0.3 will be redirected to 10.0.0.3
This makes previous rules about TCP DNS useless.
Do you have a br-lan interface?


iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.4 -p udp --dport 53 -j DNAT --to 10.0.0.4
Any UDP DNS packet arriving through br-lan that are not coming from 10.0.0.4 will be redirected to 10.0.0.3
This makes previous rules about UDP DNS useless.
Do you have a br-lan interface?


iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.3 -p tcp --dport 853 -j DNAT --to 10.0.0.3
Any TCP DoT (DNS over TLS) packet arriving through br-lan that are not coming from 10.0.0.3 will be redirected to 10.0.0.3
This makes previous rules about TCP DoT useless.
Do you have a br-lan interface?


iptables -t nat -A PREROUTING -i br-lan ! -s 10.0.0.4 -p udp --dport 853 -j DNAT --to 10.0.0.4
Any UDP DoT (DNS over TLS) packet arriving through br-lan that are not coming from 10.0.0.4 will be redirected to 10.0.0.4
This makes previous rules about UDP DoT useless.
Do you have a br-lan interface?


iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p udp --dport 853 -j DNAT --to-destination 10.0.0.4
Any UDP DoT packet arriving through br0 (LAN) that are intended for 8.8.8.8 will be redirected to 10.0.0.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p udp --dport 853 -j DNAT --to-destination 10.0.0.4
Any UDP DoT packet arriving through br0 (LAN) that are intended for 8.8.4.4 will be redirected to 10.0.0.4

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 -p tcp --dport 853 -j DNAT --to-destination 10.0.0.3
Any TCP DoT packet arriving through br0 (LAN) that are intended for 8.8.8.8 will be redirected to 10.0.0.3

iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 -p tcp --dport 853 -j DNAT --to-destination 10.0.0.3
Any TCP DoT packet arriving through br0 (LAN) that are intended for 8.8.4.4 will be redirected to 10.0.0.4


NAT POSTROUTING

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 53 -j SNAT --to-source 8.8.8.8
Any UDP DNS packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 53 -j SNAT --to-source 8.8.4.4
Any UDP DNS packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.4.4
This rule is superseded by the previous one: it will never trigger as all concerned packets have already been changed to look like they came from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 53 -j SNAT --to-source 8.8.8.8
Any TCP DNS packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 53 -j SNAT --to-source 8.8.4.4
Any TCP DNS packet leaving through br0 (LAN) that are coming from 10.0.0.3 will be made that they are coming from 8.8.4.4
This rule is superseded by the previous one: it will never trigger as all concerned packets have already been changed to look like they came from 8.8.8.8

iptables -t nat -A POSTROUTING -j MASQUERADE
All packets leaving the router through any interface are made that they are coming from the router.
This rule does not make sense to me here.

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 853 -j SNAT --to-source 8.8.8.8
Any UDP DoT packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.4/32 -p udp --sport 853 -j SNAT --to-source 8.8.4.4
Any UDP DoT packet leaving through br0 (LAN) that are coming from 10.0.0.4 will be made that they are coming from 8.8.4.4
This rule is superseded by the previous one: it will never trigger as all concerned packets have already been changed to look like they came from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 853 -j SNAT --to-source 8.8.8.8
Any TCP DoT packet leaving through br0 (LAN) that are coming from 10.0.0.3 will be made that they are coming from 8.8.8.8

iptables -t nat -A POSTROUTING -o br0 -s 10.0.0.3/32 -p tcp --sport 853 -j SNAT --to-source 8.8.4.4
Any TCP DoT packet leaving through br0 (LAN) that are coming from 10.0.0.3 will be made that they are coming from 8.8.4.4
This rule is superseded by the previous one: it will never trigger as all concerned packets have already been changed to look like they came from 8.8.8.8



2) Questions/remarks:

The rules are clearly not optimized.

  • why using two piHoles and separate UDP from TCP requests? One piHole would be enough…
  • you are diverting all DNS requests from your LAN to 8.8.8.8 and 8.8.4.4 to your piHoles. What about the requests to any other DNS resolver like 1.1.1.1? Do you want them to go through? or do you want all your LAN DNS requests to be diverted to your piHoles? Or only to some resolvers?
  • after that, you have rules that redirect any DNS requests to your piHoles anyway (the ones with br-lan, if the interface exists), making all the previous rules useless.
  • there are other issues, like the need of SNAT and masquerade…
  • to be able to help you with your rules, it is important to know what you want exactly: what do you want your piHole(s) to do? What do you want to divert and not, etc…
Thanks, just trying to learn this stuff and optimize my iptable....my setup is simple, just trying to make sure all dns traffic is only through my 2 piholes
 
Thanks, just trying to learn this stuff and optimize my iptable....my setup is simple, just trying to make sure all dns traffic is only through my 2 piholes
Ok, and why 2 piHoles? Any particular reason?
 
Thanks, just trying to learn this stuff and optimize my iptable....my setup is simple, just trying to make sure all dns traffic is only through my 2 piholes

Anyway, here is the simplest rules to redirect all DNS traffic (UDP, TCP) and DoT (but not DoH as port 443 is used for regular HTTPS) to one piHole:
Bash:
iptables -t nat -I PREROUTING -i br0 -p udp --dport 53  ! -s 10.0.0.3 ! -d 10.0.0.3  -j DNAT --to 10.0.0.3
iptables -t nat -I PREROUTING -i br0 -p tcp --dport 53 ! -s 10.0.0.3 ! -d 10.0.0.3 -j DNAT --to 10.0.0.3
iptables -t nat -I PREROUTING -i br0 -p udp --dport 853 ! -s 10.0.0.3 ! -d 10.0.0.3 -j DNAT --to 10.0.0.3
iptables -t nat -I PREROUTING -i br0 -p tcp --dport 853 ! -s 10.0.0.3 ! -d 10.0.0.3 -j DNAT --to 10.0.0.3

As you can see, a lot simpler that the long list of rules you have…
That translates to:
Any TCP or UDP packet coming through the router from the LAN that is either on DNS or DoT port, is redirected to the piHole device at 10.0.0.3.
Packets that are already going to the piHole are left alone.
Packets that are coming from the piHole are left alone (as they need to get out of the LAN and reach the DNS resolvers that the piHole is using on the WAN).


You can after decide to send TCP packets to one piHole, and UDP packets to another, but I still don't see the need/point for that, and you would have to make the exception for both in the rules (to not see one piHole redirected to the other…)
The only reason I could see for 2 piHoles is load balancing (if one is undersized), and in that case separating UDP from TCP is not evenly balanced…
If you need load balancing, here is what you could use (untested):

Bash:
iptables -t nat -I PREROUTING -i br0 -p udp --dport 53 -m iprange ! --src-range 10.0.0.3-10.0.0.4 ! --dst-range 10.0.0.3-10.0.0.4 -m statistic --mode random --probability 0.5 -j DNAT --to 10.0.0.3
iptables -t nat -I PREROUTING -i br0 -p udp --dport 53 -m iprange ! --src-range 10.0.0.3-10.0.0.4 ! --dst-range 10.0.0.3-10.0.0.4 -j DNAT --to 10.0.0.4
iptables -t nat -I PREROUTING -i br0 -p tcp --dport 53 -m iprange ! --src-range 10.0.0.3-10.0.0.4 ! --dst-range 10.0.0.3-10.0.0.4 -m statistic --mode random --probability 0.5 -j DNAT --to 10.0.0.3
iptables -t nat -I PREROUTING -i br0 -p tcp --dport 53 -m iprange ! --src-range 10.0.0.3-10.0.0.4 ! --dst-range 10.0.0.3-10.0.0.4 -j DNAT --to 10.0.0.4
iptables -t nat -I PREROUTING -i br0 -p udp --dport 853 -m iprange ! --src-range 10.0.0.3-10.0.0.4 ! --dst-range 10.0.0.3-10.0.0.4 -m statistic --mode random --probability 0.5 -j DNAT --to 10.0.0.3
iptables -t nat -I PREROUTING -i br0 -p udp --dport 853 -m iprange ! --src-range 10.0.0.3-10.0.0.4 ! --dst-range 10.0.0.3-10.0.0.4 -j DNAT --to 10.0.0.4
iptables -t nat -I PREROUTING -i br0 -p tcp --dport 853 -m iprange ! --src-range 10.0.0.3-10.0.0.4 ! --dst-range 10.0.0.3-10.0.0.4 -m statistic --mode random --probability 0.5 -j DNAT --to 10.0.0.3
iptables -t nat -I PREROUTING -i br0 -p tcp --dport 853 -m iprange ! --src-range 10.0.0.3-10.0.0.4 ! --dst-range 10.0.0.3-10.0.0.4 -j DNAT --to 10.0.0.4

That would randomly send packets to one or the other with a 50:50 probability.
 
I keep coming back to this. Is there absolutely no way using MASQUERADE rules or such where I can preserve the source IP of the client making the DNS requests?
 
I keep coming back to this. Is there absolutely no way using MASQUERADE rules or such where I can preserve the source IP of the client making the DNS requests?
In the eyes of who? PiHole? 8.8.8.8?
I am not sure I understand…

The rules posted have the local clients DNS requests forced to go to PiHole, and the PiHole is the resolver who translates DN to IP and send it back to the respective local clients.

You mean you want whatever server used by PiHole (like 8.8.8.8) to see the request coming from the original local client? Why do you need PiHole and rules then? Just remove PiHole and all rules and have clients make direct DNS requests to the servers.
 
I want the DNS server to see the source IP of the client making the DNS request. Currently all appear to come from the router itself.

Code:
iptables -t nat -I PREROUTING -p tcp --dport 53 ! -s 10.0.0.10 ! -d 10.0.0.10 -j DNAT --to 10.0.0.10
iptables -t nat -I PREROUTING -p udp --dport 53 ! -s 10.0.0.10 ! -d 10.0.0.10 -j DNAT --to 10.0.0.10
iptables -t nat -I POSTROUTING -d 10.0.0.10 -j SNAT --to 10.0.0.1
 
I want the DNS server to see the source IP of the client making the DNS request. Currently all appear to come from the router itself.

Code:
iptables -t nat -I PREROUTING -p tcp --dport 53 ! -s 10.0.0.10 ! -d 10.0.0.10 -j DNAT --to 10.0.0.10
iptables -t nat -I PREROUTING -p udp --dport 53 ! -s 10.0.0.10 ! -d 10.0.0.10 -j DNAT --to 10.0.0.10
iptables -t nat -I POSTROUTING -d 10.0.0.10 -j SNAT --to 10.0.0.1
By DNS Server, you mean PiHole, right?

I suspect it is because of the POSTROUTING rule… It makes everything going to 10.0.0.10 like it is coming from 10.0.0.1 (your router).
You need to put your PiHole in the main subnet of your LAN to avoid this rule.
 
I do not use Pihole but AdGuard Home, but yes.

If I remove the POSTROUTING rule, this how DNS queries appear:

Code:
~ ❯ dig @1.1.1.1 google.com
;; reply from unexpected source: 10.0.0.10#53, expected 1.1.1.1#53

;; reply from unexpected source: 10.0.0.10#53, expected 1.1.1.1#53

;; reply from unexpected source: 10.0.0.10#53, expected 1.1.1.1#53


; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

BTW, all are in the same subnet. This query was made from 10.0.0.11.
 
Last edited:
There's this Reddit post where the user uses the following rules:

Code:
iptables -t nat -A PREROUTING -i br-lan -p udp ! --source piholeIP ! --destination piholeIP --dport 53 -j DNAT --to piholeIP
iptables -t nat -A PREROUTING -i br-lan -p tcp ! --source piholeIP ! --destination piholeIP --dport 53 -j DNAT --to piholeIP

iptables -t nat -N DNSFILTER
iptables -t nat -A DNSFILTER -j DNAT --to-destination piholeIP   
iptables -t nat -I prerouting_lan_rule -p tcp ! --source piholeIP --dport 53 -j DNSFILTER
iptables -t nat -I prerouting_lan_rule -p udp ! --source piholeIP --dport 53 -j DNSFILTER

I'm not sure what "prerouting_lan_rule" means here but could it work?
 
These rules won't work as is.
Going out all afternoon, so will look over the weekend or this evening if I have time.
 
I do not use Pihole but AdGuard Home, but yes.

If I remove the POSTROUTING rule, this how DNS queries appear:

Code:
~ ❯ dig @1.1.1.1 google.com
;; reply from unexpected source: 10.0.0.10#53, expected 1.1.1.1#53

;; reply from unexpected source: 10.0.0.10#53, expected 1.1.1.1#53

;; reply from unexpected source: 10.0.0.10#53, expected 1.1.1.1#53


; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

BTW, all are in the same subnet. This query was made from 10.0.0.11.

I just tested this:
router = 192.168.1.1
MacBook = 192.168.1.4
test DNS server in Azure = 10.40.0.10
I have an OPNsense firewall on a VM (192.168.1.5) that maintains an IPsec tunnel to Azure and routes the traffic there

On the router I added only these 2 rules
iptables -t nat -I PREROUTING -p tcp --dport 53 ! -s 10.40.0.10 ! -d 10.40.0.10 -j DNAT --to 10.40.0.10
iptables -t nat -I PREROUTING -p udp --dport 53 ! -s 10.40.0.10 ! -d 10.40.0.10 -j DNAT --to 10.40.0.10

after this DNS lookups still work fine
Code:
richard@MacBook-Pro-van-Richard ~ % dig  @1.1.1.1 google.com
; <<>> DiG 9.10.6 <<>> @1.1.1.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54664
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000

;; QUESTION SECTION:
;google.com.    IN    A

;; ANSWER SECTION:
google.com.    10    IN    A    142.250.179.206

;; Query time: 20 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Mar 18 16:33:03 CET 2022
;; MSG SIZE  rcvd: 55

And when checking with netmon.exe on the DNS server, I see that the
Code:
902    4:33:03 PM 3/18/2022    12.0310643    dns.exe    192.168.1.4    10.40.0.10    DNS    DNS:QueryId = 0xD588, QUERY (Standard query), Query  for google.com of type Host Addr on class Internet    {DNS:82, UDP:81, IPv4:1}
903    4:33:03 PM 3/18/2022    12.0315590    dns.exe    10.40.0.10    192.168.1.4    DNS    DNS:QueryId = 0xD588, QUERY (Standard query), Response - Success, 142.250.179.206     {DNS:82, UDP:81, IPv4:1}

And in Wireshark on my MacBook, I see as the last packet that is arriving:
Code:
Ethernet II, Src: Netgear_xx:xx:xx (cc:40:d0:xx:xx:xx), Dst: Apple_xx:xx:xx (ac:bc:32:xx:xx:xx)
Internet Protocol Version 4, Src: 1.1.1.1, Dst: 192.168.1.4
User Datagram Protocol, Src Port: 53, Dst Port: 49555

Thus in my situation it is working correctly.

It seems that the issue is that your source and destination are on the same network. And that thus the DNS response from AGH is directly sent towards the requestor -> It isn't sent via the router, so the route isn't changing the IP-address back.

So it seems that only options are to either move the AGH to a different subnet, so that traffic from and to AGH is always going via the router.
Or move the AGH to the router itself
 
I want the DNS server to see the source IP of the client making the DNS request. Currently all appear to come from the router itself.

Code:
iptables -t nat -I PREROUTING -p tcp --dport 53 ! -s 10.0.0.10 ! -d 10.0.0.10 -j DNAT --to 10.0.0.10
iptables -t nat -I PREROUTING -p udp --dport 53 ! -s 10.0.0.10 ! -d 10.0.0.10 -j DNAT --to 10.0.0.10
iptables -t nat -I POSTROUTING -d 10.0.0.10 -j SNAT --to 10.0.0.1
You do not need SNAT/MASQUERADE rule if you want to keep the source IP as it is when the request reaches RP4/DNS server, in your case ADH. SNAT/MASQUERADE rule will replace source IP with router IP.

I use dnsmasq on RP4 for ad filtering and dns caching and I do not want source IP replaced with router IP in my dnsmasq logs. I use below rules in router firewall script. All my devices are in same subnet.

Code:
#!/bin/sh

RP4='10.1.1.2'
iptables -t nat -I PREROUTING -i br0 -p udp ! -s $RP4 ! -d $RP4 --dport 53 -j DNAT --to $RP4:53
iptables -t nat -I PREROUTING -i br0 -p tcp ! -s $RP4 ! -d $RP4 --dport 53 -j DNAT --to $RP4:53

Dig response:
1647640059238.png


Dnsmasq logs show request from the ip of the client that sent it:
1647639974812.png
 
Last edited:
Does a factory reset wipe all iptables rules? Or is there a simpler way to just reset the firewall rules to default values?
 
Does a factory reset wipe all iptables rules?
I assume you meant to delete all custom added rules. Factory reset remove all custom added rules. As long as you do not have 'firewall-start.sh' script on usb with 'post-mount.sh' to automatically add them back again.

Or is there a simpler way to just reset the firewall rules to default values?
It depends how you added them.

If you added rules manually by running iptables cmds from shell/telnet. Reboot router or restart ng firewall.
If you added them from script 'firewall-start.sh', remove/rename firewall script then reboot router or restart ng firewall.

Restart NG Firewall:
Code:
net-wall rule
net-wall start

If you added them from some UI setting you have to remove that UI setting or Reset factory defaults. (Port forwarding, port scan, block services ... and few other settings add firewall rules from UI)
 
Last edited:
To sum up:
Each time you call net-wall start or net-wall restart iptables wipes out all custom rules, and start/restart fresh; then it executes whatever is in firewall-start.sh
 
Similar threads

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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