Date: Wed, 07 May 2008 19:43:02 -0400 From: Jon Radel <jon@radel.com> To: Jille <jille@quis.cx>, Ansar Mohammed <ansarm@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: UDP weirdness Message-ID: <48223E86.5010603@radel.com> In-Reply-To: <482215F4.1080806@quis.cx> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> <482215F4.1080806@quis.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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
[-- Attachment #2 --]
0 *H
01 0 + 0 *H
100\mtv0
*H
0b1 0 UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0
080324165921Z
090324165921Z0^10 URadel10U*
Jon Thomas10UJon Thomas Radel1 0 *H
jon@radel.com0"0
*H
0
t,P p#
٬q_2=L-^m >z3ʟV![([ AoE}ϛ3/6?cWx(/)'$6sTl<*i'=uox Mbt
rdtnxud1R6T>zU0FZ,vN9NP{>qE`^P; *Wg/jN*OVՠQMB(=:
*0(0U 0
jon@radel.com0 U 0 0
*H
h!oܨ[А!fN#[Z
b$3?x&$~Ħ9}`MX[It}/bXZajgxɥ' 2NrtWAr sFި'^@mDVw\)00\mtv0
*H
0b1 0 UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0
080324165921Z
090324165921Z0^10 URadel10U*
Jon Thomas10UJon Thomas Radel1 0 *H
jon@radel.com0"0
*H
0
t,P p#
٬q_2=L-^m >z3ʟV![([ AoE}ϛ3/6?cWx(/)'$6sTl<*i'=uox Mbt
rdtnxud1R6T>zU0FZ,vN9NP{>qE`^P; *Wg/jN*OVՠQMB(=:
*0(0U 0
jon@radel.com0 U 0 0
*H
h!oܨ[А!fN#[Z
b$3?x&$~Ħ9}`MX[It}/bXZajgxɥ' 2NrtWAr sFި'^@mDVw\)0?0
0
*H
01 0 UZA10U Western Cape10U Cape Town10U
Thawte Consulting1(0&U Certification Services Division1$0"UThawte Personal Freemail CA1+0) *H
personal-freemail@thawte.com0
030717000000Z
130716235959Z0b1 0 UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA00
*H
0 Ħ<UsUNʙZ hup [v :aQP
0cZ,p+Z?qV˯< 6$*+w=+>@dקe*TH<a@ dr` 00U 0 0CU <0:08642http://crl.thawte.com/ThawtePersonalFreemailCA.crl0 U 0)U "0 0 10UPrivateLabel2-1380
*H
HP .
fgCL!6 -6/ P p<ab:~ t%Pb'qW%ݩ9 Oe_N4[5MwV!x!5$ F]_eO1d0`0v0b1 0 UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAmtv0 + 0 *H
1 *H
0 *H
1
080507234302Z0# *H
1 t}2h6.g0R *H
1E0C0
*H
0*H
0
*H
@0+0
*H
(0 +71x0v0b1 0 UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAmtv0 *H
1xv0b1 0 UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAmtv0
*H
" g6]n㧂r'hWmaN0vv |.8k9mҐudZBr$tmb7 Roi7ڏepFr$Jes9!:vgT8oć*sL$љbj
gŜ%冥zcPz0@ds$1يr xE5cQdWz8ZSpHQU)}>iaP|Y$B
us^}C?"ڌ
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48223E86.5010603>