conntrackd IPv6 client support for interface scope

conntrackd IPv6 client support for interface scope

[Michael Griego]

Greetings,

I’ve been setting up conntrackd on a pair of new firewalls, and I discovered that, while the server code handles setting the scope for the IPv6 address structure, the client code does not.  In a case where a person is using link-local addresses for conntrackd syncing (as I am) on a multi-homed system (as is generally expected in these scenarios, especially since conntrackd is expected to be running on a dedicated interface), this causes the server socket to get bound to the proper scope/interface, but the client socket never gets the scope, so it will fall back to the kernel routing table to connect to its peer.  The kernel routing table will often not choose the correct interface for this.

I patched my local copy of conntrack-tools (for UDP in this case) as so:

--- conntrack-tools-1.4.1.orig/src/udp.c	2013-02-24 16:23:57.183985009 -0600
+++ conntrack-tools-1.4.1/src/udp.c	2014-05-07 14:18:20.407835364 -0500
@@ -144,6 +144,7 @@
 		memcpy(&m->addr.ipv6.sin6_addr, &conf->client.inet_addr6,
 		       sizeof(struct in6_addr));
 		m->sockaddr_len = sizeof(struct sockaddr_in6); 
+		m->addr.ipv6.sin6_scope_id = conf->server.ipv6.scope_id;
 		break;
 	default:
 		ret = -1;


It simply sets the scope ID of the client socket to the same one that’s being used for the server socket.  It should be a safe assumption, since only one Interface stanza is used for the channel configuration.  This did allow usage of link-local addresses to begin working properly without having to resort to setting up host routes in each firewall for the link local address of each other.

The same thing would need to be done for the other channel types as well, but I was curious about the reception of this type of patch before creating a full patch (against 1.4.2 instead of 1.4.1, of course).  As I said, this patched code is now working properly in my setup using link-local IPv6 addresses in a UDP unicast channel.

--Mike

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: conntrackd IPv6 client support for interface scope

[Pablo Neira Ayuso]

Hi,

On Wed, May 07, 2014 at 03:18:04PM -0500, Michael Griego wrote:
> Greetings,
> 
> I’ve been setting up conntrackd on a pair of new firewalls, and I
> discovered that, while the server code handles setting the scope for
> the IPv6 address structure, the client code does not.  In a case
> where a person is using link-local addresses for conntrackd syncing
> (as I am) on a multi-homed system (as is generally expected in these
> scenarios, especially since conntrackd is expected to be running on
> a dedicated interface), this causes the server socket to get bound
> to the proper scope/interface, but the client socket never gets the
> scope, so it will fall back to the kernel routing table to connect
> to its peer.  The kernel routing table will often not choose the
> correct interface for this.
> 
> I patched my local copy of conntrack-tools (for UDP in this case) as so:
> 
> --- conntrack-tools-1.4.1.orig/src/udp.c	2013-02-24 16:23:57.183985009 -0600
> +++ conntrack-tools-1.4.1/src/udp.c	2014-05-07 14:18:20.407835364 -0500
> @@ -144,6 +144,7 @@
>  		memcpy(&m->addr.ipv6.sin6_addr, &conf->client.inet_addr6,
>  		       sizeof(struct in6_addr));
>  		m->sockaddr_len = sizeof(struct sockaddr_in6); 
> +		m->addr.ipv6.sin6_scope_id = conf->server.ipv6.scope_id;
>  		break;
>  	default:
>  		ret = -1;
> 
> 
> It simply sets the scope ID of the client socket to the same one
> that’s being used for the server socket.  It should be a safe
> assumption, since only one Interface stanza is used for the channel
> configuration.  This did allow usage of link-local addresses to
> begin working properly without having to resort to setting up host
> routes in each firewall for the link local address of each other.
> 
> The same thing would need to be done for the other channel types as
> well, but I was curious about the reception of this type of patch
> before creating a full patch (against 1.4.2 instead of 1.4.1, of
> course).  As I said, this patched code is now working properly in my
> setup using link-local IPv6 addresses in a UDP unicast channel.

I don't find a reasonable scenario in which someone would need to
receive sync message from one interface and send them from another.

So I agree with your assumption, could you please send me a patch in
git-format-patch including a Signed-off-by that I can apply with
git-am.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html