Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 2 subscribers
  • Views 535 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.
Parents
  • 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.
Reply
  • 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.
Children
No Data