Forums

Resolved
0 votes
There is an update to app-firewall available for testing. You can install it with:
yum update app-firewall --enablerepo=clearos-updates-testing
For most users with a single LAN, there should be no change.

Multi-LAN
This will only affect you if you use port forwarding. If you have MachineA on LAN A and Machine B on LAN B and you use port forwarding to Machine A, if you try to access Machine A on its port forwarded port from LAN B then traffic currently appears at Machine A as if it comes from ClearOS's LAN A IP and not from Machine B. This rule was there so you could access Machine A from LAN B using your WAN IP but it is unnecessary as you can do that without the rule in place.

Multi-LAN, 1-to-1 NAT
In this case the current ClearOS behaviour is seemingly unpredictable. Really it is predictable but depends on the alpha-numeric naming of your 1-to-1 NAT rules which is not good. I Let's take the following scenario:

|-- Machine A1 (192.168.36.2 and 1.1.1.3 by 1-to-1 NAT)
|-- LAN A --|-- Machine A2
| |-- Machine A3 etc
ClearOS --|
(1.1.1.0/29) |
| |-- Machine B1 (192.168.168.2 and 1.1.1.4 by 1-to-1 NAT)
|-- LAN B --|-- Machine B2
|-- Machine B3 etc

The current behaviour is a follows:
Same LAN traffic originating from A1 never goes to ClearOS so it always appears to come from 192.168.36.2 to A2, A3 etc
Same LAN traffic originating from B1 never goes to ClearOS so it always appears to come from 192.168.36.2 to B2, B3 etc
Traffic from A1 to B1 should appear to come from 1.1.1.3 and can do depending on the 1-to-NAT rule ordering.
In that case, traffic from B1 to A1 should appear to come from 1.1.1.4 but will, in fact appear to come from 192.168.168.1 if the rule above works.
Rule order is dependent on the rule name in the 1-to-1 NAT module. If the rule order is reversed, the behaviour reverses.
Traffic from A1 to B2 will appear to come from 1.1.1.3 (as designed)
Traffic from B1 to A2 to come from 192.168.168.1! (design was to come from 1.1.1.4)
In fact traffic from all LAN B to A1 will appear to A1 as if it is coming from 192.168.168.1 (there is a reason for that in that it was thought it would allow LAN B to access A1 by it WAN IP (1.1.1.3), but this is allowed anyway without the rule).
Traffic from all LAN A except A1 to B1 will appear to B1 as if it is coming from 192.168.36.1 (there is a reason for that in that it was thought it would allow LAN B to access A1 by it WAN IP (1.1.1.4), but this is allowed anyway without the rule).

The updated behaviour is:
Same LAN traffic originating from A1 never goes to ClearOS so it always appears to come from 192.168.36.2 to A2, A3 etc (no change)
Same LAN traffic originating from B1 never goes to ClearOS so it always appears to come from 192.168.36.2 to B2, B3 etc (no change)
Traffic from A1 to B1 will always appear to come from 1.1.1.3 irrespective of 1-to-NAT rule ordering.
Traffic from B1 to A1 will always appear to come from 1.1.1.4 irrespective of 1-to-NAT rule ordering.
Traffic from LAN A except from A1 to B1 will always come from the LAN A machine's IP. LAN A can still access B1 by its WAN IP but traffic will appear to come from the machines LAN IP rather than the ClearOS LAN A IP.
Traffic from LAN B except from B1 to A1 will always come from the LAN B machine's IP. LAN B can still access A1 by its WAN IP but traffic will appear to come from the machines LAN IP rather than the ClearOS LAN B IP.
uPnP traffic from A1 and B1 (any 1-to-1 NAT LAN machine) is blocked as it was setting up port forwards and doing other things which were taking precedence over 1-to-1 NAT.

This then becomes a predictable behaviour and is as apparently designed. It also has an added simplification that traffic from one LAN to the other LAN will always appear from its own IP instead of sometimes appearing from the ClearOS LAN IP if there were a 1-to-1 NAT rule.

If it causes any breakages, you can revert to the earlier release with:
yum downgrade app-firewall app-firewall-core


Please post any issues you see in this thread
Wednesday, January 19 2022, 04:00 PM
Share this post:
Responses (2)
  • Accepted Answer

    Thursday, March 10 2022, 03:42 PM - #Permalink
    Resolved
    0 votes
    Does this mean you're back Nick?
    The reply is currently minimized Show
  • Accepted Answer

    Georgina
    Georgina
    Offline
    Friday, March 11 2022, 02:05 AM - #Permalink
    Resolved
    0 votes
    Looks like nothing more than a repost by someone of one of Nick's previous posts - was first posted Wednesday, January 19 2022, 04:00 PM.

    In the meantime there have been a number of updates to CentOS 7 that have not flowed to ClearOS 7 including an updated kernel. ClearOS management clearly would seem to have no concern of the security of ClearOS systems and abandoned ClearOS 7. At least for the Community Edition as that is all I have. Have any of you who have a paid edition seen an update since Nick left? If not, why not put in a support ticket that updates have stopped and ask why, then let us know what the response is...
    The reply is currently minimized Show
Your Reply