On 18.0.1 MR-1-Build396.
The new NAT setup does not work. On v17, picking the gateway you wanted worked great.
The gateway setup does not work. If the WAN gateway and VPN gateway have the same weight (as shown below), then the WAN stops working.If I change the weight of the internet WAN gateway to 2 or more, the internet works again.
The default NAT rule only has the internet WAN link in it and not the VPN WAN link in it. This works when the gateway weights are not equal.
This NAT rule for the guest network DOES NOT WORK.
The only way to get NAT to work with a second WAN link (as shown below) is to create a linked NAT rule and then override SNAT for ONE specific host.So how am I supposed to have a guest network with a separate WAN link?
Thanks for listening.
EDIT 1:yes, there is a corresponding firewall rule in case you are wondering.
Try to delete all your NAT rules. The default NAT rule on bot will pick up the traffic. Make sure, both WAN Gateways are selected there.
As counter intuitive as that seemed to be, it worked! Thank you…
Multi WAN scenario needs SD-WAN PBR rules. NAT decide, which IP to use. SD-WAN decide, which interface to use. See: https://community.sophos.com/xg-firewall/f/recommended-reads/121408/routing-in-xgv18-with-sd-wan-pbr
I appreciate the suggestion but adding an SD-WAN policy based route had a completely negligible effect.
You have a Route precedence on top. It depends on your setup, what you try to do.
SD-WAN Rules will only be applied, if there is no Static route on top, which "matches" this traffic.
Your Guest networks looks good, it should use the correct interface.
PS: Actually you do not need your SNAT Rules, as they simply do "MASQ if WAN". There is a default SNAT Rule on Bot, which will do this all the time, if the leaving interface is your WAN interface, to be sure, all traffic is MASQ before going to your ISP.
I am trying to send the Guest network and the DMZ out the second WAN link. The only way to get NAT to work with a second WAN link is to create a linked NAT rule and then override SNAT for ONE specific host.
My assertion still stands. V17 had the simple option to pick the WAN gateway in the firewall rule. It worked. Flawlessly. The new separated NAT rules do not work.
You are mixing up two different point in the product.
WAN Gateway in V17 is SD-WAN PBR in V18.
MASQ in V17 is NAT in V18.
So of course, NAT will not work, if you did this with PBR in V17.
Check your SD-WAN PBR Rules, if they are correct and matching.
Make sure, Routing precedence is not causing issues in your setup (For example you have Static before SD-WAN and have a static route to your destination network).
Migrating from V17 to V18 will actually copy the Firewall selection of the gateway into a SD-WAN PBR.
As counter intuitive as that seemed to be, it worked! Thank you so much. I appreciate the help, and I am glad that it is working, but I still feel the v17 solution was the more elegant one.
Sometimes complexity is not the solution, if you can have a elegant and simple solution.
Assuming your NAT did not the job as it should be, ISP are going to drop your traffic.
You only need one NAT Rule for SNAT (MASQ). Its a dynamic rule, which will pick up all WAN Interfaces. Therefore you do not need to think about MASQ. Only think about Routing -> Which gateway should i use in certain scenarios? SD-WAN is the step forward. It will break with "network rules" which we teach for centuries.
Actually in SD-WAN you could have asymmetric routing, which is perfectly fine, because you do not care. The goal is to get the packet to the destination, XG will do that.
I spoke too soon. The internet connection keeps dying if I don't give the gateway a higher weight.
Likely there is a problem with one of your gateways. SD-WAN PBR should overwrite your weight. So even if you tell XG to loadbalance 100 to 0, it should consider your PBR rule and use this always.
You should look at the tcpdump level and login to the CLI. Perform a tcpdump on your backup interface and check, if there is a proper tcp handshake etc.
I had to get rid of the multi gateway configuration as it was completely unreliable. This was not a problem in V17.
As i configured many installation to this day, i am quite confident, this should work. Assuming there is something broken within your setup or your ISPs.