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.
