Re: NAT & BINAT !! Help!!!
From: Daniel Hartmeier (daniel_at_benzedrine.cx)
Date: 10/29/03
- Previous message: Roy: "Re: Redefinition Error with NTP-4.2.0 on OpenBSD 3.3"
- In reply to: vit: "NAT & BINAT !! Help!!!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 29 Oct 2003 15:23:41 GMT
On Wed, 29 Oct 2003 12:33:26 +0100, vit wrote:
> nat on dc2 from { 172.16.1.0/24,! <freeout>, ! 172.16.1.3, ! 172.16.1.28 }
> to any -> XXX.YYY.CC.FFF
This is the problem, it doesn't do what you intend.
I assume you want the rule to apply to all sources within 172.16.1.0/24,
except for sources .3, .28 and those in table freeout.
But your rule simply expands to
nat on dc2 from 172.16.1.0/24 to any -> XXX.YYY.CC.FFF
nat on dc2 from ! <freeout> to any -> XXX.YYY.CC.FFF
nat on dc2 from ! 172.16.1.3 to any -> XXX.YYY.CC.FFF
nat on dc2 from ! 172.16.1.28 to any -> XXX.YYY.CC.FFF
which you'll see when you run pfctl -sn.
This block matches any source address, as any source address is either
different from 172.16.1.3 or different from 172.16.1.28. So, using
negated entries in {} lists is pointless, due to how expansion works.
To solve this, there's the 'no nat' option:
no nat on dc2 from { <freeout>, 172.16.1.3, 172.16.1.28 } to any
nat on dc2 from 172.16.1.0/24 to any -> XXX.YYY.CC.FFF
The first matching translation rule is used, so this construct will
cause sources <freeout>, .3 and .28 to not get translated, but any
other source within 172.16.1.0/24 to get translated.
Note that for outgoing connections, binat has precedence over nat (and
no nat), which might create another conflict, possibly.
Daniel
- Previous message: Roy: "Re: Redefinition Error with NTP-4.2.0 on OpenBSD 3.3"
- In reply to: vit: "NAT & BINAT !! Help!!!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
