Decommissioning a FG 200D and migrating it to a FG 600E and having issues

[ShawnAshCountry]

I am the Network Engineer for a 7 location Medical Imaging Company here in Leesburg Florida and have been in the position for a year and a half. The issue I am having is decommissioning a FortiGate 200D firewall and migrating it over to a 600E that have both been running in tandem at the same location. An Aruba Switch has static Ip routes going to both Firewalls. I am on attempt 7 to get this done and have had to roll back the configs on the switch and the 600E each time because I keep running into a couple of things that are not working depending on how and what physical connections I move from the old 200D to the new 600E as well as making the necessary route changes in the switch and because we only have a limited time frame to get it done between 4 AM and 6 AM and only on Tues, Wed,  or Thurs, before our doctor/s come into work and/or log into the VPN to read from home. I am also new to FortiGate Firewalls, the majority of my IT career has been working with Cisco Meraki Equipment. Can anyone assist me and if so what info/config/route info do you need to help.

Sincerely,

Shawn Ashcraft

Network Engineer

[Rajan_kohli]

Hi @ShawnAshCountry,

You can use Forticonverter to convert your working FGT 200D config to FGT 600E config and then upload it to the new Fortigate 600E and everything will start working as it was on FGT 200D.

Ref: https://www.fortinet.com/products/next-generation-firewall/forticonverter

Regards

[fadenha]

We don't use the Fortinet default/device certificates, but generate new certs on the FortiGate, signed by our CA certs (from the FortiAuthenticator). Those are used for our IPSec VPN, deep inspection, and some internal auth https://vidmate.bid/  .

[ede_pfau]

If I understand you correctly, you run both firewalls in parallel, and it sounds to me, with differing configs. Every time you try to move the links off the 200D to the 600E, something doesn't match and you have to roll it back.

Apparently, the setup is complex enough to warrant external professional help. The forum can answer detail questions very nicely but there is a limit.

Sadly, I'm not remotely located near FL :) but you can contact your FTNT account manager (who will exists for sure) and ask for competent partners who could help you with this.

FTNTs product for config conversion is FortiConverter service, that is correct. But for one, I don't think you want to replace the 600E config completely, and additionally a human being can convert with much more insight and higher success rate. I'm not a fan of it (but then again, I dont't belong to staff).

[ShawnAshCountry]

Correct ede_pfau :) When the previous Net Engineer added the 600E to that location he kept the main connections, Staff, INET, DMZ, and Wi-Fi on the old 200D and built a 4 port lag (0) interface for our Home Scheduling Staff users, Home Reading Station Radiologists, and RDP VPN connections to run through it using what I believe is a free version of the Forti Client in order to provide secure access to them to the network. The problem is that when I move all 4 connections over to the 600E, everything works with the exception of --- 1. Our PACS VPN's (BWD, SM, LSB - LSB is the location we are doing the migration on) no longer allow the Radiologists connecting to any of the PACS VPNs to be able to access the DMZ connection which is a 192.168.221.2 at the hospital to read exams however the hospital connection does work and is sending and receiving traffic to us. 2. Our IT techs at LSB on a 10.24.17.X and our scheduling department on 10.24.117.X can either access the internet but are not able to connect to Mitel connect client in the cloud when the static route on the 600E is pointed at the 10.250.2250.10 lag (0) interface on the 600E or can connect to the mitel connect client and have network but no internet access when I change the 24.17 and the 24.117.1 staff static route to the interface staff connection of 10.24.117.252. Sorry if I gave too much information just trying to be thorough. My thoughts are that the staff interface does not need to move over to the 600E however the switches main 0.0.0.0/0 static is pointed to the 117.252, the IT subnet 24.117 is pointed to the 117.252 on the same VLAN on that switch, as well as the ips to the dmz hospital connection. There is also a route in the switch that I did not move move over to the 600E Static routes 10.250.250.8 which is the bridge for the 200D and the 600E to go through the lag (0) 250.9 on the switch and 250.10 on the 600E firewall. 

[ShawnAshCountry]

Lastly this last attempt I did not move the Staff interface physical connection 24.117.252 over to the 600E and the only things that were working that time were the 24.117 and 24.17 subnets for IT and staff phones and desktops as well as access to the mitel connect client on the desktop to the cloud. But the hospital DMZ was not TX or RX traffic. Any help or suggestions as to what to try would be much appreciated. FortiConverter will not work and we do have a license for the FortiCOnverter Techs to do the conversion for us and send us the configs but not to the software/app for me to do it myself

[ede_pfau]

You seem to have a couple of different problems when moving.

Above all, don't forget that the FGT is a router AND a firewall. In order to have traffic flowing from one network (e.g. 24.117) to another (e.g. internet) you need at least one static route, and a policy.

So on the 600E, if 24.117 and 24.17 are working in-house but cannot access the internet (Mitel cloud), check first for the default route (which surely will exist) and then test the policy table. There is a button for "policy lookup" where you specify the interfaces and addresses involved, and FortiOS will highlight the first matching policy. I bet that is missing atm.

Second problem is access to the DMZ. Again, route and policy: a route is given as the FGT has got an interface in the DMZ ('directly connected'). What about the policies? You need one per source network (I would recommend against multi-interface policies, for clarity).

Third, you play against a 'hidden device' which is your core switch in L3. I'd strip it of it's routing as a first step. The FG-600E is way powerful enough to do the routing by itself. Be careful when scanning the switch config as not to overlook some forgotten routes. You even do not need the route for the transfer network between the FGTs. Just tell them how to reach each other (= add a static route on each).

Heck, if I'd be in your situation I would consider the following:

you need a 600E for testing. Doing live switchovers under time pressure is not very effective. Best would be if you had a cluster - which you absolutely should have for that kind of network. You could switch off one 600E then, remove it from the network and set it up in your lab. You don't need a second 200D for this. Just set up every network and interface you need, routes, policies, and test away with a notebook. If you think it'll work then put the offline 600E in priority and let it rejoin the cluster (causing an outage ofc). Then remove the 200D.

If you do not have a cluster which you could lobotomize for a while then contact your FTNT representative. He/She should be interested enough to arrange for a demo unit, either from FTNT or a distributor.

And again, this is not an everyday task, given the complexity and impact on services. This warrants to hire external support.

[ShawnAshCountry]

Thank you sir I will get ahold of FTNT and kick it up the chain and I appreciate everyone's feedback and assistance I can usually handle pretty complex networks and routing and not have a problem but how the previous net engineer has this set up has me scratching my head. 

[Debbie_FTNT]

Hey Shawn,

involving a Support Engineer is probably your best bet at this stage, as Ede_Pfau mentioned - your setup is pretty complex, and does have me scratching the head as well. When you open a support ticket, I would recommend including a link to this community thread - it lets the engineer assigned to your case know what you've already tried and discussed.

Cheers,

Debbie