Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 2 subscribers
  • Views 534 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

Package Filter Rules - Do we need a second rule?

rahman
Hi,

I thought astaro allows the returning/answer packets by default? Like if I create a PF rule like this: 

10.1.1.100 -> HTTP(80) -> Any -> Allow


Then when that pc connects to 10.1.1.100:48975 -> 86.86.86.86:80 then returning packages also allowed without needing a PF rule: 86.86.86.86:80 -> 10.1.1.100:48975 -> allowed.

This is of course working as expected. But what I want to ask is if this is limited to http or any specific/known protocols?

Can anybody explain why the returning package is dropping every time? 

08:58:35 Packet filter rule #8	TCP	10.1.1.2:38907→10.1.10.20:65000 [ACK FIN] len=40 ttl=62 tos=0x00 srcmac=	dstmac=



08:58:35 Packet filter rule #39 TCP 10.1.10.20:65000→10.1.1.2:38907 [RST] len=40 ttl=62 tos=0x00 srcmac= dstmac=


I lack deep knowledge about TCP packages. So is it because 10.1.10.20 sending a RST package after ACK FIN?

Thanks.


This thread was automatically locked due to age.
  • 0
    Hi, there's been several discussions on these forums about what this could be:
    old http tcp sessions getting expired on the firewall and therefore getting logged as they are not part of a recognized session.

    If it is something else, and it is causing problems, please say so.

    Otherwise, ignore it, or there are steps you can take to reduce the logging.

    Barry
  • 0
    Thanks, I am just eager to learn [:)] The logs are from our new PTZ cam. 65000 port is its rotation control port. It works though sluggish. So I wondered if its something to do with dropping packages. I guess its not.