Fortinet: Troubleshoot 5 IPSec Site-to-Site VPN Scenarios - FortiGate

in this video we're going to be going over how we can troubleshoot a fortigate ip6 site-to-site tunnel and we're also going to go over five specific scenarios that may assist you and may be applicable to your uh current use case and if you want more details as to how the firewalls are configured that we're going to be troubleshooting today have a look at the link that's in the video right here so take a moment to take a screenshot of the topology here maybe pop it on another screen and then we can you can follow along while we're troubleshooting and you know just to answer this question ahead of time is you you absolutely do not have to have both firewalls being a fortigate to actually effectively troubleshoot in this case as you'll notice we're going to be focusing mainly on fortigate number two only let's start by going over some of the tools that we have available to us so starting with a an ipsec monitor if we go to dashboard network and let's take a look at our ipsec monitor here we can see where we are at with regards to phase one and phase two for a specific tunnel now if you're on an older version of firmware you'll probably notice that the the same monitor functionality that i just showed it's on the left panel and it's via monitor ipsec monitor another item that we have available is looking at our ipsec log so under login reports events vpn events here we have a list of different log statistics for a specific tunnel so if something's not coming up we can get a bit of you know some clues here so a log is great but then maybe we want to take the next step and actually see what the what the ipsec demon is is actually thinking so if we go uh diag debug application ike minus one that turns on the debug but we need to actually enable the debug fully if we want to see some output and that's where what we would type is diag debug enable so any ipsec events now here we're just going to see them kind of spilling onto the screen so let me go ahead and disable that now and finally we can also use a network packet capture so under network and packet capture we can create various different packet sniffers here to see what's going on so let's say we don't we're not seeing any type of visibility in any of our logs or in the debug that might be a reason why we'll pull open the packet capture another reason might be is okay let's say our whole tunnel is completely established but we still can't communicate between multiple different endpoints that's another good reason to to use the packet capture tool so let's get into some scenarios now all right for scenario one we can see that phase one and phase two are both not up so let's just take that remote gateway 166.166.1.1 which is our remote peer in this case and let's go to network packet capture let's create a new packet capture on our wan one interface okay there we go so we're putting in that remote pier and we should also put in a port port 500 right this is what this is the port that we use to establish phase one so let's start that um and at the same time let's go back to that ipsec tunnel let's manually try and bring it up because that's going to generate traffic at least from this firewall to the destination 166.166.1.1 okay let's try it a couple more times okay there now let's go back to our packet capture here and let's take a look at what we see here right and you know maybe do this for a couple more minutes but this is kind of the idea so we'll stop that capture we'll download it take a look all right so we can see quickly here and and by the way yeah you would need to have wireshark downloaded on your machine so we can see here that traffic is all flowing in one direction so one 166.166.1.2 is trying to talk to 1.1 but not the other way around so the fact that we're not receiving any traffic back from 166.166.1.1 means that you know we would have to go and take a look at the other router or or you know possibly something that's in between 48 2 and 48 1 that could be causing an issue right for scenario 2 let's assume that we have the same symptom but then this this time we are looking at our packet capture and things will be changing so let's start our packet capture same as scenario one we'll go back and we will try and bring up the tunnel again okay so we're you know trying to generate some traffic for our sniffer to have some visibility okay now let's go to network packet capture let's stop the capture and then download it okay so we do see this time we see bi-directional communication so this is great both firewalls are talking to each other so the next step is okay now that we have both firewalls talking to each other um how do we try to at least help ourselves identify where the issue could be well what i would suggest here is to enable diet debug application ike minus one and then diag debug enable right and there may be an equivalent if you're using a different firewall but the idea would be that you want to actually try to bring up the tunnel from the other firewall when you are running a debug on a firewall in question so let's try and do that a few times you know we'll try and bring up the the tunnel from forty gate one and now let's look at the debug on fortigate number two so let's go diag debug disable to stop the output and you know usually it's better to do to look look at this in maybe uh you know a putty session so that you don't run out of buffer space but you know in this case let's just use the gui sniff or the gui cli there we go we can see here that there's a probable pre-shared key mismatch right so you know on 48 number one let's go and let's double check the pre-share key let's just re-enter it in and then let's try it again okay perfect okay so for scenario number three um now we have phase one is up phase two is down so if we were to do a packet capture we would configure a packet capture that would have a filter of same idea same host the port would either be 4500 or we would use protocol 50 for esp um to sniff for phase two but let's assume in this particular case let's try and assume that there isn't actually a network issue that it's just maybe something with our configuration right um so what we can do again is let's go back to the same commands that we used in scenario two right same process let's bring up the tunnel from the other firewall so that we can pretty much generate traffic right it really just generates the logic on 40 gate number two when we try and bring things up on 48 number one same with if it's even a different non-fortinet vendor appliance okay so we can you know we can see here that there's a selector mismatch so pretty much we're indicating that the pier or 48 number one is saying that okay yep the selectors look good for the local the local being this 4848 number two one nine two one six eight one twelve dot zero that's all good remote one nine two one six eight one one one dot zero that's all fine and but then when we look at our selectors we see yes the local is correct one nine two one six eight one twelve dot zero but the remote is incorrect 192.168.113.0 so this 113.0 needs to match this 110 111.0 similar to these two matching up here so in this particular case this was because you know i intentionally changed this for for this this troubleshooting purpose but um let's look at this address here and let's change that selector back to what's correct 111.0 and now the tunnel should come back up let's go to network there we go it immediately came up on its own all right first scenario number four phase one and phase two they're all up and they're all working fine uh now let's try and ping okay our ping is now failing from 48.1 to the 48.2 workstation right now we're on uh 48.2 so let's go to our packet capture section and let's try the approach of just following the packet here okay so first we're going to make sure that we actually receive the packet over the ipsec tunnel all right so we're going to filter for the destination ip and we're going to use protocol 1 for icmp and then let's start the packet capture now let's run those pings again okay all we need is one or two and we'll stop okay when we view the packet capture all we see is the ping request we don't actually see a paying reply so now let's take a look at another interface so we'll create another capture here and we'll look at the internal interface and we'll use the exact same filter right now we're just trying to get the perspective of another interface even though our filter is the exact same okay so let's try again uh actually before sorry okay we've started our capture let's delete this old one so we don't get confused okay interesting so we don't actually we're not seeing any packets incrementing here if we were to stop and download this we can't even download it because there's no packets that have been seen so um you know in this particular case the the reason was because i had the policy disabled so i didn't actually have a policy that would allow the traffic so once i enable that again from the receiving interface to 48.1 and the destination interface internal now the the ping will work again right first scenario number five same symptom as scenario number four phase one phase two is up um but then we cannot ping one nine two one six eight one one two dot two so you know same as before we'll you know run through the packet captures this time let's just put two of them up at the same time right same filter just different perspective based on the interface okay okay there we go so the the capture picked up on that one ping same as before though we're seeing it come in on the ipsec interface but not reaching that you know not egressing the internal interface so what could the issue be well let's look at the policy again okay so interesting this time the policy it's enabled there's no uh typo in any of the subnets or anything like that so what what else could the issue be well we also need to check our static routes and make sure that we have a route back to the source from which the traffic came into to the firewall from right so if i were to enable this interface i'm going to resolve whatever this issue is but you know since we've all made it this far here let's actually try and take you know one little you know dive into the weeds as to how we could actually get that visibility right so right here i'm i'm you know setting up this debug flow for protocol 1 which is icmp and then the address which is or the destination address 168 again 1 1.2 um you know here i'm just saying you can increase this number but i'm just saying show me the debug flow trace for up to 10 packets right you don't want to set this too too large because it does use up resources on the firewall to show this kind of information and then we enable the debug so let's just you know just for just so we don't get too much showing up here let's just go n1 we're just going to be sending one ping and and looking at the traffic output here okay there we go so what's really interesting with this kind of output is it's really the next step after that packet capture that we're looking at the packet capture just shows us does the packet come in is the packet going out it's very valuable but then the next step would be to say okay yeah the packet came in to the firewall here was the source ip here was the destination ip here was the source interface or ipsec tunnel but the problem was that there was a reverse path check fail so pretty much the fortigate since the stateful firewall it's saying well i can't route i can't continue to route the traffic to the destination when i don't even know how to get back to the source from which the traffic came right so even though the traffic did come from 240 gate one uh the fortigate by default is not going to just send the packet back from the interface it received it from it needs to do a routing table lookup and make sure that it it can reach the source again right so that just a bit of detail into how this um diag debug flow um feature works again it is kind of like a sniffer except it shows us the actual logic that the firewall is taking which can help us you know again identify where issues are lying so as always let's just disable it i think we would also go you know stop the float trace here okay and then we will enable that static route now okay and now our ping works so that kind of wraps things up hopefully this was a value i know some of these examples are a little bit of low hanging fruit and you know they go for a bit of the simpler their solutions but you know hopefully this is going to help you be able to begin to start isolating where the problem is and ultimately resolving it so yeah thanks for joining and we'll see you in the next video

Channel: ToThePoint Fortinet

Views: 33,860

Keywords: fortinet, remote work, vpn, work at home, work from home, site to site, ipsec, troubleshooting, fix, error, sniffer, debug, debug flow, diagnose, fortigate, how to, fortigate how to, fortinet how to, vpn how to, vpn troubleshooting, ipsec troubleshooting, ipsec vpn, ttp, ttp fortinet, to the point, topology, configure fortinet, configure fortigate, troubleshoot fortigate, troubleshoot fortinet

Id: 91GznQt2kzg

Length: 16min 1sec (961 seconds)

Published: Sat Jan 29 2022