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

Any/Any/Any Rule Drops Packets

My ASG is dropping packets even though I have an any / any / any rule defined and on.  This rule is first in the list and all other rules are disabled.

This is an example from the log file:

2012:04:02-13:59:45 asg ulogd[5607]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="78:ca:39:fb:1f:34" dstmac="d0:67:e5:ee:6e:af" srcip="17.172.116.48" dstip="192.168.2.5" proto="6" length="40" tos="0x00" prec="0x00" ttl="242" srcport="443" dstport="52238" tcpflags="ACK RST" 

It's apparently being dropped by fwrule 60001.  How do I cross reference that to something in the ASG that I can edit and change so that it doesn't drop these packets?

I also see fwrule 60003 dropping packets, too, in the log file.

Thanks!
Jason


This thread was automatically locked due to age.
Parents
  • Those are good questions with the goal of understanding, so I'll try to supply some tools for that...

    name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="d0:67:e5:ee:6e:ae" srcip="85.115.22.9" dstip="10.0.4.23" proto="6" length="481" tos="0x00" prec="0x00" ttl="64" srcport="80" dstport="53641" tcpflags="ACK PSH"

    Consulting Packetfilter Logfiles, you see that 60003 means that this packet was dropped out of the OUTPUT chain.  I only know enough about the internals of Astaro (iptables) to say that that means that Astaro already has processed this packet and the connection tracker has determined that it's supposed to go to 10.0.4.23.  I don't know why it waited to drop the packet, but ACK PSH means it's one that Barry would tell you not to worry about.

    2012:04:02-22:09:22 asg ulogd[5607]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:19:e3:e7:ec:13" dstmac="d0:67:e5:ee:6e:ae" srcip="10.0.4.50" dstip="10.0.4.5" proto="17" length="157" tos="0x00" prec="0x00" ttl="255" srcport="61486" dstport="1900"

    Consulting List of IP protocol numbers, you see that proto="17" means that this is a UDP packet.  The speedguide.net Ports Database identifies UDP 1900 as UPnP discovery.  The Astaro drops this because it doesn't speak consumereze. [;)]

    an issue with Apple iChat's ability to sign in and/or receive messages. This issue doesn't happen all of the time, but when it does it's repeatable. I can solve the problem by logging into iChat using a network that's not behind the ASG and when I switch back to the ASG internal network everything still works fine.

    That sounds more like something with Web Security.  Do you see anything in the Web Filtering log when that happens?  It also always pays to check the Firewall and Intrusion Prevention logs.

    Cheers - Bob
  • Thanks, Bob, for the helpful insight and tools to help me better understand these situations better.  I will look into these in more detail and respond back with questions from here.

    Happy Easter.
Reply
  • Thanks, Bob, for the helpful insight and tools to help me better understand these situations better.  I will look into these in more detail and respond back with questions from here.

    Happy Easter.
Children
No Data