Fresh install of 3.3 along FAQ, first reboot, nothing but bringing up PPPoE: ifconfig up xl0 route -n flush ppp -ddial pppoe
You' re right, it disconnects, but how !
When I remove the phone cable: nothing happens, route stays, tun0 -
config remains, pfctl remains. To a 'down' interface. Only after I
reconnect the cable will ADSL-modem start to negotiate for a new address;
still at the 'old' route; the PF at the 'old' (tun0), because it's still
configured. After (!!) negociation of a new identity (IP) will the tunnel
device be reconfigured, followed by PF and route.
The 'clean' approach is doubtless: ppp detects link down, takes out the
route and deconfigures; followed by PF removing the NAT address. A
re-negotiation for a new identity *must* only start after tearing down the
previous states; followed logically by (re-)configuring the tunnel device
(IP), adding the new route and adopting the new IP in PF.
No 'overlap' of former and current states, ids, configuration must be
permitted. Any undefined state is an invitation to exploits. Personally, I perceive
dead routes lying around as very annoying.
So my previous comment about ppp handling linkdown is off base. It sounds
as though either ppp or pppoe isn't handling linkdown the way you expect.
I don't have a way to test that here.
As far as previous state/dead routes go, it depends on the situation. If
nothing is actually being sent out (and it shouldn't be, until pppoe
renegotiates and starts encapsulating traffic again), then it is actually
in-line with typical network behavior. If you have a static default route
to a typical ethernet interface, and the cable is unplugged, nothing
happens to that route. The packets just don't go anywhere until you plug
the cable back in.
To keep this on topic, what exactly are you seeing pf do in this case? Is it working correctly after re-negotiation? How are you checking pf's status?
NAT-ing and routing to an IP that by then might belong to someone else is
nothing I'd expect to see in OpenBSD.
I wouldn't expect that either. But unless it's actually doing that, and not just dropping the packets, it's not an issue.
OTOH, there should be feedback of some kind to the clients, such as ICMP dest-unreach messages, while the link is down. That would be handled by the kernel's normal forwarding process. If that isn't happening, then I tend to agree that there's something wrong with ppp/pppoe.
pf itself should be working as expected based on the feedback it gets from the rest of the system.
