7.501 Strange Packet Filter behaviour

I would say because your first rule is a FORWARD rule, and the dedicated rule is a OUTPUT rule (just my first idea)

You can login over SSH and get an "iptables -L -n" to verify that

Hey Whity, thanks for your answer.

Is there a difference between forward and output rules? I thought that a firewall applies its ruleset for every packet - regardless of its source.

Normally there is an input, forward and output chain (not rule as i wrote in the last post). There are some more, but this are the importest ones.

Depending on the chain the rule is in it affects different packages:

• Input affects packages coming from the outside to the box itself.
  
• Outgoing affects packages from the box itself to the outside
  
• And forward affects packages coming in on one interface and leaves the box over another one (a router)
  

So, i would say that the ASG chooses itself to which chain it adds the rule. If it is a rule which affects f.ex. networks in your case it adds it to the forward chain. If it is a rule where source or destination is an interface of the ASG it puts it to the output or input chain.

For example, I was tired of my PF logs getting filled up with access attempts on all my public IPs from the Chinese military hackers on a zzz.yyy.***.0/24 subnet, so I decided to drop them silently.

I created a rule 'Chinese Hackers -> Any -> [68.69.70.0/28] : Drop', but the packets kept showing up in my log!

Alan Toews explained to me the same thing Whity did to you.  I therefore created "External Address Group" containing 'External (Address)', 'Outlook Web Access (Address)' and so on.  The following rule works:

'Chinese Hackers -> Any -> External Address Group : Drop

Does that resolve your issue?

Cheers - Bob

Ok, confirmed.

But i do not accept this. When i add a rule that allows "192.168.0.0/24" i mean "192.168.0.0/24" and not "192.168.0.0/24 except the firewall-interface 192.168.0.1"

Is this behaviour really intended?

As Alan Toews said:

"It may seem odd that your pf rule didn't match, and instead, hit the default drop rule. The explanation is relatively simple. Packets being sent TO the Astaro are matched against several iptables INPUT chains. 

"Packets being sent THROUGH the Astaro, are matched against several iptables FORWARD chains. All rules created in the packet filter are created in the USR_FORWARD chain, so only applied to packets being forwarded through the Astaro."

Since the blocked packets had the Astaro as the target, they were in the INPUT chain, to which your PF rule does not apply.

Cheers - Bob

Suppentrulli, I understand how you're confused; it is a little wierd.  I just keep reminding myself that the "wierd" behavior is due to how iptables is used; Bob explained it pretty well.  I've had a few customers ask the same thing.

Thanks, Bruce, but that was Alan's explanation.  I'm still struggling with the concept of "chains" in this.  I know now that it works like this, but I can't say that I've really understood why.

Cheers - Bob

by the way: why is it not possible to reach servers on a remote side of my ipsec-tunnels from my ASG?

here is my (new) configuration

ASG1 (local site):
eth0: 172.16.0.1 (172.16.0.0/24)
eth1: 172.16.1.1 (172.16.1.0/24)
eth2: 172.16.2.1 (172.16.2.0/24)
eth3: internet via PPPoE

ASG2 (remote site):
eth0: 172.17.0.1 (172.17.0.0/24)
eth1: 172.17.1.1 (172.17.1.0/24)
eth2: 172.17.2.1 (172.17.2.0/24)
eth3: internet via PPPoE

Both ASGs are connected via IPsec-tunnel for each of the local networks.
All local networks reach all remote networks, everything works as expected. 

BUT:
When i try to reach a remote network from ASG itself, the destination is not reachable due to routing-errors:

ASG2:/home/login # traceroute 172.16.1.2

traceroute to 172.16.1.2 (172.16.1.2), 30 hops max, 40 byte packets

 1  ******.local (172.16.2.1)  59.734 ms   60.880 ms   58.959 ms

 2  * * *

 3  * * *

 4  * * *

 5  * * *

 6  * * *

 7  * * *

172.17.2.2>tracert 172.16.1.2



Routenverfolgung zu 172.16.1.2 über maximal 30 Abschnitte:



  1    

IDEAS?

I was about to move your post to create a new thread in the VPN forum, then I thought about it a bit and suspect that it may indeed belong here.  Have you allowed ping and traceroute to transit the firewall ('ICMP' tab in 'Network Security >> Packet Filter'?

Cheers - Bob