Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 6 subscribers
  • Views 11534 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Jimmy Chen1

I have following scenario.

1. Cisco ASA Site to Site VPN between the HQ and the branches

We want to replace the Cisco ASAs with the Sophos UTMs and the Reds and wants know what is the best approach to go about doing this.

There are couple approaches that I am thinking of doing and that I am trying to verify whether it will work
 
  1. Install the Sophos UTMs in parallel with the Cisco ASAs.  On Cisco ASAs, reroute the traffic that needs to go to the Red to the Sophos UTMs.  Slowly migrate the NAT rules from the Cisco ASAs to the UTMs.
  2. Install the Sophos UTMs behind the Cisco ASAs by creating another network between the Cisco ASAs and the Sophos UTMs.  Basically doing double NATTING or routing.
  3. Install the Sophos UTMs behind the Cisco ASAs using transparent/bridge/mixed mode.  What features will not work in this mode?

What are the some of the advantages and disadvantages of these approaches?

What do you guys recommend?

Really appreciate some comments on these.

Thank you!



This thread was automatically locked due to age.
Parents
  • 0

    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

  • 0 in reply to NickYoung

    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?

Reply
  • 0 in reply to NickYoung

    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?

Children
  • 0 in reply to Jimmy Chen1

    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