Re: [PATCH] Accept VPN IPv4 configs without a tundevice
- From: Dan Williams <dcbw redhat com>
- To: Martin Willi <martin strongswan org>
- Cc: networkmanager-list gnome org
- Subject: Re: [PATCH] Accept VPN IPv4 configs without a tundevice
- Date: Thu, 08 Sep 2011 13:18:19 -0500
On Wed, 2011-09-07 at 15:18 +0200, Martin Willi wrote:
> ---
>
> I'm migrating our strongSwan VPN plugin [1] to NetworkManager 0.9.
> We use the native Linux IPsec stack. It doesn't use any tundev or ipsec
> network devices, but handles encryption transparently in the networking
> stack.
>
> Unfortunately, the new release (d2d1f2e9, actually) explicitly requires
> a tunnel device, making the Linux XFRM IPsec stack unusable with
> NetworkManager. The trick I used previously by passing an invalid device
> does not work anymore.
>
> The patch below leverages the requirements for a VPN specific device. It works
> fine here, but I'm not sure if it is the best way to handle VPN
> connections without a networking device.
So does the plugin still pass back the rest of the IPv4 config to NM?
One consideration here is that we still want to honor user overrides
like custom routes and whether all traffic goes over the VPN or not. So
we'd still want to process some of the routing to, say, route a certain
subnet over the tunnel by setting that subnet's gateway to the IPSec
secured host address. Etc. That might require changes inside NM, or
even making sure custom routes pushed to the VPN in the NMConnection are
set up correctly by the plugin rather than NM itself.
Basically, if the plugin will ensure that IP addressing and routes get
set up as NM would expect them to, then we can have the plugin to pass a
flag to NM saying that's the case, and then NM wouldn't do much (except
DNS fixups, search domain stuff, etc) but would still advertise the
attributes of the VPN connection such that clients could still determine
the VPN's IPv4 config.
Dan
> Best regards
> Martin
>
> [1]http://git.strongswan.org/?p=strongswan.git;a=tree;f=src/frontends/gnome
>
> src/vpn-manager/nm-vpn-connection.c | 19 +++++++------------
> 1 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/src/vpn-manager/nm-vpn-connection.c b/src/vpn-manager/nm-vpn-connection.c
> index 75ba645..e278266 100644
> --- a/src/vpn-manager/nm-vpn-connection.c
> +++ b/src/vpn-manager/nm-vpn-connection.c
> @@ -419,18 +419,12 @@ nm_vpn_connection_ip4_config_get (DBusGProxy *proxy,
> config = nm_ip4_config_new ();
>
> val = (GValue *) g_hash_table_lookup (config_hash, NM_VPN_PLUGIN_IP4_CONFIG_TUNDEV);
> - if (val)
> + if (val) {
> priv->ip_iface = g_strdup (g_value_get_string (val));
> - else {
> - nm_log_err (LOGD_VPN, "invalid or missing tunnel device received!");
> - goto error;
> - }
> -
> - /* Grab the interface index for address/routing operations */
> - priv->ip_ifindex = nm_netlink_iface_to_index (priv->ip_iface);
> - if (!priv->ip_ifindex) {
> - nm_log_err (LOGD_VPN, "(%s): failed to look up VPN interface index", priv->ip_iface);
> - goto error;
> + /* Grab the interface index for address/routing operations */
> + priv->ip_ifindex = nm_netlink_iface_to_index (priv->ip_iface);
> + if (!priv->ip_ifindex)
> + nm_log_err (LOGD_VPN, "(%s): failed to look up VPN interface index", priv->ip_iface);
> }
>
> addr = nm_ip4_address_new ();
> @@ -540,7 +534,8 @@ nm_vpn_connection_ip4_config_get (DBusGProxy *proxy,
>
> nm_system_iface_set_up (priv->ip_ifindex, TRUE, NULL);
>
> - if (nm_system_apply_ip4_config (priv->ip_ifindex, config, 0, NM_IP4_COMPARE_FLAG_ALL)) {
> + if (priv->ip_ifindex == 0 ||
> + nm_system_apply_ip4_config (priv->ip_ifindex, config, 0, NM_IP4_COMPARE_FLAG_ALL)) {
> NMDnsManager *dns_mgr;
>
> /* Add any explicit route to the VPN gateway through the parent device */
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]