I lost Internet access because of Hurricane Sandy, and couldn’t get my machine to recover until I power cycled. I think it’s because my external IP changed, and pf doesn’t seem to handle that well for NAT or just in general. The recommended fix, putting the interface name in parentheses, doesn’t seem to work. Anyone have advice?
7 Replies to “Whoops”
Comments are closed.
You have to reload. Pf only reads interface ip when the rules are loaded.
Putting parenthesis around the interface sounds correct for a dynamic addresses. If you’re getting a “Timeout waiting for PADO packet” then it’s something else.
#To perform NAT on entire internal network:
match out on egress inet from !(egress:network) to any nat-to (egress:0)
#Connections to firewall:
pass in on egress inet proto tcp from any to (egress) port $tcp_services
pass in on egress inet proto tcp to (egress) port http rdr-to $webserver
pf on OpenBSD has always handled dynamic address assignment on interface names in parentheses just fine for me. I’ve had a few issues with dhclient not updating routes when it gets a new address, and my own dhclient.script hacks to do things on address change not working for one reason or another. It’s so rare an occurrence though I never bothered to track it all down.
More likely a problem with the default routing not updating correctly.
As mentioned earlier, PF and dynamic ip addresses work just fine (using parantheses does tell PF to look up the current ip address before using it.)
If we accept that PF should be working correctly, then the next thing to verify or resolve is why your default gateway (which ends up in the kernel routing table) isn’t updated correctly.
Are you using any fancy routing that could be effecting how things are being interpreted going out of PF?
extif=”em0″
intif=”nfe0″
nat on $extif from 192.168.0.0/24 to any -> ($extif)
It’s not a very complex config. These events are far enough apart that I can’t remember for sure the sequence of events, but I have ended up in states where the machine itself was online, but NAT was not working.
I was going to try kezkankrayon’s config on my next opportunity to reset my connection.
Apologies, I may have mislead some people. The rules that I had provided on 2012/10/31 at 03:45 were for a post-OpenBSD 4.6 pf version.
I wasn’t able to determine what DragonflyBSD’s latest pf version is based on. It might be worth noting that DragonflyBSD 2.1 pf was a version based upon OpenBSD 4.4 and that the “match” rule was introduced in OpenBSD 4.6.
Systems running a pre-OpenBSD 4.7 pf version might have the following in its rule set,
# Perform NAT on entire internal network:
nat on $extif from $intif:network to any -> ($extif)
# Connections to firewall:
pass in on $extif proto tcp from any to ($extif) $tcp_services
rdr on $extif proto tcp to ($extif) port http -> $webserver
pass proto tcp to $webserver port http
kezkankrayon – I don’t recall exactly what relative version pf is at in DragonFly, but it’s older than what’s in OpenBSD 4.6. The ‘match out…’ syntax causes an error on DragonFly. The syntax you specify (the ‘nat on…’) is pretty close to what I have now. Maybe specifying the interface rather than the address range will make a difference? I’ll change next chance I get, though it’ll take another network event to find out if it works better.