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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html