IPSec VPN Tunnel Between Fortinet FortiGate and Cisco Meraki MX - Configuration and Troubleshooting

hey everyone welcome back to the channel my name is Alex pavlock and I am a systems engineer at Fortinet and today I am joined by my colleague Marcellus uh Marcellus why don't you go ahead and uh introduce yourself hello everybody happy to be here uh I am Marcella Smith I'm also a systems engineer here with Fortinet thanks Marcellus um so today's video um we are going to be covering configuring and ipsec tunnel between a fortigate firewall and an a MX Meraki firewall um we do run into this a lot with our customers um sometimes they are switching over from Meraki to Florida Gates and that's going to be like a slow transition so as they're doing that transition they'll need to build temporary tunnels until they can switch out all of the Florida Gates um sometimes they are just running in hybrid uh firewalls where they're running multiple vendors um so we do see that um a little bit too so we do have a lot of customers that are interested in VPN configurations and setups between Meraki MX firewalls and Fortinet fortigates so we figured this would be a very useful video for everybody um this will be a step-by-step guide on how to configure um an Ike V1 um ipsec tunnel between affordagate and an m i MX device so with that I am going to pass this over to Marcellus who will take us through the Meraki dashboard and the necessary configurations that we'll make on the Meraki dashboard so go ahead Marcellus absolutely so let me go ahead and share my screen awesome so now we're looking at the Cisco Meraki dashboard uh specifically we're looking to create a site to site VPN so the first thing we'll want to do is make sure that this is we go ahead and click hub um and we do want to make sure we have at least one uh subnet that is enabled to uh advertise traffic over that tunnel which we do now we're going to go ahead and add Alex Havelock uh we're going to use his name as the name of the tunnel as well we're also going to select Ike version one and then for I set policies oh wait we have for phase one now this is not for the default we've been ahead and stepped it up rather than the 3des which is going to be for default we wanted it to be a little more secure so we did choose AES 256 uh as well as Sha 256 for our authentication away from the sha-1 default uh diffie-hellman group uh we also moved away from the two group uh moving it to a more secure option for 14. we'll leave lifetime uh seconds the same at 28 800 uh and then for our phase two we turned off PFS group uh we have our lifetime at 28 800 seconds as is the default and we've also left our default authentication and encryption options available once we've done that we want to make sure we put the correct public IP name uh as well as a remote ID including private subnets that we are expecting to be available over this VPN here uh we made sure the pre-shared secret is also the same and then for availability you can select either all networks or there's a specific Network that you want to be able to make use of this tunnel you can select that as well once we've configured dates we can go ahead and save those changes awesome and then from the Meraki side we should be pretty good I'm gonna go ahead and pass it back to Alex so we can look at the Florida gate sign um if you could just scroll uh share your screen back and then just scroll down um to the tunnel config yeah absolutely so um just a couple things here that I did want to note um the remote ID um that started to be checked in MX firmware version 15 and higher so the remote ID has to do with Nat traversal so in our instance right now my fortigate is behind a Nat device and marcellus's MX is also behind an ad device um when the ipsec phase one negotiation is happening and they are going through Nat T they are going to be checking for remote IDs so they exchange hash values and those hash values need to match so the actual public IP address um from my fortigate will be different than the actual hash value of my local um IP address on my fortigate because it's been going through that Nat device so essentially what we're doing there is we're telling what hash values should be sent over when it's going through the NAT T process so that is what the remote ID is really doing there so that ID should be the local IP address of the fortigate if you're going through a net device um in addition to that the private subnet that's going to be my local subnet that I'm going to advertise over to marcellus's MX and then just the availability section of that it's set to all networks so if you had multiple mxs in that environment all of those MX devices will try to reach out and form this tunnel um if you wanted only one of your mxs to form this tunnel rather than all of your mxs then you would just change that availability there um I think that is gonna do it for the Meraki side of the configs now so um I'll go ahead and share my screen and go through the configurations on the Florida gate side so from here we're going to go down to VPN and we are going to use the ipsec wizard um before this video we did test this out to see if the pre-configured uh Cisco will work here the template for Cisco um this did not work um there were a lot of default configurations in here that were um just not compatible so we did figure that this Cisco option is only available for ASAS this is not going to be compatible with Meraki MX devices so in this instance we need to use the custom value here so go ahead and give it a name uh I'm just going to name this gate to MX click next and now this is where we need to to enter in all of our phase one phase two configurations so we are going to be doing it by static IP address there are a couple different options here for Simplicity we're going to be using static IP so go ahead and you would enter in the remote peer public IP address so this is the meraki's uh uh public IP address so the interface that we're going to be reaching out from is going to be the win1 interface um all of these other options I believe we need to disable dead peer detection let me just double check that really quickly yes so um we did get this working before we needed to change around a couple of these configurations um the tunnel did not come up with dead peer detection on so we uh disabled this uh and that is the only thing we need to change on this side we are doing authentication through pre-shared key so go ahead and just enter in the password there which is easy here it's fortinet123 for this video we're going to be doing um Ike version one and Main mode uh the Meraki MX devices do not support aggressive mode uh for ipsec tunnel so we are doing main mode main mode is more secure as well so for those purposes we're doing main mode and then the phase one proposal will just need to match up what we configured on the MX side which was AES 256 and shot 256 and our diffie-hellman group was 14. the key lifetime is 2800 and our local ID we are going to just set that as our uh local IP address so the IP address that's configured on your Wan interface or whatever interface is going to be reaching out and trying to form that tunnel going down to phase two um we need to configure our subnets that we're going to be advertising to the MX and which subnets are going to be advertised to the fortigate so our local address is going to be 2.168. 91.0 24. and our remote range uh sorry subnet is 192.168.5.0 24. it is really important to make sure that those match up um if these don't match up you can have some uh phase two errors come up uh one thing to note too on the Meraki side if you have multiple subnets that are configured on the VPN page so you can see right now we only have one enabled if we do have multiple uh subnets enabled the MX will advertise all of whatever subnets are enabled they will add just advertise all of these subnets so that's one thing to keep in mind um if you're having trouble with the tunnel coming up um try to configure all of the uh subnets that are enabled on the Meraki side going back to the Florida gate [Music] um under the advanced section we do need to edit this just a little bit here from the default values foreign Marcellus what were the phase two I forget yeah so for the phase two encryption we had AES 256. AES 192 AES 128 and 3des as our options and then for our authentication oh well let me know when you're ready um what was the so AES 256 AES 128 AES 192. and 3des uh encryption and then for the authentication we had sha-1 and md5 is this is this for phase two yes for phase two can we make a change there because it's not giving me any of those options so for the all right so for the phase two over there I see you have the 128 I see you have the as256 uh all right and then so I can take off I think we're doing um I just double checked we were doing AES 256 with shot one before okay do we have that yeah I can swap it out okay um technically if I remember correctly uh it's as long as you have matches within for that phase two it'll select the best but just for the Simplicity of it we can go ahead and remove the different options so for right now for AES 256 is the only one for encryption and child one is the only one for authentication uh PFS group is turned off and then our lifetime is going to be the 28 800 seconds okay yeah you can have multiple values configured here and as long as one of the configured values matches up um the essay ipsec essays will uh form for the purposes of our video we're trying to keep it keep it as simple as possible so we're just using one um configuration for phase one and phase two um also a very helpful tip if you're troubleshooting as well so I always keep it as simple as possible when you have that option yeah um the perfect forward secrecy is disabled on the MX side so we are going to get go ahead and disable it from over here from these default options you can leave these uh selected as all and then I have Auto negotiate selected that will make sure that the Florida gate does act as an initiator and try to form the tunnel uh last thing that we need to change is the key lifetime which again was the same as phase one 28 800 seconds and from there we should be able to go ahead and save this um so here's our tunnel here one thing to note when you do configure a custom tunnel in the ipsec Wizard um you do need to make some additional configurations on the uh 40 gate sign you do need to add a firewall policy rules to for the tunnel and then you also do need to add um routes for the uh ipsec tunnel if you are able to use the wizard and use one of these default uh configurations that we have here um it will auto create those for you but since we have to use custom we'll need to do that so also a good uh something to learn here um which we do run into a lot of customers asking how you configure VPN rules for tunnels because uh the mxi like you can only do inbound rules so um or I believe it's outbound rules that you can configure on the Meraki side yeah you can get inbound rules you do have to reach out to their customer support to have them enable that for you um so yeah I'm me I'm excited it's going to be just outbound firewall rules so the uh the fortigate side we can do inbound and outbound um just one difference between the 40 Gates a little plug for the 40 gate there um so let's move over to firewall policy and we'll go ahead and create new so we'll give it a name we'll give it the name uh gate to MX and then for the incoming interface we are going to select the interface for this is my inner this will be whatever interface that your subnet is attached to that we're advertising so we're using the user subnet here our outgoing interface is going to be the interface um for the IPS external which is also called gate to MX and then for the purposes of this this video we're keeping this as simple as possible so for source and destination I'm just going to select all but you it is advised that you would only allow whatever subnets or certain IP addresses that you actually want to be able to communicate over this tunnel but again for Simplicity we're just going to select all here and then service we're just going to select all as well um typically for an ipsec tunnel we really don't want to be nadding traffic going over the tunnel so we're going to go ahead and disable that function here and then we're leaving all the security groups off so we're not doing any type of uh packet inspection over here again just for Simplicity but it would be advised to be doing some type of traffic inspection over this tunnel so you can configure your different profiles here but we're going to leave these blank for now so we're going to go ahead and enable this policy and then we need to create a second policy uh just doing the reverse of the first one so we we're allowing traffic here from the Florida gate side to go to the MX we now need to configure for the MX side to go to the 40 gate sign again disable Nat for this and click ok so our firewall policy rules are now configured um so that's how you would configure firewall rules for ipsec tunnels it's very easy you're basically just selecting those tunnel interfaces and that's all you all you really need to do to configure firewall rules for uh an ipsec tunnel next thing that we're going to need to do is come under Network and then static routes we are going to add a static route to point traffic going to uh marcellus's subnet over the ipsec tunnel foreign once we select the interface the gateway address will go away it's just going to use the tunnel so let's go ahead and select that Advanced options we can just keep that the same so go ahead and click ok and now we have our static route configured so from here um one other thing to note the MX devices um as of 15 firmware um that I know of it might still be the same I'm not sure up to this point I believe they're on 18 firmware but once since I uh left Meraki um the MX devices do not act as an initiator for ipsec tunnels they're just in passive mode so they'll be listening for the ipsec tunnel but we wanna um have both sides just act as an initiator here so what you can do is from the Meraki dashboard from the MX page if we just come up come under here and just try to initiate what is called interesting traffic so traffic that would be routed over the appisec tunnel we generate that traffic and then it will try to form that tunnel so let's go ahead and just restart these pings here and now if we go under login report and then system events and we go under VPN events this is where we're going to be checking the logs to to check on the status of our tunnel um so if you do have a 40 analyzer just change it to memory so we're getting the most up-to-date um logs here and it does look like we are running into some Phase One issues here so this is really useful for troubleshooting and let me look I think I actually see that issue where I believe when I put the private subnet for your side I put the wrong uh Subnet in uh let me make that change right now so I actually put your private subnet as the 91.0 so the actual subnet versus like the specific uh I'm sorry yeah so the it should be 192.168.91.0 24. that's what I'm advertising to the MX and I just changed that and then we can double check I'll also check on the um VPN status as well um just for some troubleshooting tips here as well if we come under ipsec tunnel you can monitor uh the status of the tunnel so we can see that it's currently down if you do click on here and click show matching logs it will take you directly to the log page where it will give you all logs pertaining to uh the progress of this tunnel um I would advise to take out this because sometimes if you don't get far enough along where it's able to even associate these negotiation attempts to a configured tunnel um if you have that filter in there it won't show you so I would advise to just keep this blank and some other uh troubleshooting things you can do I have a dashboard created for an ipsec monitor so if you click the plus button you can just add a specific ipsec monitor which gives you information pertaining to your ipsec tunnels uh from this monitor uh you can see the how much traffic is going over that tunnel you can see what phase two selectors are up or down and then you can bring tunnels up or down directly from here as well so another good troubleshooting tip good so let's just go ahead and go back through our configurations and make sure that we have everything set up correctly here this shouldn't matter but um when we did have this up before I was using IP range so I'm gonna I'm gonna change that to IP range it shouldn't matter but um I'm gonna go ahead and configure that anyways yeah this shouldn't matter because we're we're failing at Phase One and this is phase two anyways but um I just do want to match these up foreign can you confirm the phase one selectors yes so for encryption we have AES 256 for authentication we have shot 256 and our diffie-hellman group is 14. and then we have 28 800 seconds yes okay and you just double check that the password is Fortinet one uh one two three yeah I'm changing I'm checking right yeah well actually it won't let me see what the password is so I'll just re-put it in for the net one two three and I'll click save foreign just a just a general troubleshooting tip here as well um when we are when you are going through and troubleshooting something like this it's advised that you'd make one change at a time and then test again instead of making multiple changes and then testing um just something you learn along the way so you can identify like what in particular uh was the issue there because if you change multiple things and then it comes up you can't really identify which one of those things was the issue so just make one change at a time here and then um test test again so we did make a change there so let's just come back and see where we are I'm gonna go ahead and re-initiate these pings from the from the MX so if we double click on this log here it will give us some information here so it moved to Port 4 500 so ipsec tunnels will start on UDP Port 500 and then once they determine that they're behind a Nat uh it would automatically move to Port 4500 so we know that we're at least detecting that there is not a Nat present uh and we're moving to 4 500. um another troubleshooting tip um on the Meraki side of things if you come under Network wide and then packet capture um we can take uh some packet captures uh on the Meraki side of things um so you would just come to network wide packet capture um on the interface you would keep it as Internet download is a DOT pcapp um it's just easier to use filters and such if we do it as a download and then open it directly in Wireshark um you can generally generally leave these blank um or you can put in like the host name which would be my um public IP address coming from my fortigate uh but we'll go ahead and just leave that blank uh Marcellus if you don't mind taking it packet capture yeah absolutely um and then you can also check check some logs on the Meraki side as well if you come into Network wide event log and then under the event make sure it's set to security Appliance and then just type in VPN and we'll be doing um all non-maraki VPN and then just make sure your time is set correctly Meraki logs not throwing any not Meraki logs are not the best um I think it's well known throughout the industry Meraki logs aren't necessarily the most reliable so in terms of logging I'll be leaning more so on the fortigate side of things here let's go ahead and refresh this see if we made any progress here still looks like we're failing at Phase One um let's go ahead and adjust those um uh remote ID values um because that's going to be negotiated at phase one uh let's see here I'm going to I'm going to remove it from my side where I configured it um we'll leave it on the Meraki side for now we'll go ahead and restart pings and see where we're at and Marcellus do you remember if we had the remote ID configured on the Meraki side um when we had this we did yeah you did yeah I want to say that was what got us past the uh hash because that was uh we were having issues with the hash then we had to add that uh remote ID um yeah now the only change we've made is for phase two which shouldn't have any impact on what we're seeing through phase one okay so we did get past phase two so the 192.168.230.6 that is already the IP address that's configured on my MX so there's really no need to configure a local ID as long as you have that configured on the Meraki side of things um when we did that have this up before I did not have that configured so it's sort of like a duplicate configuration if you will um so I did remove that we are past phase one now it looks like we are failing on phase two so let's go ahead and start double checking configurations from phase two and let's see if these logs give us any uh indications here in fact there was a negotiation error now on phase two of the Meraki we have AES 256 and sha-1 with AFS group turned off lifetime is at 28 800 seconds um prior when we had it up before on phase two I had all of the default options open so AES 256 192 and 128 as well as 3D yes and then authentication and selling options for shot 66 and for md5 as well but for right now we just have an AES 256 for encryption on phase two and shot one for the Authentication um do we want to check um change the IPS back to the IP subnets because for the private subnet we're expecting looks like this side is only because for the whole subnet not for a range it looks like the tunnel's up on my side actually um sometimes they do like kind of take a second after you make some configuration changes definitely give it time but it does look like this tunnel is up um you can see from the uh ipsec monitor here that it is turned to green and we can see some traffic going over the tunnel if we come back down to VPN ipsec tunnel it does show as green um on the Meraki side um yeah it's showing is up on the Meraki side as well and um um just share your screen really quickly and and show where you're seeing it there all right absolutely so uh for the Meraki side a couple things we can you can go to your Appliance status page and you can actually ping uh an inside IP address which we've done so we do see traffic is passing through that's going to be the that's going to be the IP address the local IP on my fortigate so that is my user interface IP address so that's the landside IP of my 40 gate yeah and it could also be really any internal with which is within that internal subnet hosted on Alex's side uh so yes in this case we are hitting the internal interface of the for the gate we are getting response traffic another option to verify connectivity is we can actually go to the VPN status page and when we go to our we can see that we do have a connected status there as well awesome thank you for showing that um the based on our experience uh I would say the most reliable thing to test to see if a tunnel is up or not is just to do a direct ping to an IP address that lives across the tunnel that's the most reliable way to tell if the tunnel's up or down rather than just seeing if it's green or not um I do know I'm not sure it's been about a year and a half since uh I was at Meraki but one of the things in the Meraki dashboard is that green icon for non-maraki Piers um that was it would turn green if phase one was up yeah so that that green status is for phase one only so it can be tricky it can technically have a green status and not be working on phase two yeah so it'll show you green you think the tunnel's up and good uh but really that's only phase one is up in phase two it's failing at phase two so this can be a little bit misleading so uh best practice I would say is to just try pinging an IP address that actually lives across that tunnel uh from there um so we basically showed you some basic troubleshooting steps uh try pinging across the tunnel uh within the Meraki dashboard you can go Network wide packet capture uh within Wireshark if you open up a capture so I'll just do one really quickly here and just show you what you can do within Wireshark um so we're gonna do for appliance I'll take this really quickly here while that's going uh so you have that pcap uh going here and then if you go to network wide event log uh and then search in your event log on the Meraki side for all non-rocky client VPN um that should show you some logs for your non-rocky peers uh from the fortigate side of things um it's really useful to use the ipsec monitor uh and just use the green arrow see if it's up or down um also using the clicking it showing show match logs this will show you um all logs pertaining to this tunnel like I said before I generally keep this with no filters on it um you can also take packet captures from the 40 gate side of things if we come under Network I believe and come under Diagnostics we can take packet captures from the fortigate side of things just select win one and then you can set a packet capture filter or filters for the capture in general um just as a oh just as a general rule of thumb in terms of troubleshooting um I I typically do recommend not utilizing filters when you're initially starting with packet captures because you don't want to accidentally Miss relevant traffic rather take the capture then utilize filters to break it down and then moving forward then you can start using filters once you've verified from the initial captures that you've at least captured the relevant traffic and then you can uh pre-filter as well there are concerns it captures uh that's why you don't run to run too long take up too many resources but especially if you're looking at like a minute or so um you're going to delete them afterwards then yeah I typically recommend leaving the filters off filter the full capture and then if necessary take additional captures pre-filtered if you're looking to capture a lot of traffic and you specifically know what you're looking for that's a great Point um and we did do this uh in our in our Tech days as well um definitely advise that uh one filter that you can use in that packet capture from the Meraki side is just filtering this for traffic coming from my Florida Gates public IP address so that would be ip.add R equals equals uh and then my uh actually this should be my public IP foreign which you can get from the dashboard and then status and then you should see wayne IP right here let's go ahead and enter that in so here you can this is filtering traffic uh for just my IP address um so you can start from there see if you're actually getting traffic from that IP address or Not Another filter you can use is filtering it for the port numbers that ipsec tunnels use um if they're not using if they're not going any type of a Nat uh traversal it'll be using Port 500 uh if you're over going over a Nat device it will enable Nat T and then it would switch over to Port 4500 so you can see that you could filter it by port number as well so it's just some good troubleshooting tips there um yeah one more not to interrupt you that's also very helpful if you're specifically talking about vpns you can filter by Ice account or ESP as well if you just want to see uh specifically the negotiation of the VPN which would be held under isocamp and then if you're seeing ESP traffic that means that that is encapsulated so that's that encapsulated secure security payload uh so that's also an additional uh if you want to specifically for troubleshooting VPN as well yes thank you um so I just sort of want to wrap up again what we did here uh go through the configurations that we used uh everything from the rocky side and the 40 gate side just go through that very quickly um and just to highlight that these are not these configurations are not going to be guaranteed for every scenario um you might not be behind um a Nat device um one side might be behind a net and the other is not in this particular scenario both of these MX and 48 devices are both behind Nat devices so if you do run into this scenario and these these match up um using our configurations and copying this should work for you but I just want to highlight that these configurations might not work for every scenario every scenario scenario might be different um and this was for Ike V1 in general um it's advised to use IQ two it is a lot more secure and simpler in the way that it negotiates tunnels so it is advised to use like V2 but it is still pretty common for for businesses to use Ike V1 so that's what we did for this video so um to just sort of wrap things up here I just want to go back through again and show you the configurations that we use for this tunnel um ourselves if you don't mind just going through the Meraki side very quickly again and show us what configurations that are used and I'll I'll switch back over here yeah absolutely so on the Meraki side so from the site to site VPN page we did turn this on as a hub uh from my previous time working at Meraki if I remember correctly if you're doing a non-maraki device to a Meraki device for VPN uh you'll need to have it as a hub on the Meraki site you can't connect it as a spoke to a non-maraki hub so we did select that as a hub uh we did make sure that we have at least one uh subnet being enabled to uh communicate or advertise over that VPN tunnel uh we've gone ahead and we selected Ike version one for our uh tunnel type for our configurations for phase one we're utilizing AES 256 with sha-256 as our authentication diffie-helming Route 14 and 28 800 second lifetime uh phase two we're using AES 256 uh at for encryption and shot one is our authentication with PFS group turn to off and also having a 28 800 second lifetime uh local ID is off by default right version one I can't configure that remote ID this is going to be the local ID of your remote peer um typically you'll see that as an internal interface uh some vendors do let you configure that for email address or another uh another uh value so you do want to make sure that you know what it is set up for uh on that Remote device and put that there uh we're then including what private subnets we expect to be advertised from that remote peer our pre-shared secret and which networks we want this VPN to be available on in this case we've selected for all Networks um just to confirm uh when I say all networks I am talking about all my Rocky networks so if you have multiple Meraki sites and you only want certain sites or certain networks to be able to utilize this VPN since VPN is an organization-wide setting here's where you would set that up uh so uh pretty uh clear into the points along the rocky side that's really about all you need awesome thank you and then if you did want to set up firewall rules it's right underneath that GUI interface it says outbound firewall rule so you can configure those um if you wanted to on the rocky side um so I'll go ahead and quickly go through the fortigate sign so under VPN and then ipsec tunnels um this is the one that we're working with um so in the ipsec Wizard you will need to select custom um for we are doing it by static IP address you could be doing it by fqdn uh but for it's typically going to be a static IP address uh enter in the remote public IP and then what interface of the 40 gate that we should be reaching out to on uh the the interfaces um the only default value um that we did need to change from here is going to be the uh dpd or dead peer detection um this isn't something that's typically negotiated in in any of the phases um it's not part of like the negotiations where it would prevent a tunnel from coming up or not I just know that in my experience with Tac um there were some times where it did cause issues with tunnels coming up so that's one thing that I did change that enabled this tunnel to come up is disabling dead pure detection so just go ahead and disable that um and then coming down to authentication pre-shared key enter in uh the pre-share key value Ike version one using main mode aggressive mode is not even supported on the rocky side so uh just main main mode um aggressive mode is only used for client VPN um if you're connecting from the one of the Native uh with like Windows um for just client VPN stuff so but for ipsec tunnels uh for site to site just main mode coming down to phase one proposal uh we kept this simple and just used uh the singular values um you can have multiple values configured here and as long as one of them match up the tunnel should form but for to make things easier we're just using one value and it was AES 256 with shot 256 Diffie helmet group 14 key lifetime 28 800 seconds leave the local ID blank on this side um the value on my Wan IP is 192.168.230.6 so that already matches up to what we configured on the Meraki side um ex-off um is not something that we need to configure here um and then our phase two selectors um just select the remote IP address or the uh local IP address that we're going to be advertising to the Meraki sign and then the subnet that is being advertised to us from the Meraki side um again if you have multiple values enabled on the Meraki side you might need to add all of those IP addresses in here whether you're actually going to use them over the tunnel or not um just something to be aware of I wouldn't configure those all by default just if you're running to any issues just something to troubleshoot with um and then we used IP range here on my side and just entered in the ranges that we're advertising and receiving and then under the advanced for phase two we used AES 256 for encryption sha-1 for authentication uh turn off uh PFS or perfect for secrecy and then enable auto negotiates and change the lifetime seconds to match up which is 28 800 seconds um and that is actually um the other two things that you're going to need to configure using custom were the firewall rule policies again you just come to fire roller policy click create new and then use the interfaces for the tunnel and then the internal interfaces that are going to be communicating over this tunnel so gate to MX um and then my user interface which you can see is that 192.168.91 uh IP range and then you'll need to make a vice versa rule uh so two firewall rule policies in here and then just adding the routes for the tunnel under static routes uh so one and two 168.5.0 um and the interface going over that tunnel so um that is going to do it for for this I hope this was was helpful for everybody um we do run into this a lot so I did want to create this video to just try to help everybody out there I want to thank Marcellus for hopping on with me thanks for the invite I had a lot of fun yeah this is good um did requires a lot a lot of troubleshooting but I'm glad that we were able to run into some of those issues too so you got to see our live troubleshooting as well um so we went through we configured uh an Ike V1 ipsec tunnel between fortigate and an MX device show you how to configure firewall rules for communication over an ipsec tunnel and adding static routes for that and with that that is going to wrap up the video um like always if you do need any help um shoot a like in for the video comment um I'm glad to help um if you do run into any issues and smash that subscribe button thanks everybody take care have a great one bye

Channel: Alex Pavlock

Views: 3,946

Keywords: Fortinet, FortiGate, Cisco Meraki MX, Meraki MX, MX, IPSEC, IPSec, VPN tunnel, troubleshooting, VPN, site to site, site to site vpn

Id: SOYr9bY3e44

Length: 51min 1sec (3061 seconds)

Published: Thu Sep 07 2023