Re: PPPoE / isakmpd race

2016-02-20 Thread Christopher Snell
On Wed, Feb 17, 2016 at 1:38 AM, Stuart Henderson wrote: > > A more generic (but more complicated) approach would be to use ifstated > to wait until the interface is up before running isakmpd. Stu, Thanks a bunch for this suggestion. This turned out to be the ticket! It works like a champ.

Re: PPPoE / isakmpd race

2016-02-17 Thread Stuart Henderson
On 2016/02/16 20:04, Christopher Snell wrote: > Yes, the Listen-on is static.  Unfortunately, changing the 0.0.0.0 in > hostname.pppoe0 breaks PPPoE. That will be ISP-dependent then, you can definitely hardcode it with some providers. > I think I could work around this in netstart by simply sleep

Re: PPPoE / isakmpd race

2016-02-16 Thread Christopher Snell
Yes, the Listen-on is static. Unfortunately, changing the 0.0.0.0 in hostname.pppoe0 breaks PPPoE. I think I could work around this in netstart by simply sleeping until the link comes up (or a pre-defined timer elapses) but I'm struggling to come up with a more generic approach. There might be m

Re: PPPoE / isakmpd race

2016-02-16 Thread Stuart Henderson
Is the address in "Listen-on" a static address for this connection? If so, you should be able to use it directly in hostname.pppoe0 instead of 0.0.0.0, and that might well solve this.

PPPoE / isakmpd race

2016-02-15 Thread Christopher Snell
Hi, I recently set up a site-to-site IPsec VPN on an OpenBSD firewall/router that connects to the public Internet via PPPoE. I've noticed that the VPN does not come up properly upon system boot because of what appears to be a race condition between the PPPoE connection and isakmpd start. I say "