Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixup handling gateway argument to rc.openvpn #625

Merged
merged 2 commits into from
May 7, 2013
Merged

Fixup handling gateway argument to rc.openvpn #625

merged 2 commits into from
May 7, 2013

Conversation

phil-davis
Copy link
Contributor

Handle gateway argument to rc.openvpn
Various fixups to make this work. Now I can:

  • Unplug an interface, any OpenVPN servers/clients in a gateway group using that interface are restarted and come up on the highest tier available interface. OpenVPN servers/clients that are only on that interface go down, of course.
  • Plug in the cable again, any OpenVPN servers/clients in a gateway group using that interface are restarted and come up on the now-highest tier available interface (i.e. they fail back if the interface that just came up is higher tier). OpenVPN servers/clients that are only on that interface now come up.

Phil Davis added 2 commits May 7, 2013 11:38
Make apinger pass the gateway parameter both when an alarm alarms (gateway is down) and when it comes good (gateway is up). This way the downstream openvpn and dyndns code can know what happened and do sensible stuff.
Return the friendly interface name ("wan", "opt1" etc) rather than the actual device name ("vr0", "vr1" etc). The openvpn and dynamic dns code that uses this needs to work with various entries in the config that all use the friendly interface name.
Various fixups to make this work. Now I can:
- Unplug an interface, any OpenVPN servers/clients in a gateway group using that interface are restarted and come up on the highest tier available interface. OpenVPN servers/clients that are only on that interface go down, of course.
- Plug in the cable again, any OpenVPN servers/clients in a gateway group using that interface are restarted and come up on the now-highest tier available interface (i.e. they fail back if the interface that just came up is higher tier). OpenVPN servers/clients that are only on that interface now come up.
@phil-davis
Copy link
Contributor Author

Note: A little more optimization is possible. For example, a gateway group WANpriority with:
WAN Tier1
OPT1 Tier2
OpenVPN client Client1 using interface WANpriority
If in unplug/plug OPT1 (or apinger detects it down/up), then Client1 gets restarted each time.
That is unnecessary. Client1 is already running fine on the highest tier interface. As lower tier interfaces of a gateway group go down/up we do not have to restart everything using that gateway group.
I will have a look at how easy it is to work out this detail and try to optimize it further.

ermal pushed a commit that referenced this pull request May 7, 2013
Fixup handling gateway argument to rc.openvpn
@ermal ermal merged commit 7610866 into pfsense:master May 7, 2013
@ermal
Copy link
Contributor

ermal commented May 7, 2013

Seems like dejavu cause i thought i already did this commit :)
Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants