Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
Em 11-11-2015 00:06, Nick Holland escreveu: > The point is...if you put in a DNS name, odds are you are going to end > up thinking you are blocking/passing/redirecting a DNS name..when in > reality, you are whatevering JUST the IP address that it resolves to at > the time the firewall rules were loaded. You may have missed a lot, or > it may move. > > IF you are really in a situation where the only things you are trying to > manage with DNS names are simple 1:1 name:ip mappings, an easy solution > would be to have your pf.conf file a "stub" with enough to let the > system come up, then a post boot and periodic (re)load of the "real" > rules in a separate file. I tried to help the OP by suggesting he use macros or anchors; I'd like to take it back. Don't ever use dns names on pf.conf. The only safe way to properly deal with this is using a proxy. Relayd can work quite well for simple cases. Cheers, Giancarlo Razzolini
pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
Precondition: /etc/pf.conf contains scr_addr/dst_addr set to FQDNs On boot, the consoles shows error about not being able to load pf.conf because it can't resolve the symbolic names. http://www.openbsd.org/faq/faq6.html#Setup.activate says:    "... if you had specified a DNS-resolved symbolic name in any of    the files, you would probably find it worked as expected after    reconfigure, but on initial boot, your external resolver may    not be available, so the configuration will fail." but I thought that the statement might be limited to `netstat`, and /etc/rc runs `netstat` before loading the firewall rules. So I'm not sure why it's not working... Anybody run into this before? - is the fix to add all the symbolic names to /etc/hosts? Thanks, Kent
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
Em 10-11-2015 13:58, Kent Watsen escreveu: > Precondition: /etc/pf.conf contains scr_addr/dst_addr set to FQDNs > > On boot, the consoles shows error about not being able to load pf.conf > because it can't resolve the symbolic names. If your resolver can't be accessed, this will happen. > > http://www.openbsd.org/faq/faq6.html#Setup.activate says: > >    "... if you had specified a DNS-resolved symbolic name in any of >    the files, you would probably find it worked as expected after >    reconfigure, but on initial boot, your external resolver may >    not be available, so the configuration will fail." > > but I thought that the statement might be limited to `netstat`, and > /etc/rc runs `netstat` before loading the firewall rules. So I'm not > sure why it's not working... As a general rule you should avoid using dns names on anything that might cause the boot process to fail. Even more, you should really avoid using names on hostname.if files. > > Anybody run into this before? - is the fix to add all the symbolic > names to /etc/hosts? Well, if the hosts have fixed addresses, you'd be better using macros on pf.conf that translate to their IP address. This way you won't run into boot issues (or reload issues, in case your resolver is down). This has the added inconvenience that you need to update your pf.conf file manually every time one address changes. Now, if you really, really need to use fqdn's on pf.conf, my suggestion is that you use ifstated to detected if your link is up and your resolver working, and them load the rules into an anchor afterwards. Also, you can update the anchor to reflect any uplink unavailability. Or you can use unbound with local-zones or a unbound + nsd combo, if you also need authoritative. I think you'll need to hack your /etc/rc file to load them before your pf.conf is loaded. Cheers, Giancarlo Razzolini
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
On 15-11-10 01:45 PM, Giancarlo Razzolini wrote: As a general rule you should avoid using dns names on anything that might cause the boot process to fail. Even more, you should really avoid using names on hostname.if files. Anybody run into this before? - is the fix to add all the symbolic names to /etc/hosts? Well, if the hosts have fixed addresses, you'd be better using macros on pf.conf that translate to their IP address. This way you won't run into boot issues (or reload issues, in case your resolver is down). This has the added inconvenience that you need to update your pf.conf file manually every time one address changes. Now, if you really, really need to use fqdn's on pf.conf, my suggestion is that you use ifstated to detected if your link is up and your resolver working, and them load the rules into an anchor afterwards. Also, you can update the anchor to reflect any uplink unavailability. Or you can use unbound with local-zones or a unbound + nsd combo, if you also need authoritative. I think you'll need to hack your /etc/rc file to load them before your pf.conf is loaded. FWIW, yes, putting the entries into /etc/hosts *will* work, and it avoids the need to use pf.conf macros, ifstated, etc. However, it now means that you have to ensure /etc/hosts remains 100% accurate... although I shudder to think of using ifstated and anchors to do this, it does avoid the /etc/hosts maintenance problem. And make no mistake: you *will* eventually forget to update /etc/hosts. Absolutely, 100% guaranteed. -Adam
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
Hi Kent, On 2015-11-10 Tue 10:58 AM |, Kent Watsen wrote: > > Anybody run into this before?? - is the fix to add all the symbolic > names to /etc/hosts? > Yes, use /etc/hosts. Same for hostnames in /etc/syslog.conf if using localhost unbound as the only nameserver in /etc/resolv.conf. Then also: 1) have a daily script that updates /etc/hosts' IP addresses. But you must remember to add/remove the names manually. 2) reload pf's rules in /etc/rc.local - for when /etc/hosts is wrong... Cheers. -- The reason computer chips are so small is computers don't eat much.
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
On 11/10/15 10:57, Kent Watsen wrote: > Precondition: /etc/pf.conf contains scr_addr/dst_addr set to FQDNs > > On boot, the consoles shows error about not being able to load pf.conf > because it can't resolve the symbolic names. > > http://www.openbsd.org/faq/faq6.html#Setup.activate says: > >    "... if you had specified a DNS-resolved symbolic name in any of >    the files, you would probably find it worked as expected after >    reconfigure, but on initial boot, your external resolver may >    not be available, so the configuration will fail." > > but I thought that the statement might be limited to `netstat`, and > /etc/rc runs `netstat` before loading the firewall rules. So I'm not > sure why it's not working... > > Anybody run into this before? - is the fix to add all the symbolic > names to /etc/hosts? adding yet another voice, though somewhat different answer: don't use symbolic names. Here's the thing: PF works on IP addresses. NOT DNS names. While you might argue DNS names resolve to IP addresses, they do NOT do a 1:1 correlation. You will end up with problems someday that might take a bit of investigation to figure out. Long long ago, a company I used to work for had a firewall that Wasn't My Problem. Or so I thought. It would block various sites management didn't want people going to; the user would just end up at a friendly site saying, "we don't want you to go here". Management decided that webmail was not something they wanted people going to, so they blocked most of the known major webmail services. But every once in a while, when someone would go to Google, they would get the "Blocked!" message. It was rare, but definitely happening, and it could happen all over the company. And half an hour later...problem is gone...only to appear later on someone else's computer. Maybe you are ahead of me. If so, congratulate yourself, I puzzled over this for a few weeks. Turned out the way this firewall blocked SITES was by resolving the name, and adding redirections for those addresses. Someone entered "gmail.google.com" into that table, and it quickly got lost among all the other entries. On boot, the firewall would resolve gmail.google.com, and put the one or five or whatever entries in the block/redirect table, and forget about it. Well...you see, google uses a massive front-end infrastructure for most or all of their services, and the requested name would dictate the route through the load balancers. So...this firewall was blocking probably one or five of the HUNDREDS or THOUSANDS of IP addresses Google would return for ANY of its services. So once in a while, gmail.google.com was blocked, but sometimes so was www.google.com. The point is...if you put in a DNS name, odds are you are going to end up thinking you are blocking/passing/redirecting a DNS name..when in reality, you are whatevering JUST the IP address that it resolves to at the time the firewall rules were loaded. You may have missed a lot, or it may move. IF you are really in a situation where the only things you are trying to manage with DNS names are simple 1:1 name:ip mappings, an easy solution would be to have your pf.conf file a "stub" with enough to let the system come up, then a post boot and periodic (re)load of the "real" rules in a separate file. Nick.
