Re: PF Seems To Reload Its Default Rules Unexpectedly
* J.C. Roberts list-...@designtools.org [2009-03-21 09:54]: On Fri, 20 Mar 2009 20:16:32 +0100 Henning Brauer lists-open...@bsws.de wrote: * J.C. Roberts list-...@designtools.org [2009-03-10 02:03]: The smart answer for an ISP is moving to IPv6 that is about the least smart thing anybody could do. If everyone continues to avoid IPv6, then it will remain less than useful. I understand IPv6 has less than 1% uptake at the moment, but I don't understand why employing it (in addition to IPv4 NATing hacks) is about the least smart thing an ISP could do? Is it a cost issue? no, a lack of brain issue. v6 is broken by design in a thousand ways and way worse than you can imagine. of course it has been detailed here numerous times. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: PF Seems To Reload Its Default Rules Unexpectedly
On Fri, 20 Mar 2009 20:16:32 +0100 Henning Brauer lists-open...@bsws.de wrote: * J.C. Roberts list-...@designtools.org [2009-03-10 02:03]: The smart answer for an ISP is moving to IPv6 that is about the least smart thing anybody could do. Hi Henning, If everyone continues to avoid IPv6, then it will remain less than useful. I understand IPv6 has less than 1% uptake at the moment, but I don't understand why employing it (in addition to IPv4 NATing hacks) is about the least smart thing an ISP could do? Is it a cost issue? -- J.C. Roberts
Re: PF Seems To Reload Its Default Rules Unexpectedly
If everyone continues to avoid IPv6, then it will remain less than useful. I understand IPv6 has less than 1% uptake at the moment, but I don't understand why employing it (in addition to IPv4 NATing hacks) is about the least smart thing an ISP could do? Is it a cost issue? no, a lack of brain issue. v6 is broken by design in a thousand ways and way worse than you can imagine. of course it has been detailed here numerous times. So what are you going to do when all of IPv4 is exhausted? Do you have all the IPs you need so it won't matter? -- Garry Dolley ARP Networks, Inc. http://www.arpnetworks.com Data center, VPS, and IP transit solutions (818) 206-0181 Member Los Angeles County REACT, Unit 336 WQGK336 Bloghttp://scie.nti.st
Re: PF Seems To Reload Its Default Rules Unexpectedly
* Garry Dolley gdol...@arpnetworks.com [2009-03-21 20:32]:
If everyone continues to avoid IPv6, then it will remain less than
useful. I understand IPv6 has less than 1% uptake at the moment, but I
don't understand why employing it (in addition to IPv4 NATing hacks) is
about the least smart thing an ISP could do?
Is it a cost issue?
no, a lack of brain issue. v6 is broken by design in a thousand ways
and way worse than you can imagine. of course it has been detailed
here numerous times.
So what are you going to do when all of IPv4 is exhausted? Do you
have all the IPs you need so it won't matter?
personally? yes I have enough as far as I can tell today.
globally? I fear we are going to see a v6-- which still has way too
much shit in it. That is the way v6 standards (hey, there is not even a
STD RFC for v6 today!) went in the previous years, cutting some crap.
but way too much is still there, and some issues are
fundamental.
whoever claims v6 would be any good has never written network code
dealing with it.
hey, compare these two which do the same, one for v4 and one for v6:
u_int8_t
mask2prefixlen(in_addr_t ina)
{
if (ina == 0)
return (0);
else
return (33 - ffs(ntohl(ina)));
}
u_int8_t
mask2prefixlen6(struct sockaddr_in6 *sa_in6)
{
u_int8_t l = 0, i, len;
/*
* sin6_len is the size of the sockaddr so substract the offset of
* the possibly truncated sin6_addr struct.
*/
len = sa_in6-sin6_len -
(u_int8_t)(((struct sockaddr_in6 *)NULL)-sin6_addr);
for (i = 0; i len; i++) {
/* this beauty is adopted from sbin/route/show.c ... */
switch (sa_in6-sin6_addr.s6_addr[i]) {
case 0xff:
l += 8;
break;
case 0xfe:
l += 7;
return (l);
case 0xfc:
l += 6;
return (l);
case 0xf8:
l += 5;
return (l);
case 0xf0:
l += 4;
return (l);
case 0xe0:
l += 3;
return (l);
case 0xc0:
l += 2;
return (l);
case 0x80:
l += 1;
return (l);
case 0x00:
return (l);
default:
fatalx(non continguous inet6 netmask);
}
}
return (l);
}
don't get me started on the 160bit addresses (128 + 32 scope ID) which
fuck up all alignment.
just v4 with addresses extended to 64bit (that is still an integer!)
would have been sweet, with minor adjustments/additions like hopcount
instead of ttl. maybe better crypto integration than ipsec today (v6
doesn't solve that problem despite the claims it would either).
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: PF Seems To Reload Its Default Rules Unexpectedly
On Sat, Mar 21, 2009 at 1:03 PM, Henning Brauer lists-open...@bsws.de
wrote:
* Garry Dolley gdol...@arpnetworks.com [2009-03-21 20:32]:
If everyone continues to avoid IPv6, then it will remain less than
useful. I understand IPv6 has less than 1% uptake at the moment, but I
don't understand why employing it (in addition to IPv4 NATing hacks)
is
about the least smart thing an ISP could do?
Is it a cost issue?
no, a lack of brain issue. v6 is broken by design in a thousand ways
and way worse than you can imagine. of course it has been detailed
here numerous times.
So what are you going to do when all of IPv4 is exhausted? Do you
have all the IPs you need so it won't matter?
personally? yes I have enough as far as I can tell today.
globally? I fear we are going to see a v6-- which still has way too
much shit in it. That is the way v6 standards (hey, there is not even a
STD RFC for v6 today!) went in the previous years, cutting some crap.
but way too much is still there, and some issues are
fundamental.
whoever claims v6 would be any good has never written network code
dealing with it.
hey, compare these two which do the same, one for v4 and one for v6:
u_int8_t
mask2prefixlen(in_addr_t ina)
{
if (ina == 0)
return (0);
else
return (33 - ffs(ntohl(ina)));
}
u_int8_t
mask2prefixlen6(struct sockaddr_in6 *sa_in6)
{
u_int8_t l = 0, i, len;
/*
* sin6_len is the size of the sockaddr so substract the offset of
* the possibly truncated sin6_addr struct.
*/
len = sa_in6-sin6_len -
(u_int8_t)(((struct sockaddr_in6 *)NULL)-sin6_addr);
for (i = 0; i len; i++) {
/* this beauty is adopted from sbin/route/show.c ... */
switch (sa_in6-sin6_addr.s6_addr[i]) {
case 0xff:
l += 8;
break;
case 0xfe:
l += 7;
return (l);
case 0xfc:
l += 6;
return (l);
case 0xf8:
l += 5;
return (l);
case 0xf0:
l += 4;
return (l);
case 0xe0:
l += 3;
return (l);
case 0xc0:
l += 2;
return (l);
case 0x80:
l += 1;
return (l);
case 0x00:
return (l);
default:
fatalx(non continguous inet6 netmask);
}
}
return (l);
}
don't get me started on the 160bit addresses (128 + 32 scope ID) which
fuck up all alignment.
just v4 with addresses extended to 64bit (that is still an integer!)
would have been sweet, with minor adjustments/additions like hopcount
instead of ttl. maybe better crypto integration than ipsec today (v6
doesn't solve that problem despite the claims it would either).
But then network admins would have been able to keep track of hosts in
their own networks.
;)
-B
Re: PF Seems To Reload Its Default Rules Unexpectedly
On Sat, 21 Mar 2009 21:03:45 +0100 Henning Brauer lists-open...@bsws.de wrote: whoever claims v6 would be any good has never written network code dealing with it. hey, compare these two which do the same, one for v4 and one for v6: snip great code example don't get me started on the 160bit addresses (128 + 32 scope ID) which fuck up all alignment. just v4 with addresses extended to 64bit (that is still an integer!) would have been sweet, with minor adjustments/additions like hopcount instead of ttl. maybe better crypto integration than ipsec today (v6 doesn't solve that problem despite the claims it would either). Thank you Henning. -- J.C. Roberts
Re: PF Seems To Reload Its Default Rules Unexpectedly
* J.C. Roberts list-...@designtools.org [2009-03-10 02:03]: The smart answer for an ISP is moving to IPv6 that is about the least smart thing anybody could do. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: PF Seems To Reload Its Default Rules Unexpectedly
* J.C. Roberts list-...@designtools.org [2009-03-09 10:06]: 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 debatable, there is a default ruleset in /etc/rc loaded early before the real pf.conf is loaded. but unless someone manually runs rc there is no way that could be loaded. technically, the default ruleset is pass, everything else has to be sent to the kernel by pfctl. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: PF Seems To Reload Its Default Rules Unexpectedly
Is your external IP on DHCP? I doubt it's pf that's changing. -Bryan On Sun, Mar 8, 2009 at 4:01 PM, Hilco Wijbenga hilco.wijbe...@gmail.com 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. 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
Re: PF Seems To Reload Its Default Rules Unexpectedly
On 2009-03-12, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: 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. that's an invalid netmask. do you mean 255.255.255.0? or not? 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. the (iface) syntax works fine... please show pfctl -vsr and pfctl -vsn
Re: PF Seems To Reload Its Default Rules Unexpectedly
Hi!
On Mon, Mar 09, 2009 at 07:06:10PM -0700, Hilco Wijbenga wrote:
[...]
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
You missed the parens in the marked place.
[...]
Kind regards,
Hannah.
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
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=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500
groups: tun egress
inet 70.212.222.173 -- 66.174.217.64 netmask 0xff00
My external interface tun0 has an IP address of 70.212.222.173 with a
netmask of 255.255.255.0 (0xff00), 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 }
Re: PF Seems To Reload Its Default Rules Unexpectedly
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. 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? 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. -- J.C. Roberts
Re: PF Seems To Reload Its Default Rules Unexpectedly
On 3/9/09 2:05 AM, J.C. Roberts wrote: 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. 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? 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. Interesting, that is brings up a question for me... what do we do in this case? My ISP seems to be content to give the same ip back over and over again. If they did not is there something I can do besides monitor my $ext_if and reload the rules on ip addr change? Just curious.
Re: PF Seems To Reload Its Default Rules Unexpectedly
On Mon, Mar 09, 2009 at 08:10:00AM -0700, Dag Richards wrote: Interesting, that is brings up a question for me... what do we do in this case? My ISP seems to be content to give the same ip back over and over again. If they did not is there something I can do besides monitor my $ext_if and reload the rules on ip addr change? ($ext_if)
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
Dag Richards wrote: 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. Interesting, that is brings up a question for me... what do we do in this case? My ISP seems to be content to give the same ip back over and over again. If they did not is there something I can do besides monitor my $ext_if and reload the rules on ip addr change? Just curious. To get an idea, you best take a look at the Example Rulesets in the PF FAQ. And off course, grind the PF documentation on how to use parentheses on interface names. ($ext_if)
Re: PF Seems To Reload Its Default Rules Unexpectedly
Ah, different semantics. :-) By default rules I mean whatever pf does *without* an /etc/pf.conf. Probably something like block all. Without any rules, pf does not block anything. come on.. stop making assumptions.
Re: PF Seems To Reload Its Default Rules Unexpectedly
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. 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. 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. 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. 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. -- J.C. Roberts
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
Re: PF Seems To Reload Its Default Rules Unexpectedly
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. 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. And uptime to prove it hasn't been rebooted. And grep pf /etc/rc.conf.local so we can see how you're starting it. In other words, *useful information*. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
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
