Proxy inconsistencies

I hadn’t read as far back to see that PiHole is In Orange. In that case the SNAT rule should only be needed for other machines in the Orange network.

Yes, is possible. It’s a matter of doing some trials and testing, and reading a bit of documentation. But the operation is possible.:wink:

And what should this change? If I do DNAT port 123 for all green network and point to ipfire:123 nothing happens, only destination on port 123 will be blocked, because forward = blocked. There is no mystical interception and redirection to the point I have defined. If that were to happen, I wouldn’t receive a ‘blocked’ message, would I?

I don’t understand what you are saying. Sorry.

I have vague memories of ntp redirects not working, possibly due to the protocol, but it is years since I tried it.

It is the same with port 53 UDP. Doesn’t work. Destination is not redirect able, maybe it works for DMZ, but not for green.

What do you mean “Destination is not redirectable”? IIRC you can’t do it in the UI, because it is an edge case which trips up the UI which does not allow a redirect target in the same LAN, but it works at the command line. How are you doing it?

edge case? ok, if you have clients, with hardcoded destinations like Sound-Receiver, etc. you mostly can’t change the destination for timeserver or sometimes also DNS. So, you want to redirect this to ipfire but the destination is not redirectable.

I do it like this:

start)

## add your ‘start’ rules here

iptables -t nat -A CUSTOMPREROUTING -s Green -p udp --dport 123 -j DNAT --to-destination ipfire:123
iptables -t nat -A CUSTOMPREROUTING -s Green -p udp --dport 53 -j DNAT --to-destination ipfire:53
;;

stop)

## add your ‘stop’ rules here

iptables -t nat -D CUSTOMPREROUTING -s Green -p udp --dport 123 -j DNAT --to-destination ipfire:123
iptables -t nat -D CUSTOMPREROUTING -s Green -p udp --dport 53 -j DNAT --to-destination ipfire:53
;;

in the /etc/sysconfig/firewall.local

I never understand the Stop rules. They seem pointless. It should just be “iptables -F CUSTOMPREROUTING -t nat”

Really IPF should have it permanently in the custom rules to flush all CUSTOMxyz chains, or, even easier, on a firewall stop just flush all chains:

iptables -F
iptables -F -t nat
iptables -F -t mangle

It would save all the playing around with stop rules.

For DNS, also remember to redirect tcp:53.

Also, for a redirect, in the –to-destination, you don’t need to specify the port if you are not changing it.

if you do not set a stop rule and do /etc/sysconfig/firewall.local stop, nothing happens, the rules will stay in the iptables.
firewall.local is a script extra for custom edits.

ok, thank you for the hint.

Let’s phrase it differently. There should be no need for stop rules if the main IPF firewall stop command flushed all chains in all tables by default.

Even if it doesn’t flush everything, there is no need to delete the rules one by one when an iptables -F whatever will flush all custom rules from relevant chain in a single command.

Yes, but have a look in the iptables how many chains are there predefined and custom edits can be everything, and if you test a rule this start stop is nice to have.

I know, but a IMHO a firewall stop should flush everything. Even if it doesn’t, you have:

stop)

## add your ‘stop’ rules here

iptables -t nat -D CUSTOMPREROUTING -s Green -p udp --dport 123 -j DNAT --to-destination ipfire:123
iptables -t nat -D CUSTOMPREROUTING -s Green -p udp --dport 53 -j DNAT --to-destination ipfire:53

And, presumably you’re going to add a tcp:53 one as well. Why not just do iptables -F CUSTOMPREROUTING -t nat? It is much quicker and easier than individual deletes.

You are completely right, but what I miss is a way to make my tests lines from firewall.local as a part of the firewall itself and I only need to add the start rules.
I think firewall.local is not in the bootup routine and in /etc/init.d/firewall firewall.local is also not started.
firewall.local is test aria also for longer time, but if they are approved where to write this new lines?

Yes it is.

In the firewall initscript the firewallctrl miscellaneous program is run.
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/firewall;hb=ffc84170ee5003aa52e1dad23e5e911ed198716f#l537

firewallctrl runs rules.pl
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/misc-progs/firewallctrl.c;hb=ffc84170ee5003aa52e1dad23e5e911ed198716f#l16

and rules.pl runs firewall.local reload command if the file is present.

So when the firewall initscript is run then the added rules and/or other scripts specified that are in firewall.local are included\run.

Ahh and when you don’t write start stop rules the rules will always be added and never be flushed…

And my big question now:
Why should a NAT_DESTINATION rule be the same as a CUSTOMPREROUTING rule?

source GREEN

NAT Destination Firewall auto

Destination Firewall all
UDP PORT 123

will set a NAT_DESTINATION rule in iptables

iptables -t nat -A CUSTOMPREROUTING -s Green -p udp --dport 123 -j DNAT --to-destination ipfire

will set a CUSTOMPREROUTING in the iptables

Will both do the same or not?

The first rule in NAT_DESTINATION is written as REDIRECT.

The CUSTOMPREROUTING rule in /etc/firewall.local did the job before the REDIRECT NAT_DESTINATION made with the webGUI even could occur.

I have also a question to the firewall rules and the Tor addon, i want to use the socks5 proxy at port 9060, if i save the torrc file and start the addon, not really anything happens. In firewall mode forwarded block the rules seems to set automaticity, but if also firewall mode outgoing is on block, i find no rule which is set for this proxy, so what must i set in the iptables.

And only outgoing rules or more things to do? I can’t figure this out on my own, anybody can help me here, please?

That is because all the CUSTOM rules are run first, before the rest of the ruleset.

https://www.ipfire.org/docs/configuration/firewall/firewall-local#iptables-chains-for-custom-rules

Because the rules for the firewall itself are still defined in the code or by installing an addon. This only blocks all traffic between zones (including Red) but allowing all traffic from IPFire itself to go out.

This option blocks all traffic from IPFire itself, so rules have to be raised for all functions in IPFire itself that need access to somewhere.

https://www.ipfire.org/docs/configuration/firewall/default-policy#outgoing

https://www.ipfire.org/blog/firewall-configuration-recommendations-for-ipfire-users#allow-essential-connections-for-ipfire-itself

I can’t help with the above as I still have my IPFire with its default setting for these options.

ok, but must this traffic not get his own iptables “category/chain”? So if I made a rule for outgoing traffic on “all tcp/udp ports” that only the traffic through this Tor socks5 proxy on Port 9060 could reach this “destination”?
But even then, where is this rule like you said for the socksproxy?

In terms of the TOR addon, I can’t help you. I have never used it and don’t know what is needed for it.

Another user familiar with operating TOR will have to help.