VPN-settings save error if external interface is selected and goes down.

[trym@…]

If a VPN-server is set to listen on a specific external interface, and the interface goes from a working condition to non-working (for example PPPoE losing DSL-connection), then saving settings produces the error:

"VPN server <name> couldn't be configured, no IP address found for interface eth<x>."

I also suspect that if the connection changes address (again, a DSL-line which has gone down, then comes back up), that the VPN-server does not get re-configured, but continues to listen on the old address, requiring a restart of the VPN-server.

To simulate a DSL-connection going down:

Configure a working external interface, as for example DHCP. Configure VPN-server to listen on that interface. Change the interface to PPPoE with a non-working connection. Save changes: the error will appear.

If changing the VPN-server to listen on all interfaces, the error goes away.

---

When a DSL-connection goes down, the very first thing an administrator will try is to refresh PPPoE-interface, and will be unable to completely save changes (as after refreshing the interface, settings for 8 modules are saved.) This can make any admin nervous.

[jamor@…]

Thanks a lot for your report, Trym. There are three different issues there.

the unable to save changes if interface is down issue.

Unfortunely we need a IP address to put in the configuration file. A interface name does not work. If we listen on all interfaces we don't need to put any address so we don't have any problem.

Maybe we should change the message to remind the admin that he could retry later

the change address problem in the server

You are right in your suspicion. We plan to address this issue and others related with address changer later, possibly in a iteration of the 2.1 version.

In the meantime you can try one of this two manual solutions.

1. you could put a dhclient hook script to restart the vpn module when it get a

lease.

2. you can put your server to listen on all address and then use the firewall to

restrict the connections. If you do this you would want to disable the automatic rule put in place to allow connections to the VPN server. (Firewall-> Packet Filter -> Rules added by Zentyal services)

the change address problem in the client

If the interface change address, the VPN clients could not connect. There are two possible ways around this:

1. If you know the address pool you can put all the alternate address in the

client configuration. The client will try addresses until it found one it is working. There is authentication with certificates so an accidental connection to a foreign server is not an issue unless your CA is stolen. (and then is not accidental..).

The bundle configuration allows up three different alternate address but you could put more manually in the configuration file.

2. Instead of using IP address for the client, use a hostname. This make clients

easier to deploy and maintain but the admin has to maintain the DNS record updated.

[jamor@…]

This shouldn't be closed..

[trym@…]

1) the unable to save changes if interface is down issue.

It shouldn't throw an error and stop the save-process. It should throw a warning instead, letting the save process complete. So instead of throwing the error, why not just close it down with a message like "VPN-server <name> shutting down - no address to listen to." so it can easily be seen as "stopped" in the dashboard, and restarted when the connection comes back up.

2)the change address problem in the server.

I (of course) already use a /etc/ppp/ip-up.d script to update dynamic dns, so I guess I can start the VPN-server from there. But what is the status of the server after the saving-error? Can it be restarted and just work, or do we need to "fix" something since saving changes didn't work? Will "/usr/share/ebox/ebox openvpn restart" be enough?

3) Not a problem for any of our servers, we use dynamic dns and host-names to connect to the VPN-servers.

Thanks for listening.

[jamor@…]

Can it be restarted and just work, or do we need to "fix" something since saving changes didn't work? Will "/usr/share/ebox/ebox openvpn restart" be enough?

I was thinking in a server which has already saved changes. In this case the 'restart' command will rewrote the configuration file with the new address and the the server will be restarted.

In case there was before a problem saving changes it would not be a good idea because other servers and clients could be let without the applied changes; better to fix this before.

[jamor@…]

We will let this pending until we implemented the infrastructure needed to restart odules on interface changes.