Kresd responds from incorrect source IP

The details about the setup:
br-lan configured for
strongSwan IKEv2 server with subnet dedicated for vpn clients, advertises 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 assigned to br-lan.

20:45:35.478364 IP > 16589+ A? (39)
20:45:35.480332 IP > 16589 6/0/0 CNAME, CNAME, A, A, A, A (165)
20:45:35.515731 IP > ICMP udp port 7930 unreachable, length 201

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

TCP-based protocols from mobile device to (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? is not a valid ip, suppose that log been edited prior posting and that it should read 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?

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

-- policy for rev dns for local networks
local lan_rule = policy.add(policy.suffix(policy.FORWARD(''), policy.todnames({''})))
table.insert(policy.rules, 1, lan_rule)

policy.add(policy.suffix(policy.FORWARD(''), policy.todnames({''})))

-- TLS forwarding to cloudflare
    {'', hostname='', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'},
    {'', hostname='', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'}

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

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.

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

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 I’ve just double checked with tcpdump - there is no traffic on WAN port 53, it uses port 853 and connects to /

VPN clients have indeed correctly configured DNS.
As you can see on tcpdump snippet, the packet for arrives from VPN device (, the problem is that the response has instead of, 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

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

Works fine for unbound, my end having set

config resolver 'common'
	list interface ''
	list interface ''
	list interface ''
	# list interface '::0'

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