Re: DCE-RPC

[Greg Hennessy]

Ansar Mohammed wrote:

Hello All,

Does pf have any higher level application inspection capability such as RPC
filtering based on UUID?
  

No, that is layer 7 style 'deep packet inspection' (tm) voodoo.


Greg

___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

UDP weirdness

[Ansar Mohammed]

I have a very simple configuration yet I am bemused as to what I am doing
wrong.


Windows 2003<- FreeBSD-PF ->Windows 2003
192.168.3.2 192.168.3.1 192.168.2.2 192.168.2.130
Here are my rules


ext_if="le0"
int_if="le1"
int_net="192.168.3.0/24"
ext_net="192.168.2.0/24"
int_addr="192.168.3.1"
ext_addr="192.168.2.2"
scrub on $ext_if all reassemble tcp
scrub on $int_if all reassemble tcp
block in log all
pass in  proto icmp from any to any
pass in proto udp from any to any port 53
pass in on $ext_if inet proto tcp from any to any port 3389


DNS traffic is allowed though but the return packet gets blocked. Can anyone
explain why?
This is true on ALL UDP traffic TCP traffic works well

Pflog message:

065276 rule 0/0(match): block in on le1: 192.168.3.2.53 >
192.168.2.130.3837: [|domain]




___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: UDP weirdness

[Kevin K]

Try pass out proto udp from any to any port 53

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-freebsd-
> [EMAIL PROTECTED] On Behalf Of Ansar Mohammed
> Sent: Wednesday, May 07, 2008 1:34 PM
> To: freebsd-pf@freebsd.org
> Subject: UDP weirdness
> 
> I have a very simple configuration yet I am bemused as to what I am
> doing
> wrong.
> 
> 
> Windows 2003  <- FreeBSD-PF ->Windows 2003
> 192.168.3.2   192.168.3.1 192.168.2.2 192.168.2.130
> Here are my rules
> 
> 
> ext_if="le0"
> int_if="le1"
> int_net="192.168.3.0/24"
> ext_net="192.168.2.0/24"
> int_addr="192.168.3.1"
> ext_addr="192.168.2.2"
> scrub on $ext_if all reassemble tcp
> scrub on $int_if all reassemble tcp
> block in log all
> pass in  proto icmp from any to any
> pass in proto udp from any to any port 53
> pass in on $ext_if inet proto tcp from any to any port 3389
> 
> 
> DNS traffic is allowed though but the return packet gets blocked. Can
> anyone
> explain why?
> This is true on ALL UDP traffic TCP traffic works well
> 
> Pflog message:
> 
> 065276 rule 0/0(match): block in on le1: 192.168.3.2.53 >
> 192.168.2.130.3837: [|domain]
> 
> 
> 
> 
> ___
> freebsd-pf@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: UDP weirdness

[Ansar Mohammed]

Ok, so adding the line as you suggested worked. 
Thanks Kevin.

But why do I need to have both entries in for 

pass in proto udp from any to any port 53
pass out proto udp from any to any port 53

what makes UDP so special?


> -Original Message-
> From: Kevin K [mailto:[EMAIL PROTECTED]
> Sent: May 7, 2008 1:54 PM
> To: 'Ansar Mohammed'; freebsd-pf@freebsd.org
> Subject: RE: UDP weirdness
> 
> Try pass out proto udp from any to any port 53
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:owner-freebsd-
> > [EMAIL PROTECTED] On Behalf Of Ansar Mohammed
> > Sent: Wednesday, May 07, 2008 1:34 PM
> > To: freebsd-pf@freebsd.org
> > Subject: UDP weirdness
> >
> > I have a very simple configuration yet I am bemused as to what I am
> > doing
> > wrong.
> >
> >
> > Windows 2003<- FreeBSD-PF ->Windows 2003
> > 192.168.3.2 192.168.3.1 192.168.2.2 192.168.2.130
> > Here are my rules
> >
> >
> > ext_if="le0"
> > int_if="le1"
> > int_net="192.168.3.0/24"
> > ext_net="192.168.2.0/24"
> > int_addr="192.168.3.1"
> > ext_addr="192.168.2.2"
> > scrub on $ext_if all reassemble tcp
> > scrub on $int_if all reassemble tcp
> > block in log all
> > pass in  proto icmp from any to any
> > pass in proto udp from any to any port 53
> > pass in on $ext_if inet proto tcp from any to any port 3389
> >
> >
> > DNS traffic is allowed though but the return packet gets blocked. Can
> > anyone
> > explain why?
> > This is true on ALL UDP traffic TCP traffic works well
> >
> > Pflog message:
> >
> > 065276 rule 0/0(match): block in on le1: 192.168.3.2.53 >
> > 192.168.2.130.3837: [|domain]
> >
> >
> >
> >
> > ___
> > freebsd-pf@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"

___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: UDP weirdness

[Jille]

Ansar Mohammed schreef:
Ok, so adding the line as you suggested worked. 
Thanks Kevin.


But why do I need to have both entries in for 


pass in proto udp from any to any port 53
pass out proto udp from any to any port 53

what makes UDP so special?

UDP is stateless,
With TCP you've got an connection (identified by: local host:port and 
remote host:port)
With UDP, well, you just trow the packages over the line, and hope the 
is (still) someone on the other end.


So the is (almost) no way to detect whether packets are responses to 
eachother


-- Jille
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: UDP weirdness

[Ansar Mohammed]

But I thought pf would be tracking state?
Isnt that the whole point of statefull firewalls?



> -Original Message-
> From: Jille [mailto:[EMAIL PROTECTED]
> Sent: May 7, 2008 4:50 PM
> To: Ansar Mohammed
> Cc: 'Kevin K'; freebsd-pf@freebsd.org
> Subject: Re: UDP weirdness
> 
> 
> 
> Ansar Mohammed schreef:
> > Ok, so adding the line as you suggested worked.
> > Thanks Kevin.
> >
> > But why do I need to have both entries in for
> >
> > pass in proto udp from any to any port 53
> > pass out proto udp from any to any port 53
> >
> > what makes UDP so special?
> UDP is stateless,
> With TCP you've got an connection (identified by: local host:port and
> remote host:port)
> With UDP, well, you just trow the packages over the line, and hope the
> is (still) someone on the other end.
> 
> So the is (almost) no way to detect whether packets are responses to
> eachother
> 
> -- Jille

___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: UDP weirdness

[Kevin K]

You cannot track state of stateless protocols such as UDP.



> -Original Message-
> From: Ansar Mohammed [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 07, 2008 4:54 PM
> To: 'Jille'
> Cc: 'Kevin K'; freebsd-pf@freebsd.org
> Subject: RE: UDP weirdness
> 
> But I thought pf would be tracking state?
> Isnt that the whole point of statefull firewalls?
> 
> 
> 
> > -Original Message-
> > From: Jille [mailto:[EMAIL PROTECTED]
> > Sent: May 7, 2008 4:50 PM
> > To: Ansar Mohammed
> > Cc: 'Kevin K'; freebsd-pf@freebsd.org
> > Subject: Re: UDP weirdness
> >
> >
> >
> > Ansar Mohammed schreef:
> > > Ok, so adding the line as you suggested worked.
> > > Thanks Kevin.
> > >
> > > But why do I need to have both entries in for
> > >
> > > pass in proto udp from any to any port 53
> > > pass out proto udp from any to any port 53
> > >
> > > what makes UDP so special?
> > UDP is stateless,
> > With TCP you've got an connection (identified by: local host:port and
> > remote host:port)
> > With UDP, well, you just trow the packages over the line, and hope
> the
> > is (still) someone on the other end.
> >
> > So the is (almost) no way to detect whether packets are responses to
> > eachother
> >
> > -- Jille

___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: UDP weirdness

[Valentin Bud]

from pf faq --- http://www.openbsd.org/faq/pf/filter.html#pass
quote:
" One will sometimes hear it said that, "One can not create state with UDP
as UDP is a stateless protocol!" While it is true that a UDP communication
session does not have any concept of state (an explicit start and stop of
communications), this does not have any impact on PF's ability to create
state for a UDP session. In the case of protocols without "start" and "end"
packets, PF simply keeps track of how long it has been since a matching
packet has gone through. If the timeout is reached, the state is cleared.
The timeout values can be set in the
optionssection of the
pf.conf file."


On Wed, May 7, 2008 at 11:56 PM, Kevin K <[EMAIL PROTECTED]> wrote:

> You cannot track state of stateless protocols such as UDP.
>
>
>
> > -Original Message-
> > From: Ansar Mohammed [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, May 07, 2008 4:54 PM
> > To: 'Jille'
> > Cc: 'Kevin K'; freebsd-pf@freebsd.org
> > Subject: RE: UDP weirdness
> >
> > But I thought pf would be tracking state?
> > Isnt that the whole point of statefull firewalls?
> >
> >
> >
> > > -Original Message-
> > > From: Jille [mailto:[EMAIL PROTECTED]
> > > Sent: May 7, 2008 4:50 PM
> > > To: Ansar Mohammed
> > > Cc: 'Kevin K'; freebsd-pf@freebsd.org
> > > Subject: Re: UDP weirdness
> > >
> > >
> > >
> > > Ansar Mohammed schreef:
> > > > Ok, so adding the line as you suggested worked.
> > > > Thanks Kevin.
> > > >
> > > > But why do I need to have both entries in for
> > > >
> > > > pass in proto udp from any to any port 53
> > > > pass out proto udp from any to any port 53
> > > >
> > > > what makes UDP so special?
> > > UDP is stateless,
> > > With TCP you've got an connection (identified by: local host:port and
> > > remote host:port)
> > > With UDP, well, you just trow the packages over the line, and hope
> > the
> > > is (still) someone on the other end.
> > >
> > > So the is (almost) no way to detect whether packets are responses to
> > > eachother
> > >
> > > -- Jille
>
> ___
> freebsd-pf@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>



-- 
Kind Regards,

Valentin Bud

www.syk.ro
www.spreadbsd.org/aff/86/1
www.spreadbsd.org/aff/86/2

valentin [dot] bud [at] gmail [dot] com
valentin [dot] bud [at] dep [dot] upt [dot] ro
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

proftpd and pf weirdness

[Valentin Bud]

Hello to you all,
 Last week i've begun to have problem with an HUAWEI E220 HSDPA modem
when connecting to proftpd server. First thing i want to mention is that the
thing
that i'll describe here only happens when i connect from that modem.
 First of all the topology of the servers:

ISP[bridged modem]-[FreeBSD mpd4+pf][FreeBSD proftpd]

the pf rules that redirect traffic to proftpd:

rdr pass on $EXT_IF proto tcp from any to $EXT_IF port 21 ->  port
21
rdr pass on $EXT_IF proto tcp from any to $EXT_IF port 59000:59100 ->
 port 59000:59100

DMZ_HOST (192.168.1.2) being the FreeBSD 6.2-RELEASEp6 box that runs -
ProFTPD Version 1.3.1
no firewall running on DMZ_HOST

here is the relevant ouput that the server gives when the ftp session is
closed:

12.34.56.78 (213.233.102.254[213.233.102.254]) - Entering Passive Mode
(192,168,1,2,230,167).
12.34.56.78 (213.233.102.254[213.233.102.254]) - dispatching POST_CMD
command 'PASV' to mod_sql
12.34.56.78 (213.233.102.254[213.233.102.254]) - dispatching LOG_CMD command
'PASV' to mod_sql
12.34.56.78 (213.233.102.254[213.233.102.254]) - dispatching LOG_CMD command
'PASV' to mod_log
12.34.56.78 (213.233.102.254[213.233.102.254]) - FTP session closed.

tcpdump output from the [mpd4+pf] box:

14:04:58.299572 AF IPv4 (2), length 94: 12.34.56.78.21 >
213.233.102.254.40437: P 261:311(50) ack 92 win 65535
0x:  4500 005a be9c 4000 3f06 0f55 597a d74a  [EMAIL PROTECTED]
0x0010:  d5e9 66fe 0015 9df5 2ded 1879 01dc 346b  ..f.-..y..4k
0x0020:  5018  aea7  3232 3720 456e 7465P...227.Ente
0x0030:  7269 6e67 2050 6173 7369 7665 204d 6f64  ring.Passive.Mod
0x0040:  6520 2831 3932 2c31 3638 2c31 2c32 2c32  e.(192,168,1,2,2
0x0050:  3330 2c31 3637 292e 0d0a
30,167)...
14:04:58.348823 AF IPv4 (2), length 94: 213.233.102.254.40437 >
12.34.56.78.21: R 92:142(50) ack 261 win 65535
0x:  4500 005a be9c 4000 2806 2655 d5e9 66fe  [EMAIL 
PROTECTED](.&U..f.
0x0010:  597a d74a 9df5 0015 01dc 346b 2ded 1879  Yz.J..4k-..y
0x0020:  5014  aeab  3232 3720 456e 7465P...227.Ente
0x0030:  7269 6e67 2050 6173 7369 7665 204d 6f64  ring.Passive.Mod
0x0040:  6520 2831 3932 2c31 3638 2c31 2c32 2c32  e.(192,168,1,2,2
0x0050:  3330 2c31 3637 292e 0d0a
30,167)...

The last snippet from tcpdump shows (as far as i know) that the huawei modem
sends an R
and that the server (before) that reset sends the PASV port answer. If i am
not right please correct me.
  The ppp connection made from the modem receives an ip from 172.16/12
private class which gets
nat-ed to the 213.* ip from the logs. If it matters the modem is from
Vodafone.
 I will attach the proftpd config file.

 I think that vodafone does some check on packets and it doesn't like that
the connection to the ftp server
passes through the [mpd4+pf] box. Configuring proftpd on the [mpd4+pf] box
works like a charm. This is a viable
solution but i want to find out what happens. Any hints to dig further are
more than welcomed.
Thank you.

PS: the 12.34.56.78 ip is bogus to protect my server's identity, everything
else is copy paste from
server output.

-- 
Kind Regards,

Valentin Bud

www.syk.ro
www.spreadbsd.org/aff/86/1
www.spreadbsd.org/aff/86/2

valentin [dot] bud [at] gmail [dot] com
valentin [dot] bud [at] dep [dot] upt [dot] ro
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: UDP weirdness

[Jeremy Chadwick]

On Wed, May 07, 2008 at 04:54:22PM -0400, Ansar Mohammed wrote:
> But I thought pf would be tracking state?
> Isnt that the whole point of statefull firewalls?

UDP is stateless, however pf still tracks the "state" in the sense that
it knows when there's an outbound or inbound initial packet for UDP,
thus creates a "state" for it.  It can do the same with ICMP.  I believe
the teardown/state removal is based on a timeout (of when it last sees
packets matching that src/dst IP and port).

Keep in mind that if you're using RELENG_6, you'll need "keep state" on
those pass in/pass out rules you used.  If you're using RELENG_7, "keep
state" is implicit, so you won't need to specify it in your config.

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

iptables rule in pf

[Oleksandr Samoylyk]

Dear Community,

I want to move some of our firewalls from Linux/iptables to FreeBSD/pf.

After reading man pf.conf for a couple of minutes I couldn't find the 
realization of such iptables rule in pf:


iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport 
25 -j DROP
iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT 
--to-destination :25


How it can be rewriting in pf.conf?

Thanks!

--
 Oleksandr Samoylyk
 OVS-RIPE
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

iptables rule in pf

[Oleksandr Samoylyk]

Dear Community,

I want to move some of our firewalls from Linux/iptables to FreeBSD/pf.

After reading man pf.conf for a couple of minutes I couldn't find the
realization of such iptables rule in pf:

iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport
25 -j DROP
iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT
--to-destination :25

How it can be rewriting in pf.conf?

Thanks!

--
 Oleksandr Samoylyk
 OVS-RIPE

___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: UDP weirdness

[Ansar Mohammed]

So I am using FreeBSD 7 and it doesn't work either way with "keep state"
there or not. The only catch here is that everything is running on VMWare,
although that should not matter. I have been using pf for about 2 years now.
I feel this may be a bit of a bug. 

I even set the state-policy to floating (which I believe is default) and
still I need the second rule.





> -Original Message-
> From: Jeremy Chadwick [mailto:[EMAIL PROTECTED]
> Sent: May 7, 2008 5:44 PM
> To: Ansar Mohammed
> Cc: 'Jille'; freebsd-pf@freebsd.org
> Subject: Re: UDP weirdness
> 
> On Wed, May 07, 2008 at 04:54:22PM -0400, Ansar Mohammed wrote:
> > But I thought pf would be tracking state?
> > Isnt that the whole point of statefull firewalls?
> 
> UDP is stateless, however pf still tracks the "state" in the sense that
> it knows when there's an outbound or inbound initial packet for UDP,
> thus creates a "state" for it.  It can do the same with ICMP.  I
> believe
> the teardown/state removal is based on a timeout (of when it last sees
> packets matching that src/dst IP and port).
> 
> Keep in mind that if you're using RELENG_6, you'll need "keep state" on
> those pass in/pass out rules you used.  If you're using RELENG_7, "keep
> state" is implicit, so you won't need to specify it in your config.
> 
> --
> | Jeremy Chadwickjdc at parodius.com |
> | Parodius Networking   http://www.parodius.com/ |
> | UNIX Systems Administrator  Mountain View, CA, USA |
> | Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: UDP weirdness

[Max Laier]

On Wednesday 07 May 2008 19:34:00 Ansar Mohammed wrote:
> I have a very simple configuration yet I am bemused as to what I am
> doing wrong.
>
>
> Windows 2003  <- FreeBSD-PF ->Windows 2003
> 192.168.3.2   192.168.3.1 192.168.2.2 192.168.2.130
> Here are my rules
>
>
> ext_if="le0"
> int_if="le1"
> int_net="192.168.3.0/24"
> ext_net="192.168.2.0/24"
> int_addr="192.168.3.1"
> ext_addr="192.168.2.2"
> scrub on $ext_if all reassemble tcp
> scrub on $int_if all reassemble tcp
> block in log all
> pass in  proto icmp from any to any
> pass in proto udp from any to any port 53
> pass in on $ext_if inet proto tcp from any to any port 3389
>
>
> DNS traffic is allowed though but the return packet gets blocked. Can
> anyone explain why?
> This is true on ALL UDP traffic TCP traffic works well
>
> Pflog message:
>
> 065276 rule 0/0(match): block in on le1: 192.168.3.2.53 >
> 192.168.2.130.3837: [|domain]

Here is what happend:
1) You sent a DNS request from 192.168.2.130:3837 to 192.168.3.2:53 this 
passes on le0 (which I assume is the interface on 192.168.2.0/24) because 
of the "pass in ... to any port 53" (because the packet is indeed 
destined to any port 53).

This creates a state: le0 IN 192.168.2.130:3837->192.168.3.2:53

2) You forward the packet and it leaves le1 in out direction.  This passes 
because you don't block outgoing packets at all.  It doesn't create state 
either.

3) The server replies from 192.168.3.2:53 to 192.168.2.130:3837 this is 
blocked on le1 because there is no rule to allow it and the state created 
above does *NOT* match!

Why doesn't it match the state?

A state "le0 IN 192.168.2.130:3837->192.168.3.2:53" will match:

 IN  192.168.2.130:3837->192.168.3.2:53and
 OUT 192.168.3.2:53->192.168.2.130:3837

but not

 IN  192.168.3.2:53->192.168.2.130:3837

if state-policy is set to floating, the interface doesn't matter, but the 
direction does!

This is a FAQ!

-- 
/"\  Best regards,  | [EMAIL PROTECTED]
\ /  Max Laier  | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | [EMAIL PROTECTED]
/ \  ASCII Ribbon Campaign  | Against HTML Mail and News
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: UDP weirdness

[Jeremy Chadwick]

On Wed, May 07, 2008 at 06:06:38PM -0400, Ansar Mohammed wrote:
> So I am using FreeBSD 7 and it doesn't work either way with "keep state"
> there or not. The only catch here is that everything is running on VMWare,
> although that should not matter. I have been using pf for about 2 years now.
> I feel this may be a bit of a bug. 
> 
> I even set the state-policy to floating (which I believe is default) and
> still I need the second rule.

You don't need "keep state" or "keep state flags S/SA" on any of your
rules because you're using RELENG_7.

Regarding the need for the "pass out" line, Max has explained the
reason/need for it in another Email.  It's not a bug.

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: UDP weirdness

[Jon Radel]

Jille wrote:
> 
> 
> 
> Ansar Mohammed schreef:
>> Ok, so adding the line as you suggested worked. Thanks Kevin.
>>
>> But why do I need to have both entries in for
>> pass in proto udp from any to any port 53
>> pass out proto udp from any to any port 53
>>
>> what makes UDP so special?
> UDP is stateless,
> With TCP you've got an connection (identified by: local host:port and
> remote host:port)
> With UDP, well, you just trow the packages over the line, and hope the
> is (still) someone on the other end.
> 
> So the is (almost) no way to detect whether packets are responses to
> eachother

Other than looking at local host:port and remote host:port and matching
things up  Which PF does just fine ordinarily.  (Only exception I
can think of right now is if you're using a TFTP server which actually
implements the RFC rather than breaking it to make firewalls work)
Current versions also match ICMP up with other traffic with which it is
associated.  But this has already been addressed in another reply.

I have reread this thread and can't find any indication of which version
of PF is running.  This makes it rather hard to comment on whether a
"keep state" would make things better, though I suspect you're using
FreeBSD 7.x.  So what follows are some thoughts which may or may not
apply to your implementation.  (Somebody else has already pointed out
when the default for keep state changed.)

pass in proto udp from any to any port 53
pass out proto udp from any to any port 53

can be combined into

pass proto udp from any to any port 53



If the rule set is complete as presented:

> > ext_if="le0"
> > int_if="le1"
> > int_net="192.168.3.0/24"
> > ext_net="192.168.2.0/24"
> > int_addr="192.168.3.1"
> > ext_addr="192.168.2.2"
> > scrub on $ext_if all reassemble tcp
> > scrub on $int_if all reassemble tcp
> > block in log all
> > pass in  proto icmp from any to any
> > pass in proto udp from any to any port 53
> > pass in on $ext_if inet proto tcp from any to any port 3389

then you're making use of the default action of "pass" on all outbound
traffic.  I wouldn't recommend doing that, particularly on a firewall.
To be specific, my firewall rulesets tend to start with

block log all

If you do that, then you need to do something such as

pass in on $int_if proto udp from any to any port 53 [keep state]
pass out on $ext_if proto udp all [keep state]

if you want machines on the inside to initiate DNS queries, which are
allowed to pass in on the internal interface and then out on the
external interface.

If you want DNS queries to be allowed in both directions (you have an
authoritative DNS server on the inside, or something...) you'd want
something like

pass in proto udp from any to any port 53 [keep state]
pass out proto udp all [keep state]

and that would cover both directions.

In writing this I am struck by an interesting question:  Is there a
possibility that what you're running into is a difference in the default
keep state behavior in the default pass rule between UDP and TCP.  The
documentation I've looked at has been silent on whether the default pass
rule is expected to establish state (for versions of PF recent enough),
and I'm not quite curious enough to build a testbed right now.  If
anyone knows the answer to this one, please do share.  :-)

--Jon Radel


smime.p7s
Description: S/MIME Cryptographic Signature

Re: iptables rule in pf

[CZUCZY Gergely]

On Thu, 08 May 2008 01:04:54 +0300
Oleksandr Samoylyk <[EMAIL PROTECTED]> wrote:

> Dear Community,
> 
> I want to move some of our firewalls from Linux/iptables to FreeBSD/pf.
> 
> After reading man pf.conf for a couple of minutes I couldn't find the
> realization of such iptables rule in pf:
> 
> iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport
> 25 -j DROP
block in on $interface proto tcp from any to ! my.smtp.server port 25

> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT
> --to-destination :25
rdr on $interface proto tcp from any to port 2525 ->
 port 25

> How it can be rewriting in pf.conf?
be sure to read the openbsd faq:
http://www.openbsd.org/faq/pf

pf works quite differently then iptables, it has a different logic. you will
get used to it. just forget these "tables" which you've got used to with
iptables.

-- 
Sincerely,

CZUCZY Gergely
Harmless Digital Bt
mailto: [EMAIL PROTECTED]
Tel: +36-30-9702963


signature.asc
Description: PGP signature