Recently (unfortunately, I can’t remember if this is related to the latest Core update to version 202), incoming connections to RED (192.168.80.0/24) for which a rule exists (see attached image below) are being dropped instead of being forwarded to the reverse proxy server (192.168.90.30) in the ORANGE zone.
I haven’t changed my firewall settings like: 'Firewall options for the red interface/Discard packets to and from malicious networks (Spamhaus DROP list, etc.)’enabled, ‘Default behaviour of the (input) firewall’DROP, since the rule was still working.
As a test, I have already tried out various settings during troubleshooting:
‘Source/Default networks:’ALL specified
‘Source/Hosts:’Router specified
‘Destination/Destination address:’ specified via IP address 192.168.90.30
‘IP address blocklists’disabled
‘Enable location-based filtering:’off
‘Discard packets to and from malicious networks (Spamhaus DROP list, etc.)’disabled
But none of this changed the behaviour or solved the problem and I’m running out of ideas now.
Has anyone else had this problem?
Any ideas on how to fix it? Many thanks in advance for any help.
The comma separated list of ports is also an allowed method for a Firewall Rule.
There was an issue with comma separated ports that some users found error messages in the iptables logs when using them but that issue was fixed in CU202. https://www.ipfire.org/blog/ipfire-2-29-core-update-202-released#misc
EDIT:
However the suggestion is worth trying out to see if there is any difference.
That would be true for when your red interface has a public IP but the user obviously has another router between the IPFire and the internet connection as red has a private ip address and in that case I believe that nat is not required.
EDIT:
However having the nat present won’t hurst so it is worth trying to see if it helps.
Yes, both IPFire devices are connected behind a router that already handles NAT, and I’d generally like to avoid double NAT.
Yes, I already have that group.
In the screenshot, I’ve manually added these two ports just for testing purposes and to make things clearer. Whether with or without that group, nothing has changed.
Exactly! When NAT is enabled, the connections are actually forwarded to the clients.
I don’t yet understand why it works like that, but that solves my problem for now.
Thank you all so much for taking the trouble to help me find a solution!
Forwarding itself does not change the destination IP, which, presumably needs to be IPF Red at the external router LAN. For that, you need a DNAT rule which is put in place by checking NAT.
There is (possibly) a complex alternative. At the external router, if it is allowed, you NAT the traffic to the IPF Orange IP, but then you need a route in the external router to the orange IP via the IPF red IP. At that point a simple Forward in IPF may work. Many routers will only allow you to port forward to a router LAN IP and not to a different subnet from the router LAN.
Thank you very much for your explanation.
I think that double NAT is still the simplest solution, and I’ll give the complex alternative a miss, especially as the router only allows port forwarding to a router’s LAN IP address, as you mentioned.
I’ve already had problems with this while setting up the PBX, which is why I had to put it into the RED zone.
I’m glad you found a solution to your problem, but I didn’t quite understand your first message where you seemed to be saying that this rule worked before CU202.
Yes, I suspected there was a connection in terms of timing with the update.
Unfortunately, I don’t keep a record of updates and rule changes (I know I should), so I can only speculate.
Maybe that some time ago, because I wanted to reduce double NAT in my rules, I removed the DNAT, and the rule may have continued to work for a short while because it was still in some sort of cache or similar, and maybe the cache then has been cleared when I rebooted the system after the update. I can’t quite remember.
In any case, based on your explanation, a causal link with the Core Update 202 can be ruled out.
