PR: https://github.com/vyos/vyos-1x/pull/2100

There is a task for "loadbalancing" T4109

You can use <x.x.x.x>-<x.x.x.x>
Or you need "multi" addresses not in "range"? Something like

set nat destination rule 5 translation member 203.0.113.1
set nat destination rule 5 translation member 203.0.113.14
set nat destination rule 5 translation member 203.0.113.240

Turns out that 'destination-interface any' works, and I just hadn't read the help.

I'm not sure. Only hypothesis...

are you sure, or could it be related to conntrack helper topic in T1141?

We moved to pdns in 1.2 and will not be fixing it in 1.1.x
if you can reproduce on 1.2 mention this task or create new

can you repeat same on 1.2 ?

Well, as I previously said, I finally know why it doesn't worked as expected for me, since lines like "listen-on vti0 and listen-on vti1" were missing, for requests incoming from tunneled networks.
However, it seems to be strange that requests are sometimes still forwarded, as we can expect that none are forwarded, or all are forwarded, but why sometimes only some request are forwarded ? This seems to be a bug, however this ticket can be closed since for my needs it's ok...

P.S. This is really starting to get more into the territory of support than bug reporting, have you considered purchasing support?

At first glance it looks like the name servers you are using are not reliable, and the lack of response is because the forwarder is also not getting a response.

(By the way, it would be interesting to be able to add more than only one inbound-interface to a NAT rule...)

(And I guess that it's the same reason for NAT rule : the inbound-interface should not only be eth0...)

1. There are no firewall rules set, and no firewall rulset set to the interface on the affected VyOS instances
2. The problems seems to occur whatever the name resolution request is
3. Yes, see below

We'll need some more information.

Yes, I thought about that too, but with or without setting the dns
cache-size to 0, I have the same result !

By default the DNS forwarder will cache recent responses. Have you disabled DNS caching on the forwarding service with the following configuration?

It was likely the first scenario that I mentioned where there was traffic already established before the NAT rule was created. Also note that a reset conntrack is essentially a flush of the conntrack table and can be disruptive for established connections. Alternatively you could have cleared conntrack entries for the specific host address only as a more safe way of doing it in the future.

Thank you for your attention, cause it's router in production at night executed

reset conntrack

I don't know what it was but now all works fine, sorry for the trouble.

I have verified that this is working on 1.1.8 so there might be a configuration or operation issue that is making you see this behavior (I actually have this working in production at scale using over 14,500 rules across 28 chains).