Best approach for replacing existing Cisco ASAs with UTMs and the Reds

Hi,

I can only tell you what I did, which was your option 1 and that worked fine. I would qualify and say "if you have at least 1 spare external ip at each site"

We used UTM's on all sites and configured each branch UTM as "Red" device between site and head office, that way we could have simple VPN to HQ. We used remote UTM's so we can also configure / filter local Internet / voice traffic, as our remote sites all need different web filtering rules.

To build the network we just put a spare internal and external address on each remote UTM and did a manual route change on a test PC (route add xxxx mask xxxx via UTM internal ip). Once we could prove connectivity was as required (to single test host at HQ), we simply swapped out the default gateways via our DHCP server and nobody was any the wiser.

NAT was a simple process of creating the equivalent rule at HQ. As we only had a few rules it was easier for us to just leave the external address of the ASA and UTM as they were for the build, and just change the external DNS records to point to new UTM address to make it live. We did that way so we didn't have to rebuild Red connections.

I am not sure from what you say if you are using all UTM's or just UTM's at head office, and Red devices at remotes.

HQ 2 x SG310 active/passive. Remotes Sites SG 135. One remote site RED 50 (no local filtering required)

Nick

Thank you Nick for that valuable information feedback!!!

We are planning to implement two Sophos UTM at Head Office as HA pair and Sophos Red at Remote Offices.

If there is spare external IP at HQ but no spare IP at the branches, what issue will we run into?  As we replace the Cisco ASAs with Sophos Reds, other than rerouting traffic on the Cisco ASA to the UTM for the red traffic, do you see anything else that may needed to be changed?

Hello Jimmy,

I agree with Nick, we used approach #1 and every step went without a hitch.

Something I did was to go through my ASA config line by line and create a spreadsheet with all my NAT statements, port-forwarding statements etc. and made sure when I built the UTM configuration I had the equivalent line from the ASA included in the UTM.

As far as the remote offices are concerned, the nature of the RED devices are "plug-n-play" so you should be able to, once configured on the UTM's, be able to plug them into the Internet connection at the remote office, RED contacts the cloud, gets it's config, reboots and connects back to the host UTM. Done.

The key for me was mapping my ASA config to my UTM line by line with the spreadsheet as a guide.

Take care

todd

Hi,

Having the spare ip at HQ is the trick. You can get the UTM up and running first, then when tested deploy the first RED. As Todd just said the RED is basically a plug and play device that gets the config from the cloud, so once in it should just take over the routing (tunnel to HQ) and away you go.

The only issue I originally faced was DHCP on the remote router, so I switched that off, changed router internal LAN to 192.168.11.254, and configured the RED with a static.

Uplink mode: Static (this refers to the RED interface connected to the router)

Address: 192.168.11.252

Remote router (192.168.11.254) (Vigor ADSL)

Netmask /24

Def GW: 192.168.11.254

DNS Server: 192.168.11.254 (RED needs to be able to resolve your UTM hostname to make the connection) suspect you can just use external ip of UTM ?

Switch port config: Switch (so I plug site switches into RED directly)

When you create a RED config you get a new virtual interface on the UTM (reds1, reds2 etc), and this is where you assign the inside (remote LAN) address, so in my case the remote RED interface is 10.1.64.254/24 and all the devices on remote site A are on same subnet.

Again sure there may be other ways to do it, but above worked.

NAT etc. Again as Todd said the trick was to work out how each current rule worked, and create the same rule on the UTM. It took a while to work out how to see ASA verses UTM in the way the rules work, but once you get it there is no problem. I did find that the UTM way of doing things meant in the end I needed a lot less rules that I had on the ASA.

We also use the HQ UTM for email, and RDP, both of which are much simpler in the UTM (Webserver Protection) and allowed us to replace IAS and separate mail gateway / spam filter. 

If you get the chance I would install UTM, configure 1 RED tunnel, then take RED home and have a go (no disruption to work). Once you get the way it works then it really is a 10 min job at each remote site.

Nick

Hi, Jimmy, and welcome to the UTM Community!

You didn't say how many branch office you have nor which SG appliance you're considering.  RED tunnels are resource-intensive.  Your reseller should be able to size correctly for you, so be sure they have skin in the game.

I will usually recommend an SG 115 with Network Protection instead of a RED 50.  Faster, cheaper and more flexible.  For small offices with less than 10 PCs, a RED 15 is a cost-effective solution if you don't need faster throughput.

I agree with the suggestion to use your 1st approach.  When bridging, you cannot do QoS.  I also dislike double-NAT, so if you want to try your 2nd approach, I would recommend using public IPs with no NAT.

Cheers - Bob

Thank you all for the reply!!!  That was really helpful!!!

We decided to try option 2 since we don't have extra public IP address.  We are going to turn off masquerade and just route instead so we don't have to double NAT.  Will filtering and all other functions still work?

We just discovered that the Sophos Red does not support PPPoE connection.   Can someone confirm?  PPPoE for WAN is what we are currently using for the ASA at the branches.