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