SD-WAN why are migrated rule used, but not created on new firewall rules?

https://community.sophos.com/products/xg-firewall/f/firewall-and-policies/118665/v17-to-v18-migration---specific-gateway

Based on this thread, that would be a function that would have to be integrated again in one of the next versions.

you can see from the migration rules, that this function already exists it just cannot be set manually.

Just like a linked NAT rule, there could be an option in the firewall rule "create linked SD-WAN route"

Hi Tim,

sorry, your explanation does not explain why the SD-WAN rules are required for migrated firewall rules but not new rules. Also there is only 1 for IPv6 when 4 rules were migrated.

What happens tot the SD-WAN rules for new firewall rules?

Do the SD-WAN rules override the NAT rule interface assignment?

Ian

Hi Tim,

sorry, your explanation does not explain why the SD-WAN rules are required for migrated firewall rules but not new rules. Also there is only 1 for IPv6 when 4 rules were migrated.

What happens tot the SD-WAN rules for new firewall rules?

Do the SD-WAN rules override the NAT rule interface assignment?

Ian

SD-WAN policies appear to ignore NAT rules?

I deleted one SD-WAN policy and broke the connection. I deleted the entire firewall rule and recreated and now have connectivity without an SD-WAN policy. So, where do the newly created SD-WAN policies hide? I have created an SD-WAN policy before and it looks very like a NAT, somebody didn't think this process through very throughly eg fails the pub test of logic. It is also another process in the passage of traffic through the firewall, therefore can become a performance bottleneck. As part of the migration why was there a need to create linked NAT rules fo all firewall rules then create SD-WAN pouches, one all encompassing would have been sufficient.

Ian

 

And just to add a bit of fuel to one Luk's posts, nothing appeared in logviewer to assist with why the connection was failing.

Ian lets discuss this for a minute.

 

Migrated SD-WAN Policies are "migration helper". Basically they are there to help administrators not to break anything after upgrading to V18.

So if you upgrade to V18, XG will migrate your configuration and you do not have to anything to have the same functions in V18.

 

 

There are no hidden SD-WAN Policies. As mentioned in the other Thread, XG will consider three types of routing, depending on the precedence. 

There are Static, SD-WAN, VPN. 

If there is no SD-WAN policy, XG will fallback to WAN Link Manager all the time. If there is a matching SD-WAN Policy, it will be applied.

 

The current situation depends a second configuration of the same criteria of SD-WAN Policies to match. 

For example, LAN to WAN allow as firewall. You would have to create a SD-WAN Policy with LAN als Source and WAN (ANY) as destination. There are work needs to be done in the future to get a better process for this. But as the state for now, it is like that. 

 

SD-WAN has "nothing to do" with NAT. 

NAT will be applied after the SD-WAN already take place. So you need a Default SNAT Rule, which should be there.

Therefore you do not need any Linked NAT or something like that. 

 

 

Hi LuCar,

I suspect I am being a little slow with this and thank you for the explanation.

Let me show you a simple process and you might be able to see why I am confused.

1/. I have a v17.5.9 firewall rule with a NAT

2/. I migrate that to v18 GA and get a firewall rule, a linked NAT rule and SD-Wan policy which just so happens to point at the same interface as the Linked NAT. Strange

3/. I delete the firewall, NAT and SD-WAN policy, then recreate the firewall rule using the same functions as migrated, then I create linked NAT rule with the same functions as the migrated rule but do not need an SD-WAN policy to make it work. The funny part is the new firewall rule and linked NAT rule have the same IDs as before, trivial.

So what happened to the requirement for an SD-WAN policy?

Ian

First of all, please do not start to work with Linked NAT Rules, they are not needed at all for basic setups and will get messy. 

Simply use the Default SNAT on the Bottom, thats it. This Rule will be used.

Now about SD-WAN. Do you need a SD-WAN Rule? Most likely if you have two interfaces (WAN Uplinks). 

 

SD-WAN needs to be created on the desired outcome. Do you want to force all Port 443 to Gateway one? 

Simply create a ANY - ANY - Port 443 and select Gateway One. 

 

I would recommend, as mentioned in the other Thread, to change the route precedence first. 

 

Thanks Lucar for your suggestion.

Take note that using any any is not the best approach, although as the last NAT rule.

For better approach, please create ad hoc NAT rules and do not use any any, as troubleshooting can be very time consuming. Creating a NAT as any any for source and destination,is like creating a firewall rule "any any" and after a way, you do not understand why the traffic is allowed.

I always suggest to create selective NAT rule like Firewall rule.

So select proper source zone, source IP network, single ip and so on and do the same for destination zone/network and for services.

For the linked NAT, that option is just confusing users and should be removed into next releases.

While for primary and second gateway, the SD-WAN approach, in my opinion is not the maximum. v17 UI was much better and smooth for creating gateway decisions because it was in the same firewall rule and Business Application Rule.

This opinion comes from myself and from the customers (coming from v17) where I showed the new v18, during a 3 hours meeting.

Regards

Hi Luk, LuCar,

thank you for your suggestions. I used the and continued with the linked NAT because my existing migrated had Linked NAT. At one stage I removed all linked NAT and created a single NAT and that approach seemed to slow th XG down so I recreated all the linked NATs. I have run into issues with the linked NAT rules being ignored and another linked NAT rule being used.

So basically I should have 3 SD-WAN policies to cover my three internal network?

I used to have two internet links but due to the short sightedness of our current government I can only have one. If I wish to push the point and have a second link installed it will cost over $1000 just to run an terminate twisted pair cable able 50m.

So tomorrow's challenge is to migrate all my linked NATs to SD-WAN policies.

Ian

 

Just started playing around and found I need to use NAT for some firewall rules eg the NTP proxy. And then there is the issue of traffic classification in two places.

Could you please quickly review the new Online help? 

http://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/concepts/PolicyRouting.html

Is something still unclear ? Question not answered? 

 

I am missing a bit of the UTM‘s style with the NAT/SDWan features. In many cases when a SNAT has to be applied it has to be applied to a specific interface alias of the public subnet being used for a specific service, e.g. SMTP leaving the company from specific IPs. But those aliases can only be used in DNAT rules, not in SNAT. If I apply an IP host object of the public subnet I want a NGFW acting clever enough to check that the SNAT has to be routed over the according interface. Yesterday I had a mail server hitting the correct FW rule, hitting the correct NAT rule and leaving the XG on the wrong WAN port because I deleted all SDWan policies before. Now I run the 2 WAN uplinks in active/backup mode and use 1 SDWan policy for every external IP on the backup line where not the primary IP has to be used (simple MASQ). That works fine for me until now. The DNAT/destination Zone part for V18 confuses me a lot. I define zone DMZ but I have to use the external interface or alias as destination. That IP is no part of the zone, that is not logic. The UTM‘s logic makes more sense to me. The firewall rule allows traffic from real source address to real destination address everything fine. Destination IP pre- and destination zone post-NAT in the same rule confuses more than it helps. I can live with that ACL style on a Cisco ASA, where the ACL is bound to a specific interface and direction. But in a freely positionable ruleset it makes understanding a given firewall config very complicated...