Hey fellas
I have some custom iptables rules that are based on domain names, so I need to reload those custom rules to update the IPs in case they change.
I tried "/etc/init.d/firewall reload" and that won't reload the custom rules "firewall.user". Just everything else.
Only by running "/etc/init.d/firewall restart" do those rules get reloaded.
The problem is that with "restart" all active connections get dropped. Is there a way for me to reload firewall.user without dropping the connections? 99.99999% of the time the IPs are the same.
Thank you so much!
trendy
February 10, 2023, 12:42pm
2
Have you consider using a dns based ipset? It does what you want and it is automatically updating the IPs.
3 Likes
frollic
February 10, 2023, 12:45pm
3
since you have the domain names, use the adblock package ?
2 Likes
Hi trendy
Will that reload the custom rules?
grrr2
February 10, 2023, 12:56pm
5
no, will not. but instead of updating the rule manually with the domain's ip address, you can reference to an ipset as placeholder, and just add the ip addresses whenever you want to the ipset. firewall rule will check the ipset and match rule against all members of the set to compare against the active connection's ip address. and all this runtime, any time you can add/remove ip address to ipset, the next firewall match will happen against the latest ipset content.
2 Likes
Ok thanks. I'll look into it.
Still I'd love to know what the command is for reloading the custom firewall rules. Anyone?
grrr2
February 10, 2023, 1:00pm
7
i dont think you can reload just the custom rules, but maybe i'm wrong so let's wait someone to answer this. this is a good question.
1 Like
pavelgl
February 10, 2023, 1:19pm
8
config include
option path '/etc/firewall.user'
option reload '1'
This will do what you want, but there is a side effect.iptables -F my_chain at the beginning of /etc/firewall.user
3 Likes
alcatraz:
domain names, so I need to reload those custom rules to update the IPs in case they change.
I tried "/etc/init.d/firewall reload" and that won't reload the custom rules "firewall.user". Just everything else.
Only by running "/etc/init.d/firewall restart" do those rules get reloaded.
The problem is that with "restart" all active connections get dropped. Is there a way for me to reload firewall.user without dropping the connections? 99.99999% of the time the IPs are the same.
Thank you so much!
That's an interesting idea.
I'm using two chains, uh-oh. PREROUTING and POSTROUTING.
If I flush those two I'm afraid I might disturb the other rules outside of custom. Do you think that could happen?
I ran "iptables -t nat --list" and I don't see other rules in those two chains. Should be safe then?
pavelgl
February 10, 2023, 1:43pm
10
Use the existing empty custom chains prerouting_rule and postrouting_rule.
root@ArcherA7:~# iptables -t nat -nvL PREROUTING | head -n 3
Chain PREROUTING (policy ACCEPT 1801 packets, 465K bytes)
pkts bytes target prot opt in out source destination
1947 474K prerouting_rule all -- * * 0.0.0.0/0 0.0.0.0/0 /* !fw3: Custom prerouting rule chain */
root@ArcherA7:~# iptables -t nat -nvL POSTROUTING | head -n 3
Chain POSTROUTING (policy ACCEPT 3 packets, 144 bytes)
pkts bytes target prot opt in out source destination
454 112K postrouting_rule all -- * * 0.0.0.0/0 0.0.0.0/0 /* !fw3: Custom postrouting rule chain */
2 Likes
iptables -F prerouting_rule
iptables -F postrouting_rule
I tried this and POSTROUTING / PREROUTING but I'm getting
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
If I list all my NAT rules I have this:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
prerouting_rule all -- anywhere anywhere /* !fw3: Cus tom prerouting rule chain */
zone_lan_prerouting all -- anywhere anywhere /* !fw3 */
zone_wan_prerouting all -- anywhere anywhere /* !fw3 */
DNAT tcp -- anywhere anywhere tcp dpt:63887 to:X.X.X.X:443
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
postrouting_rule all -- anywhere anywhere /* !fw3: Cu stom postrouting rule chain */
zone_lan_postrouting all -- anywhere anywhere /* !fw3 */
zone_wan_postrouting all -- anywhere anywhere /* !fw3 */
SNAT tcp -- anywhere X.X.X.X to: Y.Y.Y.Y
Chain postrouting_lan_rule (1 references)
target prot opt source destination
Chain postrouting_rule (1 references)
target prot opt source destination
Chain postrouting_wan_rule (1 references)
target prot opt source destination
Chain prerouting_lan_rule (1 references)
target prot opt source destination
Chain prerouting_rule (1 references)
target prot opt source destination
Chain prerouting_wan_rule (1 references)
target prot opt source destination
Chain zone_lan_postrouting (1 references)
target prot opt source destination
postrouting_lan_rule all -- anywhere anywhere /* !fw3 : Custom lan postrouting rule chain */
SNAT tcp -- 192.168.81.0/24 UltraBird.lan tcp dpt:21823 /* ! fw3: UltrabirdTorrent (reflection) */ to:192.168.81.1
SNAT udp -- 192.168.81.0/24 UltraBird.lan udp dpt:21823 /* ! fw3: UltrabirdTorrent (reflection) */ to:192.168.81.1
Chain zone_lan_prerouting (1 references)
target prot opt source destination
prerouting_lan_rule all -- anywhere anywhere /* !fw3: Custom lan prerouting rule chain */
DNAT tcp -- 192.168.81.0/24 192.168.2.11 tcp dpt:21823 /* ! fw3: UltrabirdTorrent (reflection) */ to:192.168.81.199:21823
DNAT udp -- 192.168.81.0/24 192.168.2.11 udp dpt:21823 /* ! fw3: UltrabirdTorrent (reflection) */ to:192.168.81.199:21823
Chain zone_wan_postrouting (1 references)
target prot opt source destination
postrouting_wan_rule all -- anywhere anywhere /* !fw3 : Custom wan postrouting rule chain */
MASQUERADE all -- anywhere anywhere /* !fw3 */
Chain zone_wan_prerouting (1 references)
target prot opt source destination
prerouting_wan_rule all -- anywhere anywhere /* !fw3: Custom wan prerouting rule chain */
DNAT tcp -- anywhere anywhere tcp dpt:21823 /* ! fw3: UltrabirdTorrent */ to:192.168.81.199:21823
DNAT udp -- anywhere anywhere udp dpt:21823 /* ! fw3: UltrabirdTorrent */ to:192.168.81.199:21823
Any idea of what's wrong? Thanks for your time by the way. What a champ!
Woops
I got it to not produce errors with
iptables -t nat -F prerouting_rule
But I still get duplicates upon reload.
I'll try zone_wan_prerouting + postrouting.
pavelgl
February 10, 2023, 2:16pm
13
The rules should be moved from the PREROUTING and POSTROUTING chains to the custom chains.
Example:
iptables -t nat -A prerouting_rule -m udp -p udp -s 192.168.1.0/24 --dport 53 -j DNAT --to-destination 192.168.1.96:53
iptables -t nat -A postrouting_rule -m udp -p udp -s 192.168.1.0/24 -d 192.168.1.96/32 --dport 53 -j SNAT --to-source 192.168.1.1
iptables -t nat -nvL prerouting_rule; iptables -t nat -nvL postrouting_rule
2 Likes
Ahh, I see. Fixed!
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule
iptables -t nat -A prerouting_rule -p tcp -m tcp --dport 63887 -j DNAT --to-destination `dig x.com +short`:443
iptables -t nat -A postrouting_rule -p tcp -d `dig x.com +short`/32 -j SNAT --to-source `dig y.com +short`
iptables -A FORWARD -s `dig x.com +short`/32 -j ACCEPT
iptables -A FORWARD -d `dig x.com +short`/32 -j ACCEPT
I'm having issues with the two FORWARD and ACCEPT commands. They seem to need editing as well. (They worked when I was using the previous chains.)
pavelgl
February 10, 2023, 2:33pm
15
iptables -F forwarding_rule
iptables - A forwarding_rule -s ...
iptables - A forwarding_rule -d ...
iptables -nvL forwarding_rule
EDIT:
alcatraz:
`dig x.com +short`/32
This will not work as intended if dig returns multiple IP addresses.ipset as @trendy already suggested
2 Likes
I'm only getting one address.
Seems I need to create forwardning_rule. The other two existed from the start.
This is where I am right now, and I get an error probably at trying to add into the chain forwarding_rule. I can't see it in the list.
iptables -t nat -F forwarding_rule
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule
iptables -t nat -A prerouting_rule -p tcp -m tcp --dport 63887 -j DNAT --to-destination `dig x.com +short`:443
iptables -t nat -A postrouting_rule -p tcp -d `dig x.com +short`/32 -j SNAT --to-source `dig y.com +short`
iptables -A forwarding_rule -s `dig x.com +short`/32 -j ACCEPT
iptables -A forwarding_rule -d `dig x.com +short`/32 -j ACCEPT
iptables -t nat -nvL forwarding_rule
iptables -t nat -nvL prerouting_rule
iptables -t nat -nvL postrouting_rule
I need to study up on ipset. It's on my todo list. Phew.
I sincerely appreciate your patience with me.
1 Like
iptables -F forwarding_rule
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule
iptables -t nat -A prerouting_rule -p tcp -m tcp --dport 63887 -j DNAT --to-destination `dig x.com +short`:443
iptables -t nat -A postrouting_rule -p tcp -d `dig x.com +short`/32 -j SNAT --to-source `dig y.com +short`
iptables -A forwarding_rule -s `dig x.com +short`/32 -j ACCEPT
iptables -A forwarding_rule -d `dig x.com +short`/32 -j ACCEPT
iptables -nvL forwarding_rule
iptables -t nat -nvL prerouting_rule
iptables -t nat -nvL postrouting_rule
I'm here now and it won't route the packets the same way as:
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 63887 -j DNAT --to-destination `dig x.com +short`:443
iptables -t nat -A POSTROUTING -p tcp -d `dig x.com +short`/32 -j SNAT --to-source `dig y.com +short`
iptables -A FORWARD -s `dig x.com +short`/32 -j ACCEPT
iptables -A FORWARD -d `dig x.com +short`/32 -j ACCEPT
pavelgl
February 10, 2023, 5:46pm
20
The essential difference between the two variations is that in the first variant the rules are inserted at the beginning of the FORWARD, PREROUTING and POSTROUTING chains, while in the second variant they are added at their end.
A complete review of the firewall is required to discover the reasons for the different behavior, but at first glance, under normal circumstances the rules below shouldn't do any work, because they will be added after the last rule in the FORWARD chain, which rejects everything.
EDIT:
Just to clarify that these commands are used to verify that the rules are created and there are hits. They don't need to be added to /etc/firewall.user.
1 Like