Kresd responds from incorrect source IP

Software SW bugs discussion
1

The details about the setup:
br-lan configured for 192.168.10.1/24
strongSwan IKEv2 server with subnet 192.168.11.0/24 dedicated for vpn clients, advertises 192.168.10.1 as DNS

I have noticed with tcpdump that the DNS queries are received by kresd, but the answer has wronge source IP, therefore it’s not accepted by the vpn client device. Response source IP is set to public IP assigned to eth0, instead of 192.168.10.1 assigned to br-lan.

20:45:35.478364 IP 192.168.11.1.7930 > 192.168.10.1.53: 16589+ A? outlook.office365.com. (39)
20:45:35.480332 IP 151.248.182.89.53 > 192.168.11.1.7930: 16589 6/0/0 CNAME outlook.ha.office365.com., CNAME outlook.ms-acdc.office.com., A 40.101.88.2, A 52.97.137.178, A 52.97.147.178, A 52.97.151.50 (165)
20:45:35.515731 IP 192.168.11.1 > 151.248.182.89: ICMP 192.168.11.1 udp port 7930 unreachable, length 201

As we see above, dns query is sent to 192.168.10.1.53 but response is sent from 151.248.182.89.53, so the VPN device doesn’t recognize this connection and sends ICMP error packet.

TCP-based protocols from mobile device to 192.168.10.1 (for example, turris web ui) work fine. I’ve tried completely disabling any NAT (by cleanup of PRE/POSTROUTING chains), but it doesn’t help - looks like no NAT misconfiguration is involved and issue comes from kresd.

Any ideas?

2

151.248.182.89.53 is not a valid ip, suppose that log been edited prior posting and that it should read 151.248.182.89:53 instead, or is it the syntax from the dump?

Is Use forwarding enabled in Foris -> DNS?

Is WWZ Telekom AG the ISP the TO is connected to?

3

tcpdumpd shows indeed . on turris - but it’s clear, .53 means port 53

“Use forwarding” is not enabled in Foris -> DNS.

I have customized /etc/kresd/custom.conf:

-- Disable IPv6
net.ipv6=false

-- policy for rev dns for local networks
local lan_rule = policy.add(policy.suffix(policy.FORWARD('192.168.24.1'), policy.todnames({'168.192.in-addr.arpa'})))
policy.del(lan_rule.id)
table.insert(policy.rules, 1, lan_rule)

-- int.hidden.xxx
policy.add(policy.suffix(policy.FORWARD('192.168.24.1'), policy.todnames({'int.hidden.xxx'})))

-- TLS forwarding to cloudflare
policy.add(policy.all(
  policy.TLS_FORWARD({
    {'1.1.1.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'},
    {'1.0.0.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'}
  })
))
4

Yes, WWZ Telekom AG the ISP the TO is connected to via WAN.

5

try/check in “/etc/config/network”

config interface 'wan'
	option delegate '0'
	option peerdns '0'

Requires a network restart from the cli ("/etc/config/network" restart).

Else I am not familiar with kresd, with being more of a stout unbound user. Perhaps someone else could assist though it does not seem to an issue with kresd but the VPN setup, which I cannot help with either as being uninitiated with StrongSwan too.

6

This is a mis-feature of kresd when listening on ::0 (which Turris does by default, unfortunately). Upstream work-around is to bind to addresses explicitly; I’m not sure how to best do that on Turris.

Listening on ::0 results into OS selecting source address depending on the target address instead of using the address which accepted the query. In most cases the right address is selected even so, but not in all setups.

1 Like
7

DNS forwarding is indeed enabled, see the snippet from /etc/kresd/custom.conf above - it includes at the end policy entry to forward all queries via TLS to clouflare-dns.com. I’ve just double checked with tcpdump - there is no traffic on WAN port 53, it uses port 853 and connects to 1.1.1.1 / 1.0.0.1.

VPN clients have indeed correctly configured DNS.
As you can see on tcpdump snippet, the packet for 192.168.10.1:53 arrives from VPN device (192.168.11.1), the problem is that the response has 151.248.182.89:53 instead of 192.168.10.1:53, so the VPN client device correctly rejects this packet.

I’ve checked if adding options delegate/peerdns you suggested, but this doesn’t change the behaviour.

1 Like
8

Well in /etc/config/resolver there are those list interface lines, so changing them will probably work – they seem to be used in the correct way when initializing kresd command-line – but I’m no good about stuff around UCI configs, so it’s completely at your own risk :slight_smile: Hopefully someone else knows better.

1 Like
10

Works fine for unbound, my end having set

config resolver 'common'
	list interface '127.0.0.1'
	list interface '10.111.222.1'
	list interface '192.168.112.12'
	# list interface '::0'
12

Thanks for suggestions. The explaination with kresd listening on intefaces is logical and sounds like a good solution. I am at the moment at another location, but as soon as I’m back at that office I’ll check your suggestions and add feedback. Again, thanks a lot!

1 Like