Bug 12873

Summary: A port forwarding rule pointing to IPFire itself will cause the forwarded port to be exposed as well
Product: IPFire Reporter: Peter Müller <peter.mueller>
Component: ---Assignee: Michael Tremer <michael.tremer>
Status: ASSIGNED --- QA Contact:
Severity: Security    
Priority: Will only affect a few users CC: fkienker, michael.tremer
Version: 2   
Hardware: all   
OS: All   
Bug Depends on:    
Bug Blocks: 12278    

Description Peter Müller 2022-06-06 11:18:09 UTC 
https://community.ipfire.org/t/firewall-source-location-rule-ignored/7977/4

Steps to reproduce this behaviour:

1. Create a firewall rule with either a country or entire RED as a source, IPFire's RED interface as a destination, and portforwarding being configured from TCP port 443 to 222.

2. Reload the firewall engine to apply the rule.

3. Try to connect to IPFire from a machine on the internet (in the correct country, if configured): Both port 443 and 222 are publicly reachable.

However, based on the rule, one would expect to only port 443 being exposed.

This appears to be a bug in the firewall engine, although it only appears to affect port forwardings to IPFire itself, so it is not as bad as it could be.
Comment 1 Michael Tremer 2022-06-06 15:23:11 UTC 
This is kind of how the firewall works here. It does the NAT first, and then evaluates any filter rules. At that point, it does not know whether a packet was NATed before or not.

We could only fix this with a marker, but I am not sure if we can change packets at NAT time.

Since this is however unexpected behaviour, I would consider this a security-sensitive problem.
Comment 2 Fred Kienker 2022-08-17 14:14:56 UTC 
This seems related to this bug.

Core 169

Incoming port forwarding from various external ports on the firewall to port 22 on several internal servers had been working for some time. The location of these ports was set to the US. Suddenly, incoming traffic went to the servers on one particular firewall but no traffic was allowed out. Changing the selection from Location US to Standard Networks fixed the issue.