On Mon, 9 Mar 2009 19:06:10 -0700 Hilco Wijbenga
<hilco.wijbe...@gmail.com> wrote:
> 2009/3/9 J.C. Roberts <list-...@designtools.org>:
> > On Mon, 9 Mar 2009 09:07:51 -0700 Hilco Wijbenga
> > <hilco.wijbe...@gmail.com> wrote:
> >
> >> 2009/3/9 J.C. Roberts <list-...@designtools.org>:
> >
> > I doubt your ISP only has 254 customers, so they are most likely
> > using more than just the stated 192.168.1.0 - 192.168.1.255 range.
>
> Let's hope so for them. :-) I always get an IP in that range, though.
> Well, so far anyway.
>
> > If you are doing your own NAT'ing for other machines on your private
> > LAN, the fact your ISP is assigning you an IP address from the
> > private address space could lead to a conflict.
>
> I had been wondering about that. I use 192.168.151.* internally. That
> should be okay then, shouldn't it?
>
> > The "smart" answer for an ISP is moving to IPv6 since it's the only
> > long term solution. Unfortunately, with less than 1% uptake on
> > IPv6, it doesn't get you much usability "right now" and network
> > address translation hacks are still required in some cases.
>
> We're talking about a very big ISP. Smart doesn't come into the
> picture. ;-)
>
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.
Don't worry, it gets worse. :-)
When using Point to Point Protocol (PPP, PPPoE, and similar), it can get
far more confusing. Take a look at the following:
# ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
groups: tun egress
inet 70.212.222.173 --> 66.174.217.64 netmask 0xffffff00
My external interface "tun0" has an IP address of 70.212.222.173 with a
netmask of 255.255.255.0 (0xffffff00), so officially speaking the range
of addresses reachable from my external interface should be:
70.212.222.0 - 70.212.222.255
Did you notice my default route, 66.174.217.64, is actually outside of
the reachable range of my external interface?
Yep, this is one of the strange side effects of using the various Point
to Point Protocols. You mentioned needing DHCP but you did not mention
needing to use PPP/PPPoE/similar, so this little routing mindjob might
not be related to your issue.
None the less, the safest thing you can do is use an obtuse private
network range for your internal LAN.
http://en.wikipedia.org/wiki/Private_network
Typically the "20-bit" block 172.16.0.0 b 172.31.255.255 is mostly
forgotten, and will most likely keep you far away from what your
provider is using.
> >> > In sort my first guess is your IP is changing every 24 hours or
> >> > so due to your service provider using dynamic addressing (and
> >> > trying to prevent you from having a particular IP for too long).
> >> > If I'm right, then your problem is that pf is holding on to the
> >> > old rules for your old IP address even though your IP had
> >> > changed. In other words, you have a configuration error.
> >>
> >> That definitely makes sense. However, I thought that by referring
> >> to an interface instead of an IP I was protected from that? I
> >> mean, it's fairly common to have a dynamic IP, is it not?
> >>
> >
> > It depends on *how* you refer to the interface in your rules. As
> > mentioned in the thread, you may have left off the needed
> > parenthesis around your interface variable. You would be neither
> > the first nor last to make this mistake. If you would post your
> > pf.conf it would be very helpful.
>
> ext_if = "sk0"
> int_if = "sk1"
>
> set skip on lo
> set block-policy return
> scrub in
>
> nat log on $ext_if from $int_if:network to any -> ($ext_if)
>
> block log
> pass out quick from $int_if to $int_if:network
> pass out quick from $ext_if to any
> #pass in quick on $ext_if proto { tcp, udp } from any to ($ext_if)
> port { domain, ntp }
> pass in quick on $int_if from $int_if:network to any
>
> > p.s. I hope you don't mind I cc'd m...@. I figured your off-list
> > reply was due to my mistaken off-list reply.
>
> :-) Yep.
>
The rules you have are a bit odd but you're not doing anything too
fancy, so you can easily simplify things.
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.
ext_if = "sk0"
int_if = "sk1"
set skip on lo
scrub in
nat on $ext_if from !($ext_if) -) ($ext_if:0)
block in log
pass out
antispoof quick for { lo $int_if }
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).
The "set block-policy return" you have is interesting, and to put it as
bluntly as possible, I know little about this policy implementation.
I've always used the default of 'drop' but the 'return' policy could be
useful in some situations, as long as it doesn't cause a conflict.
http://www.openbsd.org/faq/pf/options.html#block-policy
Sets the default behavior for filter rules that specify the
block action:
* drop -packed is silently ignored
* return - a TCP RST packet is returned for blocked TCP packets
and an ICMP Unreachable packet is returned for all others.
Note that individual filter rules can override the default
response. The default is drop.
http://tools.ietf.org/html/rfc1531#section-2.2
As a consistency check, the (server) allocation mechanism may
probe the reused address, e.g., with an ICMP echo request,
before allocating the address, and the client will probe the
newly received address, e.g., with ARP.
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.
--
J.C. Roberts
