Status of the migration tool

Hi  

Please take a look at ChrisMcCormack's post here for context.

• The UTM to XG Migration Assistant is available to Sophos Partners
• Customers/End-Users should reach out to their Sophos Partner / Rep for more info

Note: Sophos Partners can access this blog post that provides more information

Flo,

my question is more about the status of the tool in terms of features that are still not covered by the tool.

We expect to have a tool that convert everything from UTM 9 to XG.

Certain complex installations, starting from the scratch is almost impossible, as customers have refined their configuration that is impossible to reproduce it.

Thanks

Hello FloSupport and Luk,

give me some time and I think I will be able to tell you if the migration tool is able to migrate the configuration from UTM v9.701 to v18 EAP3-Refresh1. 

Alternatively, I will report any errors in the migration tool, if I will be able to identify them.

Regards

alda

Hello FloSupport and Luk,

give me some time and I think I will be able to tell you if the migration tool is able to migrate the configuration from UTM v9.701 to v18 EAP3-Refresh1. 

Alternatively, I will report any errors in the migration tool, if I will be able to identify them.

Regards

alda

Hi Alda,

Hint: just remove 9701 from unencrypted UTM Backups and SMA still works (producing 17.5-compatibel XG configs).

Regards

Steven

Hi Steven

dos the migration migrate all the configurations? Like ipsec, WAF, Certificates and so on?

On the partner portal, there is a pdf that shows which components cannot be migrated. The list of objects that cannot be migrated is long.

Maybe they released a new version?

Hi Luciano,

we still use SMAOS from April 2019 Partnerportal Post partnerportal.sophos.com/.../sg-to-xg-upgrades.aspx

• SW-SMAOS_17.0.0_SMA_2-1818.iso, Checksum : b5dc34c1b34eb8ecbc4a5770c0ca46c3 or
• Update  SW-SMAOS_17.0.0_SMA_2.SFW-1818.gpg, Checksum : 747c19f9e56688fec09658f8760dddff

WAF: no (afaik) and IPsec: yes

...

Site-to-Site VPN

• IPsec: Connections; remote gateways; policies; local RSA key; Advanced
• SSL: Settings; Advanced
• Certificate Management: Certificates; certificate authority

Remote Access

• PPTP: Global
• L2TP over IPsec: Global
• IPsec: Connections
• Advanced

...

Regards

Steven

Hello all,

as I mentioned, I spent some time testing migration from v9.701 to v18 EAP3- Refresh1 and here are my findings:

- the latest officially supported version is v9.605-1. If you want to migrate v9.700-5 or v9.701-6, you have to replace v9.700-5 / 9.701-6 in the .abf file with the latest supported version v9.605-1. Thanks SayFriedLight  for letting me know how to fix the problem with supported backup version! 

- Firewall rules where the source or destination is object  (User Network) are not migrated and there is no record or notification anywhere in the documentation / migration log. Please see to the first picture below for example rule. In my tests, the configuration migration "disappeared" a total of 7 firewall rules without a single record of why this happened. I know that users objects ( or group ) are not migrated as part of the migration, but the secondary consequence is that there are also dropped firewall rules in which user objects are used. Without any warning!

- The first migrated firewall rule ID has the highest number and the last migrated firewall rule has the lowest number ID of rules, which is in my opinion totally illogical. Of course, is true that the ID rules in UTM9 and XG have different functions and meanings. However, for UTM9 administrators who migrate to XG, it will be very confusing and this error (in my opinion) will not make it easier to work in the new XG environment.

- The network object Internet is erroneously migrated. The problem is, I think very well document by the following two pictures ( again below ) and by picture of the Internet object. The result of a bad migration firewall rule is the target zone Any, although the target zone have to be WAN zone ( I think ) !. Unfortunately, as you know the Any zone in the migrated rule means any zone within the XG configuration (WAN, LAN, DMZ, WiFi, VPN, etc.). In my opinion a very critical error in migration!

A possible solution to this problem could be a "translation table" at the beginning of the whole migration. Thus, this migration table give the administrator the ability to define which interface from the UTM9 configuration will be migrated to what target zone in the XG Firewall itself.

 For example:

Eth0       ->           LAN

Eth1       ->           WAN

Eth2       ->           DMZ

 Another significant benefit of such a translation table would be to automatically add the appropriate zones to the migrated firewall rules. Now, after migration, all migrated firewall rules do not have either a source or destination zone assigned. The consequence is the need to additionally edit all firewall rules and define the appropriate source and target zones, which in the case of several hundred or more firewall rules may be somewhat exhaustive.

- Obviously, NAT rules are not migrated, this is obviously the result of removing NAT rules from the complex firewall rules in v17.5

In my opinion, the current version of the migration tool is not applicable to v17.5 and certainly not to v18. However, in the first half of October last year, I received the following response to my previous notice regarding the quality of the migration tool:

Hi alda,

I've received feedback from the Migration team:

They appreciated your analysis and feedback and will reference it as they continue to work on improving and enhancing the migration experience. They are currently working on the next version of the tool and will provide more info as it becomes available.

Best,

So my question is, when will be released new migration tool for migration from v9.x to v18? 

Regards

alda

Comprehensive test, Alda.

So the tool is not still very useful if you have/use more than "normal" configuration.

Hi Alda,

thank you for sharing the test results. But honestly we never used the Internet Object (0.0.0.0 at WAN, introduced in UTM 7.5!) for more than SSL VPN or Guest-Wifi as Destination and avoided User Network Objects at all cost. UTM is imo not an Identity-based Firewall!

So try to adjust these quite uncommon configurations and enjoy the rest of the Tool :)

You can generate an Public IPv4 Object with https://github.com/iaasteamtemplates/XgOnAzurePOC/blob/master/createInternetIPv4Group.sh for example.

Regards

Steven

Hello SayFriedLight,

on the contrary, I see a really big advantage in using the "Internet" object in UTM v9. Therefore, if you look at the description of this object for IPv4 or IPv6, here is "" Any "network, bound to interfaces with default gateway". Etc. all networks available ONLY on the Internet BEHIND default gateway or Uplink Interfaces. Because, compared to the "Any" network object (which you most likely use), the "Internet" object does not include any internal networks and possibly DMZ networks defined behind the firewall internally as a subset of the relevant IPv4 / IPv6 networks.

This is a fundamental difference between "Any" and "Internet" objects. From my point of view, my firewall rule set (when using the "Internet" object) is logically much more secure and also necessarily with less firewall rules, because I do not have to deal with potential security collisions when using the "Any" object. Furthermore, the "Internet" object is essentially a WAN zone definition in UTM v9, as defined as a zone object in the XG Firewall!
So, for the above reasons, I see very good (above) reasons why, when defining firewall rules in UTM v9 for communication from any internal network in the direction to the Internet, use "Internet" as the target network in the Internet.

And therefore (again for the above reasons) I claim and Sophos confirmed that the migration of the "Internet" object is wrong in the current version of the migration tool, as they themselves have verified in their internal tests.

Regards

alda

I use Internet object too on my installation and I taught my customers to use Internet for everything that is not LAN or inside their network.

Any is very dangerous and must be used carefully. I fully agree with Alda.

The tool must be optimized to migrate the full configuration, even WAF.

It is not impossible, as there is code behind and it can be done.