Re: pf pauses in sending traffic
On 13 Sep 2004 12:10:48 -0700, [EMAIL PROTECTED] (matthew zeier) wrote: On the pf box itself, running a ping to a directly connected box, I get: 64 bytes from 116.23.162.6: icmp_seq=1134 ttl=128 time=0.427 ms ping: sendto: No route to host ping: wrote 116.23.162.6 64 chars, ret=-1 ping: sendto: No route to host ping: wrote 116.23.162.6 64 chars, ret=-1 ping: sendto: No route to host ping: wrote 116.23.162.6 64 chars, ret=-1 64 bytes from 116.23.162.6: icmp_seq=1138 ttl=128 time=0.493 ms What would cause that? The physical interface never drops. Are you running a default block policy of block log all ? Sounds like your policy may be a tad asymmetric in the way its setting states on various interfaces. greg -- Felicitations, malefactors! I am endeavoring to misappropriate the formulary for the preparation of affordable comestibles. Who will join me?!
Re: pf pauses in sending traffic
On Mon, Sep 13, 2004 at 12:50:16PM -0700, matthew zeier wrote: If it were a rule, I'd expect it to block all the time, not sporadically, no? Run tcpdump -s 1600 -nvvvetttX -i pflog0 and provide the verbatim output of a couple of such blocked ICMP packets. Also, enable pfctl -x loud and see if /var/log/messages logs anything pf related during the pinging. Daniel
Re: pf pauses in sending traffic
Hi Matthew, I've the same problem here with 3.4 (and had the same problem with 3.3). The 'hole' in communication is always just 20 seconds. In the beginning I thought about a Spanning Tree issue, but after careful inspection, everything seems fine. Also tried to swap switches, network cards (all fxp tough) etc. The same things also happen with pf disabled, and happen only on the trunk interface, the management interface is fine. Tried a netstat -w 1, and in those 20 seconds, traffic arrives at fxp0, but not a single packet exits. The server just quits routing on the trunk interface, and all vlans. At the time that happend, I simply didn't have the time to troubleshoot it (since I began noticing it when VoIP customers came in... and that REALLY disrupts VoIP!), and now have an old Cisco that routes that. But the question still remains... The only other thing running at the time was Zebra with full bgp tables (and it was before the explosion of the tables that rendered the old kernels unusable with full bgp peer). I can try to reproduce the problems if it helps the community! Cheers! ]\/[arco - Original Message - From: matthew zeier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 13, 2004 7:47 PM Subject: pf pauses in sending traffic I'm seeing sporadic packet loss through an openbsd 3.5 box running pf. While running 'tcpdump -n -e -ttt -i pflog0' on the pf box and a ping on another box, I see: 64 bytes from 116.23.162.6: icmp_seq=103. time=0. ms 64 bytes from 116.23.162.6: icmp_seq=104. time=0. ms 64 bytes from 116.23.162.6: icmp_seq=105. time=0. ms 64 bytes from 116.23.162.6: icmp_seq=124. time=1. ms 64 bytes from 116.23.162.6: icmp_seq=125. time=1. ms 64 bytes from 116.23.162.6: icmp_seq=126. time=3. ms And the tcpdump window stops logging, although the box itself is still responsive. This is manifesting itself in slow http connections and RDP session resets. Site performance is now considered slow. Both fxp0 (outside) and fxp1 (inside interface) are trunks with various vlan interfaces and carp interfaces with it's standby unit. I'm stumped where else to look. Any clues? -- matthew zeier - But if you only have love for your own race, Then you only leave space to discriminate, And to discriminate only generates hate. - BEP
Re: pf pauses in sending traffic
On Tue, Sep 14, 2004 at 12:51:26PM +0200, Marco Matarazzo wrote: Hi Matthew, I've the same problem here with 3.4 (and had the same problem with 3.3). The 'hole' in communication is always just 20 seconds. In the beginning I thought about a Spanning Tree issue, but after careful inspection, everything seems fine. Also tried to swap switches, network cards (all fxp tough) etc. The same things also happen with pf disabled, and happen only on the trunk interface, the management interface is fine. Tried a netstat -w 1, and in those 20 seconds, traffic arrives at fxp0, but not a single packet exits. The server just quits routing on the trunk interface, and all vlans. At the time that happend, I simply didn't have the time to troubleshoot it (since I began noticing it when VoIP customers came in... and that REALLY disrupts VoIP!), and now have an old Cisco that routes that. But the question still remains... The only other thing running at the time was Zebra with full bgp tables (and it was before the explosion of the tables that rendered the old kernels unusable with full bgp peer). I can try to reproduce the problems if it helps the community! I think you got hit by a fxp bug that was fixed after 3.5. The problem was that somehow the fxp card did no longer generate an interrupt and so the watchdog timer reseted the card after 20 seconds. This only happened on havily loaded links (many interrupts). -- :wq Claudio
Re: pf pauses in sending traffic
Is there a patch for 3.5? I don't see anything listed on the errata page. I think you got hit by a fxp bug that was fixed after 3.5. The problem was that somehow the fxp card did no longer generate an interrupt and so the watchdog timer reseted the card after 20 seconds. This only happened on havily loaded links (many interrupts). -- matthew zeier - But if you only have love for your own race, Then you only leave space to discriminate, And to discriminate only generates hate. - BEP
Re: pf pauses in sending traffic
I may - I've also got fxp, however, my customer doesn't push more then 2Mbps. After moving that user away from this box, everything is fine. The box is pushing only a few hundred Kbps now. It's not bandwidth, but packets per seconds that make the difference (more packets - more interrupts), so it could be that just 2Mbps give the problem... Cheers, ]\/[arco
Re: pf pauses in sending traffic
I may - I've also got fxp, however, my customer doesn't push more then 2Mbps. After moving that user away from this box, everything is fine. The box is pushing only a few hundred Kbps now. On Tue, 14 Sep 2004 14:44:35 +0200, Marco Matarazzo [EMAIL PROTECTED] wrote: I've the same problem here with 3.4 (and had the same problem with 3.3). The 'hole' in communication is always just 20 seconds. I think you got hit by a fxp bug that was fixed after 3.5. The problem was that somehow the fxp card did no longer generate an interrupt and so the watchdog timer reseted the card after 20 seconds. This only happened on havily loaded links (many interrupts). At the time of testing it was pushing 20Mbit... I'll try with 3.6beta if it fixes the problem... I'd really prefer to have an OpenBSD router there! ;) Perhaps Matthew has the same problem! Cheers, ]\/[arco -- -- matthew zeier - But if you only have love for your own race, Then you only leave space to discriminate, And to discriminate only generates hate. - BEP
IPv6 Rules
My OpenBSD kernel has only IPv4 in it. I was wondering, do I need to have IPv6 rules since the kernel doesn't support it or can I keep it as is with IPv4 rules? Also does this apply for ICMPv6? Let me know. Thanks.
RE: blocking gnutella
Little bit more info would help people on the list, maybe post your
pf.conf with ip's xxx.xxx out and a simple diagram of your network
setup. Look like your not blocking on the internal interface from what
your describing possibly.
Amir Mesry
[EMAIL PROTECTED]
Cadillac Jack, Inc.
http://www.cadillacjack.com/
Network Systems Administrator
2420 Meadowbrook Parkway
Duluth, GA 30096
770-865-0034
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Bryan Irvine
Sent: Tuesday, September 14, 2004 3:34 PM
To: [EMAIL PROTECTED]
Subject: blocking gnutella
I can't seem to get gnutella to break.
gnutella = { 6346 6348 8436 }
block out quick proto { udp tcp } from any to any port $gnutella
block in quick proto { udp tcp } from any to any port $gnutella
pftop still shows connection on 6346 though, ideas?
--Bryan
Re: blocking gnutella
On Tue, 2004-09-14 at 15:33, Bryan Irvine wrote:
I can't seem to get gnutella to break.
gnutella = { 6346 6348 8436 }
block out quick proto { udp tcp } from any to any port $gnutella
block in quick proto { udp tcp } from any to any port $gnutella
pftop still shows connection on 6346 though, ideas?
--Bryan
pftop still shows new connections being established or still shows old
connections that were established before you implemented the new rules
and didn't flush the state table or kill the individual states?
-j
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
It has been said that Public Relations is the art of winning friends and
getting people under the influence. -- Jeremy Tunstall
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: perceived strange behavior
I got a tcp dump of this occurring if anyone is interested in looking, I have not really had a chance to look at it yet It's in binary format. There was a flurry of ICMP going from this machine at the time also, I forgot to ask him to turn off everything else. http://www.qosbox.com/tests/aim.dump.tgz nb On Sep 10, 2004, at 6:57 AM, Jason Opperisano wrote: On Fri, 2004-09-10 at 03:11, Ryan McBride wrote: On Thu, Sep 09, 2004 at 08:40:23PM -0400, Jason Opperisano wrote: all use TCP Port 5190. all three connections appear to stay open once connected. the simple solution appears to be to set a NAT rule that only uses 1 translation IP for connections on TCP Port 5190. Or use the 'sticky-address' keyword. yes--precisely. the OP on other firewall mailing list was essentially asking for pf's sticky-address feature. forgot where i was posting there for second... -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= ~ I hate it when my foot falls asleep during the day cause that means it's going to be up all night. -- Steven Wright =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= ~
Re: blocking gnutella
Gnutella is a slippery protocol, being peer to peer its highly
network configurable. Its not always a simple matter of blocking
a particular port. If your handy with network programming (with
perl or java or any network-useful language) you might want to
consider blocking unwanted protocols by setting up a daemon or
similar utility to sniff for protocol fingerprints and reject
them at the application layer. All protocols announce what they
are in the first few packets (at least I'm pretty sure they all
do...)
Of course this method will become useless when p2p developers
start using ssl and other secure transport methods, which they
are bound to do soon.
Amir S Mesry writes:
Little bit more info would help people on the list, maybe post your
pf.conf with ip's xxx.xxx out and a simple diagram of your network
setup. Look like your not blocking on the internal interface from what
your describing possibly.
Amir Mesry
[EMAIL PROTECTED]
Cadillac Jack, Inc.
http://www.cadillacjack.com/
Network Systems Administrator
2420 Meadowbrook Parkway
Duluth, GA 30096
770-865-0034
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Bryan Irvine
Sent: Tuesday, September 14, 2004 3:34 PM
To: [EMAIL PROTECTED]
Subject: blocking gnutella
I can't seem to get gnutella to break.
gnutella = { 6346 6348 8436 }
block out quick proto { udp tcp } from any to any port $gnutella
block in quick proto { udp tcp } from any to any port $gnutella
pftop still shows connection on 6346 though, ideas?
--Bryan
Re: blocking gnutella
On Sep 14, 2004, at 3:33 PM, Bryan Irvine wrote:
I can't seem to get gnutella to break.
gnutella = { 6346 6348 8436 }
block out quick proto { udp tcp } from any to any port $gnutella
block in quick proto { udp tcp } from any to any port $gnutella
pftop still shows connection on 6346 though, ideas?
I think this thread is still germane:
http://marc.theaimsgroup.com/?l=openbsd-pfm=104592911709710w=2
--
Jason Dixon, RHCE
DixonGroup Consulting
http://www.dixongroup.net
