This package has Vyatta configuration and operational templates and scripts for NAT.
Thu, Jan 24
I'm not sure. Only hypothesis...
are you sure, or could it be related to conntrack helper topic in T1141?
May 27 2018
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
Apr 7 2018
can you repeat same on 1.2 ?
Mar 12 2018
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...
Mar 9 2018
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...)
- There are no firewall rules set, and no firewall rulset set to the interface on the affected VyOS instances
- The problems seems to occur whatever the name resolution request is
- Yes, see below
Mar 8 2018
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 !
Mar 7 2018
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
I don't know what it was but now all works fine, sorry for the trouble.
Mar 6 2018
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).