Re: PF Seems To Reload Its Default Rules Unexpectedly
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
Re: PF Seems To Reload Its Default Rules Unexpectedly
2009/3/9 J.C. Roberts list-...@designtools.org: On Sun, 8 Mar 2009 16:01:57 -0700 Hilco Wijbenga hilco.wijbe...@gmail.com wrote: I have pf running on my firewall box and I'm experiencing some strange behaviour. After several hours (this may even be 24 hours) of functioning normally, pf seems to reload its default rules which means that from that point on all traffic is blocked. A simple pfctl -f /etc/pf.conf fixes the problem but it is very annoying. ummm... no. Think about it for a moment. The default rules *are* stored in /etc/pf.conf --the very same file you are manually reloading, so it's obviously not magically reloading the default rules as you claim. Ah, different semantics. :-) By default rules I mean whatever pf does *without* an /etc/pf.conf. Probably something like block all. What kind of connection are you running? Is your public IP address static or dynamic? More importantly, are you running some sort of tunneling/authentication such as PPPoE or simlar? I use DHCP so my IP can change. It's not particularly public though. My ISP gives me an IP in 192.168.1.*. :-( (A smart move on their part, I guess [no more running out of IPv4 addresses for them] but not very useful to me.) 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? Cheers, Hilco
Re: PF Seems To Reload Its Default Rules Unexpectedly
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:
On Sun, 8 Mar 2009 16:01:57 -0700 Hilco Wijbenga
hilco.wijbe...@gmail.com wrote:
I have pf running on my firewall box and I'm experiencing some
strange behaviour. After several hours (this may even be 24 hours)
of functioning normally, pf seems to reload its default rules
which means that from that point on all traffic is blocked. A
simple pfctl -f /etc/pf.conf fixes the problem but it is very
annoying.
ummm... no. Think about it for a moment. The default rules *are*
stored in /etc/pf.conf --the very same file you are manually
reloading, so it's obviously not magically reloading the default
rules as you claim.
Ah, different semantics. :-) By default rules I mean whatever pf
does *without* an /etc/pf.conf. Probably something like block all.
:-)
What kind of connection are you running?
Is your public IP address static or dynamic?
More importantly, are you running some sort of
tunneling/authentication such as PPPoE or simlar?
I use DHCP so my IP can change. It's not particularly public though.
My ISP gives me an IP in 192.168.1.*. :-( (A smart move on their part,
I guess [no more running out of IPv4 addresses for them] but not very
useful to me.)
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. ;-)
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.
Cheers,
Hilco
PF Seems To Reload Its Default Rules Unexpectedly
Hi all, I have pf running on my firewall box and I'm experiencing some strange behaviour. After several hours (this may even be 24 hours) of functioning normally, pf seems to reload its default rules which means that from that point on all traffic is blocked. A simple pfctl -f /etc/pf.conf fixes the problem but it is very annoying. I don't see anything relevant in /var/log/pflog or /var/log/messages but I'm not sure what I am looking for so I may have missed something. Do you have any idea why this is happening? Do you have any tips for debugging this? I'm running a stock OpenBSD 4.4. Cheers, Hilco
acpitz0: THRM: failed to read _TMP
Hi all, I'm seeing the following messages logged to the console: acpitz0: THRM: failed to read _TMP acpitz0: THRM: failed to read temp (both lines are repeated many times). It looks like OpenBSD (4.4) is unable to read the CPU temperature which would explain why my previously whisper quiet box now resembles a starting F16. I have the box under the desk running 24/7 so I really want it to be quiet. Google didn't find anything other than the fact that OpenBSD has support for reading temperature (and other) sensors. Any ideas? Cheers, Hilco
Re: PF Seems To Reload Its Default Rules Unexpectedly
2009/3/8 Jason Dixon ja...@dixongroup.net: On Sun, Mar 08, 2009 at 04:01:57PM -0700, Hilco Wijbenga wrote: Hi all, I have pf running on my firewall box and I'm experiencing some strange behaviour. After several hours (this may even be 24 hours) of functioning normally, pf seems to reload its default rules which means that from that point on all traffic is blocked. A simple pfctl -f /etc/pf.conf fixes the problem but it is very annoying. There's nothing in OpenBSD or pf that reloads any configurations automagically. :-) Yeah, I didn't think there would be. I don't see anything relevant in /var/log/pflog or /var/log/messages but I'm not sure what I am looking for so I may have missed something. Do you have any idea why this is happening? Do you have any tips for debugging this? I'm running a stock OpenBSD 4.4. You could start by showing us pfctl -sr before and after this supposedly takes place. B And uptime to prove it hasn't been rebooted. B And grep pf /etc/rc.conf.local so we can see how you're starting it. In other words, *useful information*. I'll get the pfctl -sr when it happens again. In the meantime, I'd like to point out that rebooting loads the rules correctly. So both pfctl -f /etc/pf.conf and reboot solve the problem. # grep pf /etc/rc.conf.local pf=YES # Packet filter / NAT # uptime 5:39PM up 9 days, 19:44, 1 user, load averages: 0.10, 0.09, 0.08 # pfctl -sr scrub in all fragment reassemble block return log all pass out quick inet from 192.168.151.1 to 192.168.151.0/24 flags S/SA keep state pass out quick inet from 192.168.1.64 to any flags S/SA keep state pass out quick on sk0 inet6 from fe80::21c:f0ff:fe9f:e13 to any flags S/SA keep state pass in quick on sk1 inet from 192.168.151.0/24 to any flags S/SA keep state As you can see I haven't rebooted this box for 9 days. I think I've reloaded pf.conf 4 or 5 times. I'm quite curious what pfctl -sr says the next time it happens. There is one other strange thing that's being logged every now and then: acpitz0: THRM: failed to read _TMP acpitz0: THRM: failed to read temp (See my other email specifically about this.) It doesn't seem related but who knows so I thought I'd mention it. Cheers, Hilco
Re: NAT, Firewall pf
2009/2/24 Jorge Enrique Valbuena Vargas jvalbue...@gmail.com: 1. You need to enable routing on your BSD box edit /etc/sysctl.conf and change the 0 (zero) with 1 net.inet.ip.forwarding=1 B B B B # 1=Permit forwarding (routing) of IPv4 packets My problem isn't that basic. :-) Forwarding is permitted. That was the very first thing I set up.
Re: NAT, Firewall pf
2009/2/23 Jason Dixon ja...@dixongroup.net:
On Mon, Feb 23, 2009 at 05:58:20PM -0800, Hilco Wijbenga wrote:
Hi all,
I've been trying to get a simple firewall system up-and-running in
OpenBSD. I have The Book of PF and Secure Architectures
with OpenBSD so I thought it would be very simple. Well, we're two
weeks later now and still no firewall. :-) The pf rules I found in
those books don't seem to work as I expected them to work.
Before I list my current pf.conf, let me give a few more details. My
firewall will be running a few services for my network (DHCP, NTP, and
DNS). I need to use NAT to get my own network Internet access. DHCP
works. I seem to have managed to get DNS (maradns on lo0 and sk1) and
ICMP working.
Sounds like a very basic home setup. B You want your firewall to handle
DHCP, NTP and act as a DNS resolver for your local network. B Easy
enough.
Yes, exactly what I thought. :-)
/etc/pf.conf
01 ext_if = sk0
02 int_if = sk1
03 localnet = $int_if:network
04 internet = $ext_if:network
05 udp_services = { domain, ntp }
06 icmp_types = { echoreq, unreach }
07
08 nat log on $ext_if from $localnet to any - ($ext_if)
09
10 block log all
11
12 pass quick inet proto { tcp, udp } from $internet to any port
$udp_services
13 pass quick inet proto { tcp, udp } from $localnet to any port
$udp_services
14 pass quick inet proto { tcp, udp } from $lo0:network to any port
$udp_services
15
16 pass inet proto icmp all icmp-type $icmp_types
17 pass from { lo0, $localnet } to any keep state
a. Why do I need 12? I had expected 13 (which I don't seem to need).
Wouldn't 12 be for incoming requests from the Internet?
b. Given that ping works from my network (so that presumably routing
is okay), why doesn't anything else work? HTTP seems blocked by the
firewall.
c. How can I get pflog to flush immediately? I noticed I have to wait
a minute or so before logged lines show up.
d. Any other pointers?
Let's start off with your questions and then a working example below.
a. B If you're only intending to allow outbound traffic from your local
network, you don't. B That rule would be to allow inbound requests from
the internet to your firewall (and optionally, other internal services
if you had rdr or binat rules). B By default, pf uses keep state on all
pass rules, which means that it will track your connections outbound and
allow the appropriate replies from external services.
That's what I thought, hence the question because line 12 was required
for it to work.
b. B Because line 16 is allowing icmp outbound *and* inbound. B You have
no directional (or interface) qualifiers.
Shouldn't 17 take care of all that for (e.g.) HTTP requests? It's from
the local net to anywhere and it keeps state (not relevant for HTTP, I
guess, but still).
c. B I would need more details here to give you a qualified answer. B As
in, examples. B You're only logging blocked traffic.
Yes, I thought that would make it easier. It isn't always clear to me
what a logged line is for: was it logged because it was blocked or
because it was allowed?
d. B Read the PF FAQ.
Right. :-)
Ok, here is a working example based on your description. B Noticed the
beauty in the simplicity. B :)
What!?! You didn't like my near random mish-mash of rules? ;-)
##
00 ext_if = sk0
01 int_if = sk1
02
03 set skip on lo
04
05 scrub in
06
07 nat on $ext_if from $int_if:network to any - ($ext_if:0)
08
09 block in log all
10 pass in on $int_if inet keep state
##
I'll try that tonight.
The first two lines are obvious. B Why did I remove localnet and
internet? B The first is truly unnecessary in a ruleset this small; B it
simply adds abstraction where none is needed. B The internet is already
provided via the any and all keywords.
That's one thing that isn't obvious to me. To the firewall sk0 and sk1
are just two interfaces, why/how would any and all refer to the
internet? Or do you simply mean they refer/include all interfaces so
also the internet?
Line 3 allows us to skip state on loopback, nothing exciting there.
Yeah, I read about that and figured it could wait till later. Just
icing on the cake, right?
Line 5 provides scrubbing, also known as packet defragmentation. B This
helps pf by reassembling packet fragments before applying rules. B In
short, it's a safety mechanism.
Same thing, I figured that could wait.
Line 7 allows outbound NAT to the internet.
Okay, so the only difference with my attempt at it is the :0 you
added at the end. Does it mean anything special or was it simply
implied in my version?
Line 9 provides a basic block all for inbound requests. B This affects
both inbound from the internet, as well as inbound (from the firewall's
perspective) from the local network. B Which requires...
Was this the main problem then? I was blocking everything
Re: NAT, Firewall pf
2009/2/23 Jason Dixon ja...@dixongroup.net: ## 00 ext_if = sk0 01 int_if = sk1 02 03 set skip on lo 04 05 scrub in 06 07 nat on $ext_if from $int_if:network to any - ($ext_if:0) 08 09 block in log all 10 pass in on $int_if inet keep state ## I tried this and I'm afraid it doesn't work. I can't ping anymore, neither from my own box nor from the firewall. This setup is basically what I also found in the books I have, I guess. :-( DHCP works (i.e. my box gets an IP from the DHCP daemon on the firewall) and I can see maradns receiving requests from localhost (the firewall) and from the int_if (my box) when I try to ping something. It's all blocked by the firewall, though. I don't think it should matter but the only special thing about my setup is that my external IP is on 192.168.1.0/24. Yes, that's my *external* network. No more IPv4 address shortages for my ISP. :-) Please also see my next reply.
NAT, Firewall pf
Hi all,
I've been trying to get a simple firewall system up-and-running in
OpenBSD. I have The Book of PF and Secure Architectures
with OpenBSD so I thought it would be very simple. Well, we're two
weeks later now and still no firewall. :-) The pf rules I found in
those books don't seem to work as I expected them to work.
Before I list my current pf.conf, let me give a few more details. My
firewall will be running a few services for my network (DHCP, NTP, and
DNS). I need to use NAT to get my own network Internet access. DHCP
works. I seem to have managed to get DNS (maradns on lo0 and sk1) and
ICMP working.
/etc/pf.conf
01 ext_if = sk0
02 int_if = sk1
03 localnet = $int_if:network
04 internet = $ext_if:network
05 udp_services = { domain, ntp }
06 icmp_types = { echoreq, unreach }
07
08 nat log on $ext_if from $localnet to any - ($ext_if)
09
10 block log all
11
12 pass quick inet proto { tcp, udp } from $internet to any port $udp_services
13 pass quick inet proto { tcp, udp } from $localnet to any port $udp_services
14 pass quick inet proto { tcp, udp } from $lo0:network to any port
$udp_services
15
16 pass inet proto icmp all icmp-type $icmp_types
17 pass from { lo0, $localnet } to any keep state
a. Why do I need 12? I had expected 13 (which I don't seem to need).
Wouldn't 12 be for incoming requests from the Internet?
b. Given that ping works from my network (so that presumably routing
is okay), why doesn't anything else work? HTTP seems blocked by the
firewall.
c. How can I get pflog to flush immediately? I noticed I have to wait
a minute or so before logged lines show up.
d. Any other pointers?
Cheers,
Hilco
