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-pf&m=104592911709710&w=2 -- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net
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: 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
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: 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
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
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: 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
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
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'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
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
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 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