Re: Problems w/ IRC DCCs and p2p on my firewall

[jared r r spiegel <jrrs@ice-nine.org>]

On Sun, May 02, 2004 at 11:49:35AM +0200, Thorin Oakenshield wrote:
> I'm running an OpenBSD 3.4 firewall: everything works ok except some
> services i.e. sending DCC file send requests (if someone tries to send
> me a file via DCC it works without problems, I just can't send) and p2p
> inbound connections. Here are my rules:

  if you can receive ok, but cannot send; this reminds me of socom:II for
  the ps2 and how when i messed with it a bit, found that people could not
  hear me through the microphone, but i could hear them ok.

  in that case, the solution was to add 'static-port' to the nat declaration.

  perhaps:

nat on $ext_if from $debian to any -> ($ext_if) static-port

  right above your normal nat line.
 
  if that works, i'd try to narrow it down by including port specifications too.

  since you're logging your blocks ( yay ), you could also watch pflog0 with 
  tcpdump to see if there is blocking of packets happening when you're trying
  to dcc_send

> let's talk about DCC first: as you can see I specified to use the
> 7777/TCP port but even if I specify this port (I tried this in two
> different IRC client programs, xchat which has a menu voice about file
> transfers to do this while in epic4 I can specify on the command line
> the -p <port> parameter) and it seems to always use a random source port
> so there's no way to have it working correctly.

  that makes me think of static-port too

> I tried to sniff using
> tcpdump on the pflog0 interface on the destination host and the 7777
> port both but nothing seems to pass through it.

  try just listening to pflog0, don't worry about specifying a port.  if it's
  blocked, you'll see it anyway.

> The same seems to happen with p2p programs too since I'm always seeing
> this kind od stuff in my pflog:
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=> CLIP HERE < =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> May 02 09:36:33.227643 rule 0/0(match): block in on fxp1: 213.8.29.12.4662 > 10.0.0.2.25490: R 0:0(0) ack 4195832184 win 0 May 02 09:37:15.786105 rule 0/0(match): block in on fxp1:
> 213.8.29.12.4662 > 10.0.0.2.25492: R 0:0(0) ack 2858685711 win 0 May 02 09:37:17.105543 rule 0/0(match): block in on fxp1: 213.8.29.12.4662 > 10.0.0.2.25492: R 0:0(0) ack 1 win 0
> May 02 09:45:50.628670 rule 7/0(match): block in on fxp1: 82.49.16.21.4661 > 10.0.0.2.25577: S 3776926678:3776926678(0) ack 3714573958 win 65535 <mss 1400,nop,nop,sackOK>

> pass in quick on $ext_if inet proto tcp from any to $Debian port 7777 flags S/SA keep state
> pass out quick on $ext_if inet proto tcp from $Debian to any port 7777 flags S/SA keep state
> pass in quick on $ext_if inet proto tcp from any to $Debian port 4662 flags S/SA keep state
> pass in quick on $ext_if inet proto udp from any to $Debian port 4672 keep state
> pass out quick on $ext_if inet proto tcp from any to any flags S/SA modulate state

  the first tw, the 'R's that are blocked, probably because you're saying pass only S/SA and
  the connection was closed at that time.  or it could be the next suggestion:

  you pass from any to you port 4662, but it doesn't seem you pass from any port 4662 to you.

  maybe you should add pass rules for those, or to make things easy, just do something like:

rdr pass on $ext_if from any to $debian port { 7777 4662 4672 } -> ($ext_if) static-port
rdr pass on $ext_if from any port { 7777 4662 4672 } to $debian -> ($ext_if) static-port

  ( ps, looks like there's a 4661 in there too. )

  i haven't had the coffee yet, so might not make much sense.  oops

  jared

-- 

[ openbsd 3.5 GENERIC ( mar 26 ) // i386 ]