Page MenuHomeVyOS Platform

SNAT with static port not working
Closed, ResolvedPublicBUG


Configured SNAT with static ports

rule 10 {

outbound-interface eth0.4002
protocol tcp_udp
source {
    port 5060
translation {
    port 5060

But translation looks

show nat s translations

Pre-NAT              Post-NAT             Prot  Timeout     udp   3598

How to correct configure static port to port SNAT?


Difficulty level
Easy (less than an hour)
Why the issue appeared?
Will be filled on close

Event Timeline

vasglebov created this task.Mar 6 2018, 7:50 AM
vasglebov updated the task description. (Show Details)
rps added a subscriber: rps.Mar 6 2018, 9:37 PM

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).

First thing to check:

NAT rules will only take effect on new connections that happen after they're put in place. Did you verify that there wasn't an existing conntrack entry for this translation from before the rule was added?

If you're sure the rule was there beforehand, the other thing to check is that no NAT rules that would match come before it (only the first matching rule will be applied).

If that doesn't seem to be it, then I'd like to verify the actual NAT rules in the kernel. Using a root shell (sudo -i) can you provide the output of:

iptables -L -n -v -t nat

It would also be helpful to see your entire NAT configuration and not just the rule for this translation.

vasglebov closed this task as Resolved.Mar 7 2018, 2:21 AM
vasglebov claimed this task.

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.

rps added a comment.Mar 7 2018, 4:32 AM

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.