[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [openbsd-france-misc] "rdr pass on" et "rdr on"
On Thu, Nov 11, 2004 at 03:10:39AM +0100, Saad Kadhi wrote:
> On Wed, Nov 10, 2004 at 10:56:34AM +0100, Serge Basterot wrote:
> > Voilà une question que je me pose au sujet des redirections. La
> > directive pass sur une rdr permet d'automatiser le passage des paquets
> > en se passant de règles "pass" supplémentaires, d'après ce que j'ai
> > compris. Je voudrais savoir dans quel cas est-il préférable d'utiliser
> > la directive pass sur une rdr, ou le contraire.
> >
> > La réponse que je me donne (j'essaye de réfléchir un peu tout de même
> > :)) est que ne pas utiiser cette directive dans une rdr permet
> > d'affiner au mieux les pass in / pass out avec les statefull. Au
> > contraire la directive pass dans une rdr serait un forçage un peu
> > brutal et une ouverture trop nette dans le fw.
> >
> > Est-ce que j'analyse bien le problème ou je suis à côté de la plaque ?
> l'utilisation du "pass" dans les règles de nat/rdr ne semble
> effectivement pas bien documenté. IMHO, un "rdr pass" équivaudrait à un
> "rdr" suivi immédiatement d'un "pass (in|out) quick ... keep state", si
> c'est le cas, il n'y a donc pas de possibilité de vérifier les drapeaux
> TCP ou d'utiliser du modulate/synproxy.
>
> je vais voir avec joel, daniel et nick comment on peut expliquer ça
> "facilement" dans le PF Guide. en tout cas, merci pour ta remarque.
Voici la réponse de Daniel Hartmeier (qui sera utilisée pour améliorer
le PF Guide) :
---
If you pass a connection which involves translation (nat, rdr, binat),
pf has to create a state entry so it can reverse the translation on
replies. That's why translations imply 'keep state'. If you have
nat on $ext_if from 10.0.0.0/8 to any -> $ext_if
pass out on $ext_if from $ext_if to any
it doesn't matter that you didn't specify 'keep state' _for packets that
matched the nat rule_, pf will create a state entry anyway.
"nat/rdr/binat pass" means that, after a packet has matched the
translation rule, the filter rules won't be evaluated. The packet is
passed and creates state. The connection is filtered statefully, much
like if you'd used "nat/rdr/binat" without pass instead, and had used a
separate "pass keep state" rule matching the packet after translation.
It's a shortcut, so you don't have to add pass rules for each
translation rule.
Of course, if you want to enable specific options (like synproxy,
modulate state, keep state (max 256, tcp.established 20) etc.), you'll
still have to use the dedicated pass rule instead of adding pass to the
translation rule, as these options don't fit into translation rules.
It it's not more or less secure, just a convenience feature.
On the other hand, if you compare the example I gave above to
nat pass on $ext_if from 10.0.0.0/8 to any -> $ext_if
this latter construct will apply _only_ to packets translated by the nat
rule, while the pass rule in the first example could (unexpectedly)
match other connections as well. And you couldn't express the same thing
with a separate pass rule, since filtering happens after translation, so
you can't distinguish translated from untranslated packets in filter
rules. Except by tagging on the internal interface, before translation.
---
--
cheers
- saad.