This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

7.501 Strange Packet Filter behaviour

Hi Astaro,

i have a strange packet filter behaviour, maybe you can help me.

I'm trying to use my directly connected LDAP-server (ssl, port 636) for user-authentication in Astaro, but astaro always filters the packets.

ASG: 192.168.1.1
LDAP: 192:168.1.2

Rule #1:
Source:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24

Destination:
192.168.1.2/32
etc.

Service:
ICMP, 443, 53(tcp/udp), 636 etc.

Logfile:
19:52:20 Default DROP TCP 192.168.1.1 : 42467 → 192.168.1.2 : 636 [SYN] len=60 ttl=64 tos=0x00 srcmac=00:30:18:aa:aa:aa dstmac=00:00:00:00:00:00

19:52:22 Default DROP TCP 192.168.1.1 : 42467 → 192.168.1.2 : 636 [SYN] len=60 ttl=64 tos=0x00 srcmac=00:30:18:aa:aa:aa dstmac=00:00:00:00:00:00  

 
With a dedicated rule with the firewall-interface 192.168.1.1 as source it is working, but not with 192.168.1.0/24. WHY?


This thread was automatically locked due to age.
Parents
  • 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?
Reply Children
No Data