Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 30 replies
  • Subscribers 2 subscribers
  • Views 49518 views
  • Users 0 members are here
Options
Suggested
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

FW dropping ACK, RST/ACK & FIN/ACK packets though packets are from valid sessions

Jim Tagert
Does the ASG function in this manner?

When the firewall receives a TCP RST for an existing session it immediately clears the session from the session table. This means there is no longer a valid session for the TCP RST/ACK to pass through. Hence, the firewall will treat the TCP RST/ACK as a non-SYN first packet and drop it.



Thanks,

Jim


This thread was automatically locked due to age.
Parents
  • 0
    They are processed in order of placement. Rule #1 is processed first, then rule #2, and so on until a match is made. Once a match is found, all further processing ceases. This is the standard with most firewalls. There is currently a bug in 8.100 where there is no longer a way to view the rules in processing (number) order, but from what I've seen, this is purely cosmetic and due to be fixed soon. 
     
    If your talking about the hidden rules that don't display in WebAdmin, I believe that those are processed after any visible ones, like the default inbound drop rule (everything not specifically allowed from WAN ---> LAN is dropped).  Maybe someone from Astaro can let us know for certain.
     
    One of the top feature requests is to allow the hidden rules to be displayed in WebAdmin.  http://feature.astaro.com/forums/17359-astaro-security-gateway-feature-requests/suggestions/181341-webadmin-display-of-auto-packet-filter-rules?ref=title .  I don't have a clue why Astaro doesn't do this.  It may make things a little more confusing to a network "newbie", but can make troubleshooting so much easier.
  • 0 in reply to Scott_Klassen
    Thanks Scott,

    I was well aware of the order of rules and how to manipulate both trafic and logs with it..

    So its your second answer I was looking for.. my main issue is that I ticked the "automatic pf rule" when i made the DNAT for a webserver.
    That would normally have the result of a new PF rule being added and visible auto created for the lazy admin. In my case there simply is no PF that allows HTTP traffic to pass down to the web server.
    However the rule must exist since the web works perfectly from the Internet, and with the full nat loop back locally.

    As stated "Naturally these rules should be BELOW the ALLOW rules for your http servers."

    Great but there is no allow rule, since I apparently can't see the auto created one. See attached screen capture for the DNAT and FULL NAT. There are no visible rules in PF matching that - only the ones I manually created and those are for like LAN -> ANY and some IMAP and SMTP.
Reply
  • 0 in reply to Scott_Klassen
    Thanks Scott,

    I was well aware of the order of rules and how to manipulate both trafic and logs with it..

    So its your second answer I was looking for.. my main issue is that I ticked the "automatic pf rule" when i made the DNAT for a webserver.
    That would normally have the result of a new PF rule being added and visible auto created for the lazy admin. In my case there simply is no PF that allows HTTP traffic to pass down to the web server.
    However the rule must exist since the web works perfectly from the Internet, and with the full nat loop back locally.

    As stated "Naturally these rules should be BELOW the ALLOW rules for your http servers."

    Great but there is no allow rule, since I apparently can't see the auto created one. See attached screen capture for the DNAT and FULL NAT. There are no visible rules in PF matching that - only the ones I manually created and those are for like LAN -> ANY and some IMAP and SMTP.
Children
No Data