SEO

say you have an openbsd firewall... that has a wan connection directly
connected to the internet, which gets it's IP address through DHCP (cable
modem scenario).

say you want to put filter rules on that changing interface. does this pose
a problem because of the changing IP address... or is OpenBSD smart enough
to know that the address changes if you apply the rule to the interface and
not an ip address?

i know in reading the PF FAQ it mentions the following about NAT:

----------
"When specifying an interface name for the translation address as above, the
IP address is determined at pf.conf load time, not on the fly. If you are
using DHCP to configure your external interface, this can be a problem. If
your assigned IP address changes then NAT will continue translating outgoing
packets using the old IP address. This will cause outgoing connections to
stop functioning. To get around this, you can tell PF to automatically
update the translation address by putting parentheses around the interface
name:
nat on tl0 from dc0/24 to any -> (tl0)
There is one major limitation to doing this: Only the first IP alias on an
interface is evaluated when the interface name is placed in parentheses."

----------

i don't understand that last line, but i do understand where you have
dynamically assigned addresses, you should put the interface in ()'s.

there's no mention about anything, as far as i've come across, that mentions
anything about what to do about rules when you dealing with an interface
that has a changing IP address. i'd assume you'd simply specify the
interface alone, and OpenBSD would figure out what IP address to apply the
rules to... or something like this.

if i'm wrong can you please let me know where i mixed up my assumption, and
if i'm right, can you give a supporting statement, because it will help to
educate some others who say that it's impossible for a device to figure out
what ip address to assign a rule to on it's own.

thanks.

-Sameer

On Mon, 22 Dec 2003 12:13:58 GMT, "Sameer" <ssnewsgroups@hotmail.com>
wrote:

>say you have an openbsd firewall... that has a wan connection directly
>connected to the internet, which gets it's IP address through DHCP (cable
>modem scenario).
>
>say you want to put filter rules on that changing interface. does this pose
>a problem because of the changing IP address... or is OpenBSD smart enough
>to know that the address changes if you apply the rule to the interface and
>not an ip address?
>
>i know in reading the PF FAQ it mentions the following about NAT:
>
>----------
>"When specifying an interface name for the translation address as above, the
>IP address is determined at pf.conf load time, not on the fly. If you are
>using DHCP to configure your external interface, this can be a problem. If
>your assigned IP address changes then NAT will continue translating outgoing
>packets using the old IP address. This will cause outgoing connections to
>stop functioning. To get around this, you can tell PF to automatically
>update the translation address by putting parentheses around the interface
>name:
> nat on tl0 from dc0/24 to any -> (tl0)
>There is one major limitation to doing this: Only the first IP alias on an
>interface is evaluated when the interface name is placed in parentheses."
>
>----------
>
>i don't understand that last line, but i do understand where you have
>dynamically assigned addresses, you should put the interface in ()'s.
>
>there's no mention about anything, as far as i've come across, that mentions
>anything about what to do about rules when you dealing with an interface
>that has a changing IP address. i'd assume you'd simply specify the
>interface alone, and OpenBSD would figure out what IP address to apply the
>rules to... or something like this.
>
>if i'm wrong can you please let me know where i mixed up my assumption, and
>if i'm right, can you give a supporting statement, because it will help to
>educate some others who say that it's impossible for a device to figure out
>what ip address to assign a rule to on it's own.

Since packets are processed by NAT before rule evaluation you never
have to worry about a changing address in the actual (filter) rules.

And here is the supporting statement from the pf.conf man page:

"
TRANSLATION
Translation rules modify either the source or destination address
of the packets associated with a stateful connection. A stateful
connection is automatically created to track packets matching such a
rule as long as they are not blocked by the filtering section of
pf.conf. The translation engine modifies the specified address and/or
port in the packet, recalculates IP, TCP and UDP checksums as
necessary, and passes it to the packet filter for evaluation.
Translation occurs before filtering.
"

"Sameer" <ssnewsgroups@hotmail.com> wrote in message
news:aeBFb.4234$Vv2.1362467@news1.news.adelphia.ne t...
> say you have an openbsd firewall... that has a wan connection directly
> connected to the internet, which gets it's IP address through DHCP (cable
> modem scenario).
>
> say you want to put filter rules on that changing interface. does this
pose
> a problem because of the changing IP address... or is OpenBSD smart enough
> to know that the address changes if you apply the rule to the interface
and
> not an ip address?
>
> i know in reading the PF FAQ it mentions the following about NAT:
>
> ----------
> "When specifying an interface name for the translation address as above,
the
> IP address is determined at pf.conf load time, not on the fly. If you are
> using DHCP to configure your external interface, this can be a problem. If
> your assigned IP address changes then NAT will continue translating
outgoing
> packets using the old IP address. This will cause outgoing connections to
> stop functioning. To get around this, you can tell PF to automatically
> update the translation address by putting parentheses around the interface
> name:
> nat on tl0 from dc0/24 to any -> (tl0)
> There is one major limitation to doing this: Only the first IP alias on an
> interface is evaluated when the interface name is placed in parentheses."
>
> ----------
>
> i don't understand that last line, but i do understand where you have
> dynamically assigned addresses, you should put the interface in ()'s.
>
> there's no mention about anything, as far as i've come across, that
mentions
> anything about what to do about rules when you dealing with an interface
> that has a changing IP address. i'd assume you'd simply specify the
> interface alone, and OpenBSD would figure out what IP address to apply the
> rules to... or something like this.
>
> if i'm wrong can you please let me know where i mixed up my assumption,
and
> if i'm right, can you give a supporting statement, because it will help to
> educate some others who say that it's impossible for a device to figure
out
> what ip address to assign a rule to on it's own.
>
> thanks.
>
> -Sameer

You can do something like this:

# Macros:
ext="tun0"

# Rules:
block all
pass in log quick on $ext inet proto tcp from any to ($ext) port 22 flags
S/SA keep state
pass out all keep state

I know, I know, It's a crude example, but in the event your IP changed on
tun0 (or whatever your interface name might be) then it'll always work with
the dynamic IP address.

On Mon, 22 Dec 2003 15:07:58 -0500, "Test" <me@here.com> wrote:


>
>I know, I know, It's a crude example, but in the event your IP changed on
>tun0 (or whatever your interface name might be) then it'll always work with
>the dynamic IP address.

I've moved ISPs and re addressed the untrusted interface all without
needing to reload the policy. I was rather impressed.



greg

--
Once you try my burger baby,you'll grow a new thyroid gland.
I said just eat my burger, baby,make you smart as Charlie Chan.
You say the hot sauce can't be beat. Sit back and open wide.

how would i answer in response to this remark?

---------
We have to be debating different applications because it is
impossible for an ACL to determine if a source IP address has
changed. At least it is impossible for it to determine this BY
ITSELF. Now, dynamic VPNs is a different application. There, if the
source IP changes, then the SA tunnels must be reinitiated by the
client.
------