Strange behaviour of firewall OUT rules

[it_hardway]

Hi Demusman, thank you for the reply, your analogy is great!

Short answer, don't use OUT as a direction. It will only ever apply to floating rules and floating rules should not be used unless absolutely neccessary.
...
So never use OUT as a direction on an interface rule. It really shouldn't even be an option except on Floating rules.

Could you explain please, why the OUT direction can be evaluated only on floating rules? My original goal was to block some ip addresses in internet in some cases. Basically you are right, it can be done by blocking an inbound traffic on the LAN interface using an IN rule. But it will not block packets, issued by the firewall host itself. In this case there will be no inbound traffic at all, the packets will be created by the firewall host directly on the WAN interface. As of my understanding these packets can be blocked only using an OUT rule. I've created and tested such OUT rule on the WAN interface directly (not a floating one) - and it seems to work.

[Demusman]

You can't block anything generated by the firewall itself if that's what you're trying to do.
All rules are evaluated on the IN of the interfaces, the firewall would never generate traffic INTO an interface.

If you want to block traffic from the internet, you put the rules on the WAN.
Again, IN to an interface is traffic generated from the directly connected network of that interface. So the WAN would be directly connected to the internet by way of your WAN Network alias.

Can I ask, why would you want to block traffic from the firewall itself?? What exactly is being generated there?

[meyergru]

If you did not try and put all your logic into one rule with direction "any", but separate them out into two rules for in and out, you could then easily switch them on and off at will to further inspect and see which way packets are blocked and go further from there.

That is what I meant by 'isolate a single "problem"'.

Your setup only seemed minimal, since by using only one interface, you had to use the "unusual" out direction (in fact, you even contracted two rules into one by using "any"). Usually, as Demusman said, you filter in the "in" direction at whatever is coming at the firewall from either LAN or WAN. Unless the firewall is infected, you do not have to control what leaves it.

While it may be instructive to bang your head at such points, to get something done, it may be easier to "got with the flow" and do things as they are expected to be done.

[it_hardway]

You can't block anything generated by the firewall itself if that's what you're trying to do.

Yes, my goal is to block all kinds of outgoing traffic under certain circumstances, even if it was originated by the firewall itself. It seems to be possible to implement such behaviour. For example, by executing of a ping command directly at the firewall, it creates ICMP packets on the WAN interface. These packets can be captured and blocked by the follow OUT rule on the WAN interface:

Code: [Select]

Action: Block
Quick: Yes
Interface: WAN
Direction: Out
Protocol: ICMP
Destination: 8.8.8.8
Log: Yes
Description: Block ICMP to Google DNS

Firewall log:



The packet was blocked. There are no packets in the tcpdump also:



Ping to other hosts works properly. Follow your analogy, if a baby is born in this house, the only way to close exits to a dangerous street is to catch it when it will try to go thru a door

Can I ask, why would you want to block traffic from the firewall itself?? What exactly is being generated there?

Well, there are couple of reasons:

• If someone will get a non-admin access to the firewall, he will be able to send information to blocked servers in internet (but not to change rules!). In my situation some colleagues must have such access rights.
• Theoretically a kind of malware can be executed on the firewall, which will forward some traffic to the blocked internet servers. The IN rules will not help in this case.
• If I make an error by maintenance or reconfiguring the firewall, such blocking rule on WAN interface would be an additional protection, that guaranties, that not a single packet will be sent to the blocked servers.

[it_hardway]

If you did not try and put all your logic into one rule with direction "any", but separate them out into two rules for in and out, you could then easily switch them on and off at will to further inspect and see which way packets are blocked and go further from there.

The floating rules like "any direction on any interface <some_condition>" are useful for logging packets matching the <some_condition>. So you can discover for example, in which direction and on which interfaces the packets are flowing. Also I've found out, that Any-Direction-Rules have no gateway / reply-to "problem".

While it may be instructive to bang your head at such points, to get something done, it may be easier to "got with the flow" and do things as they are expected to be done.

I'm feeling a little bit uncomfortable when doing things that I don't understand. And the information security is such a specific topic... You can think you are safe and work a long time without any issues. But if some day the bad-case scenario happens and you discovers, that your rules have not prevented it just because you didn't understand how they work, it will be really disappointing. I would better invest some time now in the learning.