Unbound Delay=X parameter for vpn binding

[Swinson]

What exactly is the delay for when setting up the vpn binding in unbound? What I’m really trying to get at is I would like to do this dynamically if possible rather than setting some static delay.

 

[Martineau]

What exactly is the delay for when setting up the vpn binding in unbound? What I’m really trying to get at is I would like to do this dynamically if possible rather than setting some static delay.

In an ideal world, the openvpn-event triggers should suffice, so no delay= parameter would be necessary, i.e. 'UP' would truly mean that the VPN client is physically established and tunnel designated traffic can flow immediately.

If you remove the static delay= directive, you could always use a SyslogEventMonitor script or enhance the openvpn-event 'UP' scripts to wait/verify (in a spin-loop) that tunnel traffic is actually traversing the established tunnel, then call unbound_manager to immediately modify the unbound interface.

 

[Swinson]

In an ideal world, the openvpn-event triggers should suffice, so no delay= parameter would be necessary, i.e. 'UP' would truly mean that the VPN client is physically established and tunnel designated traffic can flow immediately.

If you remove the static delay= directive, you could always use a SyslogEventMonitor script or enhance the openvpn-event 'UP' scripts to wait/verify (in a spin-loop) that tunnel traffic is actually traversing the established tunnel, then call unbound_manager to immediately modify the unbound interface.


View attachment 28137

Ahh I see how that’s working now. Well that definitely seems doable just got to find some time to work on it. Are there any interrupt type mechanisms I can use or do I just need to poll until it’s up?

 

[Martineau]

Ahh I see how that’s working now. Well that definitely seems doable just got to find some time to work on it. Are there any interrupt type mechanisms I can use or do I just need to poll until it’s up?

If the openvpn-event triggers 'vpnclientX-up'/'vpnclientX-route-up' are deemed inappropriate, then the only alternative would be to hang your polling script (if still required) off the process that issues the final 'Initialization Sequence Completed' message.

e.g. Syslog chronological events...

15:41:15 RT-AC68U openvpn-event[9858]: User openvpn-event running
15:41:15 RT-AC68U openvpn-event[9858]:      Script executing.. for VPN event: vpnclient1-up
<snip>
15:41:20 RT-AC68U openvpn-event[10326]: User openvpn-event running
15:41:20 RT-AC68U openvpn-event[10326]:      Script executing.. for VPN event: vpnclient1-route-up
<snip>
15:41:26 RT-AC68U ovpn-client1[9802]: Initialization Sequence Completed

i.e. on my router there are actually 11 seconds between the misleading 'vpnclient1-up' event trigger and the final 'Initialization Sequence complete' message.

So if delay=5 is specified in trigger 'vpnclient1-route-up', then perhaps it should be increased to delay=6?, my point being that fine tuning the delay value would be a lot less work than writing the polling script?

 

[Swinson]

If the openvpn-event triggers 'vpnclientX-up'/'vpnclientX-route-up' are deemed inappropriate, then the only alternative would be to hang your polling script (if still required) off the process that issues the final 'Initialization Sequence Completed' message.

e.g. Syslog chronological events...

15:41:15 RT-AC68U openvpn-event[9858]: User openvpn-event running
15:41:15 RT-AC68U openvpn-event[9858]:      Script executing.. for VPN event: vpnclient1-up
<snip>
15:41:20 RT-AC68U openvpn-event[10326]: User openvpn-event running
15:41:20 RT-AC68U openvpn-event[10326]:      Script executing.. for VPN event: vpnclient1-route-up
<snip>
15:41:26 RT-AC68U ovpn-client1[9802]: Initialization Sequence Completed

i.e. on my router there are actually 11 seconds between the misleading 'vpnclient1-up' event trigger and the final 'Initialization Sequence complete' message.

So if delay=5 is specified in trigger 'vpnclient1-route-up', then perhaps it should be increased to delay=6?, my point being that fine tuning the delay value would be a lot less work than writing the polling script?

@Martineau Yes tuning the delay would be far easier but as you said that value is going to change based on your hardware/addons.
Throughout the process of setting up unbound I found several posts of people asking about the setup and although there are resources out there nothing really seemed comprehensive. I figure I can spend a little extra time and try to make whatever I write more cross router compatible. Definitely not the easiest solution but I’m enjoying learning the system and hopefully the end result will be one less headache for someone.