We have hosts that are multi-homed on IPv6 networks and having an issue with NSD sourcing out UDP reply packets via a different interface/IP than the query was received on.
This obviously will cause issues with clients behind firewalls, etc. Looks as though NSD just sources the packet on the egress interface based on the host routing table. So the reply is coming back from a different IP address.
With TCP this isn't an issue....
Coincidentally Unbound has a option to toggle this behavior....
# enable this feature to copy the source address of queries to reply.
# Socket options are not supported on all platforms. experimental.
interface-automatic: yes
Is there such a knob in NSD? If not, can there be?
Hi Robert,
Setting the outgoing IP address depends on the IP_PKTINFO socket
option. Currently NSD does not implement it, but given some time it can
certainly be made to do so.
NSD currently does support the bindtodevice socket option, which should
get you the desired result(?) The option causes NSD to bind the socket
to the device that has it assigned. It's an attribute of the ip-address
configuration option and you can set it like so:
ip-address: 1.2.3.4 bindtodevice=yes
Let me know if it works for you. As for the IP_PKTINFO option, I've
created a GitHub issue: https://github.com/NLnetLabs/nsd/issues/217.
Regards,
Jeroen
Normally just listing the various ip-addresses separately is enough
You're right Stuart. That's most likely enough because then you'd have
a socket per address. Hadn't thought about that, thanks!
- Jeroen
The issue we had was some asymmetric routing where the packet coming into the server didn't always match the interface going out. So the reply would be sent from a different source address.
I think with Unbound it will source the IP on the interface it received the request on, or at least that knob exists. With NSD it's possible the UDP reply comes from the wrong source address. TCP works fine.
I did work around this by limiting which interfaces NSD was bound to, but that's only part of the solution. It would use the correct SOURCE IP, but the OS would still try to use the routing table and send it out the wrong interface.
I know, it's a unique case. This was on a FreeBSD server, so the final solution was to use IPFW to set the next-hop manually rather than rely on the default route.
Hi Robert,
Glad you managed to work around this issue for now. NSD does support
the setfib attribute for ip-address options, that may be of help in
this scenario (maybe you're already using it?).
I'll see if I can port the code in Unbound to NSD at some point. I
actually looked into it when I did the bindtodevice/setfib options
because they get a similar result. Back then we decided to go with the
ones implemented now because they'd skip the routing entirely as
they're originally intended to improve performance. No reason we can't
implement the source address options too though. The source address
option can be considered a little bit more user friendly because the
user wouldn't have to list the addresses separately, which may be
useful in some situations.
- Jeroen