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!
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 ‘172.25.5.0/24’
set nat source rule 100 translation address ‘masquerade’
set nat source rule 150 outbound-interface ‘tailscale0’
set nat source rule 150 source address ‘172.25.5.0/24’
set nat source rule 150 translation address ‘masquerade’
set nat source rule 200 outbound-interface ‘wg222’
set nat source rule 200 source address ‘172.25.5.0/24’
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.
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.
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, 1.1.1.1 via eth0, 8.8.8.8 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 0.0.0.0/0 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.
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
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.
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…
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 0.0.0.0/0, 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!
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?
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:
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!
