Multiple outbound interfaces to be natted

Hello hello!

Running VyOS 1.5-rolling-202309220022"

Still immensely enjoying my VyOS high! Being blind and stuck to GUIs for routers is not a good place to be, and home made stuff tend to eventually materialize as cathedrals of patchwork and bad scripting. At least, when it is me patching and scripting! :slight_smile:
I very likely have an extraordinarily dumb question.

I have several interfaces I want to NAT to, from a single internal subnet. I have my WAN interface, and a couple of VPN tunnels on top.
It seems I cannot have many outbound interfaces for a single source nat rule. So I tentatively tried the following alternative, which broke my NAT all together:

set nat source rule 100 outbound-interface ‘eth0’
set nat source rule 100 source address ‘’
set nat source rule 100 translation address ‘masquerade’
set nat source rule 150 outbound-interface ‘tailscale0’
set nat source rule 150 source address ‘’
set nat source rule 150 translation address ‘masquerade’
set nat source rule 200 outbound-interface ‘wg222’
set nat source rule 200 source address ‘’
set nat source rule 200 translation address ‘masquerade’

I imagine the last ruleset takes precedence, and breaks everything else. I also believe I didn’t Google this properly, as the setup is fairly common and I must not be the only one in this situation. The only one that did not figure it out naturally with common sense, most probably!

Any unstuck-me potions around?

Thanks for the great help so far, and all the best.

NAT rules shown are OK. Only first matching rule is handled. And all rules have different output interfaces, so there’s no “overlap.”

Hello there!

I’m not sure I got what you mean.
If you’re saying the configuration I pasted should work, it doesn’t. It breaks my first SNAT rule (100), and clients cannot exit. If I delete my rules for the VPN interfaces, traffic gets flowing as normal.

Any clue?

If you have problems with VPN + NAT, please also share vpn configuration. Maybe issue is there

Hi there,

Good point on the VPN. To avoid unnecessarily induced artefacts, I tried the same set-up without any VPN, mimicking a multi-wan scenario, no failover, no load-balancing. Simply added routes to test traffic via different interfaces, via eth0, via eth1. As soon as I have more than one source nat ruleset, no traffic makes it through.

What I’m trying to achieve is the equivalent of:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

How do you do that?

To somewhat answer your question, though:

About interface tailscale0:

I’m not sure how I can share my Tailscale configuration, but there is nothing fancy. I just log-in to my Headscale instance, and voilà. No special routes, nada, just an internal IP to access other machines via their Tailscale IPs. I need masquerading so I can route natted traffic from my LAN clients.

About interface wg222

That one is a bit particular. I have a public IP from my Wireguard endpoint. I’ve created a separate routing table, and can route via that interface, so reverse path works fine. The outside world can ping my additional public IP and VyOS will happily pong back. As for the above, I need masquerading so that I can permit my LAN clients to exit via the Wireguard interface onto the Internet.

Moving from iptables commands:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

To Vyos commands is as simple as :

set nat source rule XX outbound-interface eth0
set nat source rule XX translation address masquerade
set nat source rule YY outbound-interface eth1
set nat source rule YY translation address masquerade

Configuration for wireguard interface should be similar

Hi there,

If I remove the source address from all my source NAT rules, it works! I will perform some more thorough testing before I venture in thinking it may be a malfunction.

Now, it seems anytime I add the Tailscale interface to my NAT masquerading, I lose my default gateway on reboot.

I would think it extremely odd that my NAT configuration would affect default routes and such. I’m mostly suspecting Tailscale. However, I do not know how to review smartly the networking stack logs.
I say smartly, because reading logs, as a blind person, is serious torture. Timestamp, app, module, log level, etc, line by line…
The scope would be to see the sequencing of how the networking comes up, and why my default gateway from DHCP on my WAN interface gets dropped.

Thanks for all the help!

Once again, without all configuration and requirements, it’s difficult to predict or provide suggestions.
Lot’s of things to review and check: routing policies, nat and firewall, vpn and wireshark configuration, ip networks used, etc…

1 Like


Thanks again for indulging me on this.

Here is my config, however I cannot get anything on tailscale from VyOS ‘show configuration’

The tailscale stuff is vanilla, with no routes besides the

I suspect my Allowed IPs for Wireguard to be part of the issue, but the problem seemingly only occurs when my NAT involves Tailscale.

vyos-config-for-vyos-forum.txt (6.5 KB)

Can’t understand exactly the idea of this configuration:

wireguard wg222 {
policy {
    local-route {
        rule 300 {
            set {
                table 41
# And 
protocols {
    static {
        table 41 {
            route {
                interface wg222 {

What are the requirements or what do you want/need regarding wireguard interface?


In this configuration, the box uses a single WAN interface that obtains its IP via DHCP. As the WAN interface itself is behind a NAT, and situations may vary, I use the Wireguard interface to separately attach a public IP directly on to the box.

The Wireguard Public IP should be able to route to, but the box itself should not route all its LAN clients via the VPN. However, should it be required, the box masquerades the LAN traffic for any potential exits via the Public IP. For instance, if certain setups require IP based authentications, static routes could be set up, so as to allow LAN clients to utilize the authorized Public IP, rather than the potential unknown entity behind the WAN DHCP, NAT, Dynamic IP and otherwise.
Obviously, it goes without saying that the Wireguard interface claims a static public IP.

There you go, Sir, I hope this provides some clarity as to my devious schemes with VyOS! :slight_smile:

Thanks for any pointers!


Hi there,

So it is confirmed, if I add the multiple NAT masquerading rules, I lose my default gateway on my main table on reboot.
If I remove the additional masquerading rules, the default gateway stays.

That is the only difference that breaks my default gateway on the main routing table.

Any suggestion? Is there an optimized way for me to check logs?


So you mean that default-gateway, which is learnt via dhcp on eth0, disappear because of other NAT rules, wich doesn’t involve interface eth0?

Why is it I can’t explain stuff so simply?
Yes, you are totally correct!

Any hints on debugging smartly on my end? I might be able to provide more verbose and helpful info.

That’s wierd.
I see no reason why a nat rule would make default-gateway to disappear (using different interfaces).
While changing and testing, you can use sudo journalctl -b. You can filter logs using other options of journalctl like:

sudo journalctl --since "1 hour ago"
sudo journalctl --since "2023-10-09 18:45:00" --until "2023-10-10 02:10:00"

journactl ref: journalctl(1) - Linux manual page

Is your default gateway a pppoe interface?
If so, does set interfaces pppoe pppoe0 default-route force fix the problem?

Hi there,

My interface is a regular ethernet with DHCP, no PPPoE.


I will attempt an investigation in my logs then! Thanks!

If default gateway is missing, is the next hop (=the gateway) still pingable? If it isn’t , default route also disappears

Hello there,

Next hop is Pingable, in fact all it takes to recover is a ‘$ sudo ip route add default via x.x.x.x’
Still haven’t found why this happens, updated my rolling image a few times, and will try some regression testing by downgrading month by month.
This latter point sounds time consuming, if you have suggestions I’m all ears!