Re: mismatch on route through packet/byte counts
Am 14.12.2006 um 17:10 schrieb Daniel Hartmeier: , I'm still getting lots of warning like this one: - Dec 14 11:16:47 pf: loose state match: TCP \ aaa.bbb.ccc.ddd:25 aaa.bbb.ccc.ddd:25 66.35.250.225:53336 \ [lo=3396551343 high=3396616878 win=5840 modulator=874376751] \ [lo=3752913744 high=3752919543 win=65535 modulator=3189448930] \ 9:9 R seq=3396551343 ack=3752913744 len=0 ackskew=0 pkts=8:10 For RSTs, the sequence number in the packet must match a value precisely, I suspect this is not the case here. Unfortunately, what is logged is not the actual sequence number of the packet. Try to capture one such connection with tcpdump -nvvvS, from initial SYN to the blocked RST, only consisting of packets that match this connection. I suspect the sender of the RST is incrementing the sequence number in the RST inappropriately, or such. Hard to tell without a trace. A fancy thing happened here: After rebooting both pfsynced firewalls simultaneously, all loose state match warnings have gone away. No single such warning in 24 hours. Should I use -F all while reloading the config and see such state warnings? Last thing, I changed before reboot was changing tcp.closed from 1 back to its default. Axel - Axel Rau, ☀Frankfurt , Germany +49 69 9514 18 0
Re: mismatch on route through packet/byte counts
I'm still hunting loose state matches. After converting all none-protocol-specific keep state to either flags S/SAFR keep state or flags S/SAFR synproxy state , I'm still getting lots of warning like this one: - Dec 14 11:16:47 pf: loose state match: TCP \ aaa.bbb.ccc.ddd:25 aaa.bbb.ccc.ddd:25 66.35.250.225:53336 \ [lo=3396551343 high=3396616878 win=5840 modulator=874376751] \ [lo=3752913744 high=3752919543 win=65535 modulator=3189448930] \ 9:9 R seq=3396551343 ack=3752913744 len=0 ackskew=0 pkts=8:10 Dec 14 11:16:47 pf: loose state match: TCP \ aaa.bbb.ccc.ddd:25 aaa.bbb.ccc.ddd:25 66.35.250.225:53336 \ [lo=3396551343 high=3396616878 win=5840 modulator=874376751] \ [lo=3752913744 high=3752919543 win=65535 modulator=3189448930] \ 9:9 R seq=3396551343 ack=3752913744 len=0 ackskew=0 pkts=8:10 Dec 14 11:16:47 pf: loose state match: TCP \ 66.35.250.225:53336 66.35.250.225:53336 aaa.bbb.ccc.ddd:25 \ [lo=4270928094 high=4270993629 win=5840 modulator=0] \ [lo=3752913744 high=3752919543 win=65535 modulator=0] \ 9:9 R seq=4270928094 ack=3752913744 len=0 ackskew=0 pkts=10:11 Dec 14 11:16:47 pf: loose state match: TCP \ 66.35.250.225:53336 66.35.250.225:53336 aaa.bbb.ccc.ddd:25 \ [lo=4270928094 high=4270993629 win=5840 modulator=0] \ [lo=3752913744 high=3752919543 win=65535 modulator=0] \ 9:9 R seq=4270928094 ack=3752913744 len=0 ackskew=0 pkts=10:11 Dec 14 11:16:47 pf: loose state match: TCP \ aaa.bbb.ccc.ddd:25 aaa.bbb.ccc.ddd:25 66.35.250.225:53336 \ [lo=3396551343 high=3396616878 win=5840 modulator=874376751] \ [lo=3752913744 high=3752919543 win=65535 modulator=3189448930] \ 10:10 R seq=3396551343 ack=3752913744 len=0 ackskew=0 pkts=9:10 Dec 14 11:16:47 pf: loose state match: TCP \ aaa.bbb.ccc.ddd:25 aaa.bbb.ccc.ddd:25 66.35.250.225:53336 \ [lo=3396551343 high=3396616878 win=5840 modulator=874376751] \ [lo=3752913744 high=3752919543 win=65535 modulator=3189448930] \ 10:10 R seq=3396551343 ack=3752913744 len=0 ackskew=0 pkts=9:10 Dec 14 11:16:47 pf: loose state match: TCP \ 66.35.250.225:53336 66.35.250.225:53336 aaa.bbb.ccc.ddd:25 \ [lo=4270928094 high=4270993629 win=5840 modulator=0] \ [lo=3752913744 high=3752919543 win=65535 modulator=0] \ 10:10 R seq=4270928094 ack=3752913744 len=0 ackskew=0 pkts=11:11 Dec 14 11:16:47 pf: loose state match: TCP \ 66.35.250.225:53336 66.35.250.225:53336 aaa.bbb.ccc.ddd:25 \ [lo=4270928094 high=4270993629 win=5840 modulator=0] \ [lo=3752913744 high=3752919543 win=65535 modulator=0] \ 10:10 R seq=4270928094 ack=3752913744 len=0 ackskew=0 pkts=11:11 - Notice the difference in modulator. My policy based filtering setup uses synproxy on internet interface only, not on dmz or intranet interfaces. Might this be an issue? Any tips would be very helpful. Axel - Axel Rau, ☀Frankfurt , Germany +49 69 9514 18 0
Re: mismatch on route through packet/byte counts
On Mon, Dec 04, 2006 at 02:02:38PM +0100, Axel Rau wrote: If flags S/SA would just be ignored by none-tcp packets, I would be happy. Be happy, it is. ;) But the man page says: This rule only applies to TCP packets that have the flags a set out of set b. This means to me: all none-tcp packets are ignored by this rule. This probably should read instead This rule only applies to TCP packets which have the flags a set out o set b. Daniel
Re: mismatch on route through packet/byte counts
Am 03.12.2006 um 21:45 schrieb Camiel Dobbelaar: Try using flags S/SA keep state on all your tcp rules. On exit, there is no discrimination on protocol in my rule set. Changing that would cluttering things. On Sat, 2 Dec 2006, Axel Rau wrote: and exit like pass out quick on $dmz_if tagged GREEN_DMZ keep state If flags S/SA would just be ignored by none-tcp packets, I would be happy. But the man page says: This rule only applies to TCP packets that have the flags a set out of set b. This means to me: all none-tcp packets are ignored by this rule. So let's make a test... and exit like pass out quick on $dmz_if tagged GREEN_DMZ $tcp_options .. Oh wonder, exit rules seem to work as expected. (-:) This means: ***None-tcp packets being passed and kept state!*** Could someone insert this sentence in pf.conf.man? That the good news. Bad news is: I still see: loose state match: TCP 84.107.12.60:57198 84.107.12.60:57198 \ 217.72.192.149:25 [lo=59866068 high=59877651 \ win=65535 modulator=0 wscale=0] [lo=3235423848 high=3235489347 \ win=11584 modulator=0 wscale=0] 9:4 R seq=59866068 ack=3235423848 \ len=0 ackskew=0 pkts=10:9 One more hint? Thanks a lot, Axel - Axel Rau, ☀Frankfurt , Germany +49 69 9514 18 0
