Incorrect source address on IPv6 UDP responses, when preferring temporary addresses
Hiya,
Running Knot-resolver 2.4.0 (from your provided apt repo, on Debian 9), we find that kresd does not preserve the destination address on IPv6 that the query came from and reply using that IPv6 source address. Instead, it looks like the kernel source address selection code chooses the response source address.
An example case: knot-resolver running on a host that uses IPv6 privacy addressing preferred for outbound connections, configured with ULA addresses. Client is connected to the same link.
root@resolver:~# ip -6 addr show dev enp0s8 | grep -v lft
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fd3a:197c:1b0c:ed04:4c78:e9c2:c54:9f8c/64 scope global temporary dynamic
inet6 fd3a:197c:1b0c:ed04:a00:27ff:fed4:1547/64 scope global mngtmpaddr dynamic
inet6 fe80::a00:27ff:fed4:1547/64 scope link
root@resolver:~# cat /etc/network/interfaces
iface enp0s8 inet6 auto
privext 2
accept_ra 1
root@resolver:~# sysctl -a | grep enp0s8 | grep use_tempaddr
net.ipv6.conf.enp0s8.use_tempaddr = 2
user@macosx-client:~$ ifconfig vboxnet0 | grep inet6
inet6 fe80::800:27ff:fe00:0%vboxnet0 prefixlen 64 scopeid 0x11
inet6 fd3a:197c:1b0c:ed04::1 prefixlen 64
user@macosx-client:~$ dig @fd3a:197c:1b0c:ed04:a00:27ff:fed4:1547 www.google.com
;; reply from unexpected source: fd3a:197c:1b0c:ed04:4c78:e9c2:c54:9f8c#53, expected fd3a:197c:1b0c:ed04:a00:27ff:fed4:1547#53
;; reply from unexpected source: fd3a:197c:1b0c:ed04:4c78:e9c2:c54:9f8c#53, expected fd3a:197c:1b0c:ed04:a00:27ff:fed4:1547#53
;; reply from unexpected source: fd3a:197c:1b0c:ed04:4c78:e9c2:c54:9f8c#53, expected fd3a:197c:1b0c:ed04:a00:27ff:fed4:1547#53
; <<>> DiG 9.10.6 <<>> @fd3a:197c:1b0c:ed04:a00:27ff:fed4:1547 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
root@resolver:~# tcpdump -i enp0s8 -v -n port 53
tcpdump: listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
23:14:28.078101 IP6 (flowlabel 0xc09d2, hlim 64, next-header UDP (17) payload length: 51) fd3a:197c:1b0c:ed04::1.64020 > fd3a:197c:1b0c:ed04:a00:27ff:fed4:1547.53: [udp sum ok] 47701+ [1au] A? www.google.com. (43)
23:14:28.078359 IP6 (flowlabel 0xa104b, hlim 64, next-header UDP (17) payload length: 67) fd3a:197c:1b0c:ed04:4c78:e9c2:c54:9f8c.53 > fd3a:197c:1b0c:ed04::1.64020: [bad udp cksum 0x2001 -> 0x84c0!] 47701 1/0/1 www.google.com. A 172.217.0.100 (59)
23:14:33.079937 IP6 (flowlabel 0xc09d2, hlim 64, next-header UDP (17) payload length: 51) fd3a:197c:1b0c:ed04::1.64020 > fd3a:197c:1b0c:ed04:a00:27ff:fed4:1547.53: [udp sum ok] 47701+ [1au] A? www.google.com. (43)
23:14:33.080139 IP6 (flowlabel 0xa104b, hlim 64, next-header UDP (17) payload length: 67) fd3a:197c:1b0c:ed04:4c78:e9c2:c54:9f8c.53 > fd3a:197c:1b0c:ed04::1.64020: [bad udp cksum 0x2001 -> 0x84c5!] 47701 1/0/1 www.google.com. A 172.217.0.100 (59)
23:14:38.080712 IP6 (flowlabel 0xc09d2, hlim 64, next-header UDP (17) payload length: 51) fd3a:197c:1b0c:ed04::1.64020 > fd3a:197c:1b0c:ed04:a00:27ff:fed4:1547.53: [udp sum ok] 47701+ [1au] A? www.google.com. (43)
23:14:38.080965 IP6 (flowlabel 0xa104b, hlim 64, next-header UDP (17) payload length: 67) fd3a:197c:1b0c:ed04:4c78:e9c2:c54:9f8c.53 > fd3a:197c:1b0c:ed04::1.64020: [bad udp cksum 0x2001 -> 0x84ca!] 47701 1/0/1 www.google.com. A 172.217.0.100 (59)
For my Mac OSX client, the packet comes from the wrong address and is rejected by dig.
On my Linux client, the packet is dropped by UFW as ip6tables does not recognise the conntrack state, due to the incorrect source address.
TCP works OK. Queries to the temporary v6 address work OK, as this is chosen as the response address. But queries to the EUI-64 address (or a configured static address) result in responses from the temporary address.
This behaviour is both when knot-resolver is listening on port 53, and also when using systemd socket activation.
Since there can be multiple v6 addresses on a host, I would be expect that the response would explictly come from the source v6 address that the query was sent to.
If you need any more information, just let me know.
Thanks!