It happened again...
2009/3/9 J.C. Roberts <list-...@designtools.org>:
> As for whether or not the assigned IP address you get from your ISP via
> DHCP will become a problem really depends on the netmask and default
> route they give you along with the IP.
>
> If your internal network is 192.168.151.*
> And your ISP gives you 192.168.1.* with a netmask of 255.255.0.0
> then you're officially hosed. The provided netmask means your internal
> network is *within* the range of your external network. bad juju!
>
> That netmask would give you the range 192.168.0.0 - 192.168.255.255 on
> your external interface, and hence, overlapping your internal network.
The netmask is 192.168.1.255 so I should be okay there.
> When using Point to Point Protocol (PPP, PPPoE, and similar), it can get
> far more confusing. Take a look at the following:
No PPP or PPPoE, just simple DHCP.
> None the less, the safest thing you can do is use an obtuse private
> network range for your internal LAN.
I guess it would be a good idea to do that then anyway.
> If I was able to 'keep state' every time I 'pass out' drinking would be
> far more enjoyable. Though I can't do it, pf can, and does it by
> default, but it seems I've digressed. Additionally, you need to be very
> careful when using the "quick" keyword since it intentionally short
> circuits your rule evaluation.
>
> B B B B ext_if = "sk0"
> B B B B int_if = "sk1"
> B B B B set skip on lo
> B B B B scrub in
>
> B B B B nat on $ext_if from !($ext_if) -) ($ext_if:0)
>
> B B B B block in log
> B B B B pass out
> B B B B antispoof quick for { lo $int_if }
> B B B B pass quick on $int_if no state
>
>
> On the last line, you do not necessarily need the 'no state' (but it
> eliminates collecting pointless state entries) and you don't need the
> 'quick' since it's the last rule evaluated (but you might follow this
> with other rules).
I'll see if simplifying the rules helps.
> If during a DHCP (re)assignment the DHCP server sends an ICMP Echo
> Request packet (Type 8), and you're blocking the packet but due
> to your block-policy replying with ICMP Destination Unreachable packet
> (Type 3), strange things might occur.
The problem is definitely with DHCP assigning a new IP address. I
checked and (as everybody here was already expecting) pf is still
using the same rules as before.
So apparently using ($ext_if) isn't working properly. I need to reload
pf.conf for the firewall to work again. I'll see if changing the
return policy makes any difference.
Cheers,
Hilco
