FortiGate Troubleshooting - Debug Flow with Examples

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
in this video we will go over the troubleshooting tool that the 48 has called the bug flow so usually when we run a debug flow we want to understand why a certain traffic flow is behaving the way that it is or not behaving the way that we expect so maybe we want to have a better understanding of what you know if traffic is matching a certain policy or not or you know if traffic is being added or not netted or how traffic is being routed so really we want to understand the logic process and the fortigate and how it applies to a certain set of traffic so let's go over how the filtering works and then we'll just get right into some examples currently we don't have any filter set okay so now we have the filter set for 8.8.4.4 and protocol 1 so that'll cover our icmp ping test now if you ever do want to clear that filter and start from square one which would be you know this filter above here go die debug flow filter clear now since we have our filter set the next step here would be to go diag debug console timestamp enabled this just puts a timestamp to every single trace that we see and then we'll also type in die debug flow trace start in my case i'm just going to do two so what this pretty much you can kind of think of this command as the the debug flow command will show us two packets and then it's going to stop the output so we could you know a lot of times you might put in something like a hundred or a thousand so that you can see a lot more traffic in this case all i want to do is just see an icmp echo request go out and then see the reply come back so then after that we will type in diag debug enable and then now the debug flow is live so now i'll send a ping out okay so you can see that multiple pings are going out but it only caught the first uh it only actually caught the first ping because again we had the flow trade start set to two so then you can see below here this is actually the icmp echo request and this is the reply okay so starting with the request all of these lines of logic are pretty much are comprising that that echo request that we see so one thing that we'll note is that the trace id is one zero one five nine and these are all the same number for the same packet and then once the reply is received we see one zero one six zero and again all of these lines of output with that same trace id that's really the 40 gauge logic applying to that same packet so we can see the the source ip destination ip source interface we can see that a session that number that gets created this is a unique session serial number we can see information about the route that was found and then the gateway that's used or essentially this is the next hop and then the destination interface and what's great here is we can actually see that the traffic was allowed by policy three and that there's a source that action so pretty much the the source ip112.4 is going to be changed to 166.166.1.2 so going back to that allowed by policy three let's go into the fortigate gui here if we filter and include id so i just right click the top column and scroll over here we can see okay this is the policy that was matched this internet outbound policy okay so back to the debug flow output um you know now if we take a look quickly at the echo reply um you know a lot of this stuff is is occurring in the reverse direction right so 8.8.4.4 is going to be sent to 166.166.1.2 the one ip um received on the one one interface this time we're doing a d nat to find an existing session which has already been matched so it ends with three eight again we can see here three eight is the first session um right because the traffic matches policy three but then traffic in response to the existing session that went out via the echo request um that's going to be allowed back in via the same policy policy three um and then yeah traffic finds a route and then we we send it to the end destination or we're essentially the the source ip um that initiated the initial echo request okay so that was a working example now let's take another example of something that might not be working so um you know let's say now we're trying to do a ping to uh 20.20.20.1 and this is currently not working and the destination is accessible via an ipsec tunnel so we'll just enable our debug flow and then send a ping okay so here we can see that traffic from 112.4 to ip20.20.20.1 from the internal network it was allowed by policy two so we don't have any type of firewall policy issue we're able to find a route via a ipsec tunnel called two main site but then we can see that there was there was no matching ipsec selector so that the traffic was dropped so in this case there was no routing issue no policy issue the the issue happened to be something to do with ipsec and then matching an ip6 selector so now if we were to actually go into that configuration to resolve it we would go to our ipsec tunnel and then we can see here that there's a a phase two selector misconfiguration we don't actually see 20.20.20.1 as any type of destination selector so you know if we were to resolve this on both firewalls essentially i won't get into the exact specifics here but you know going dot 192.168.112.0 and then have you know something like twenty twenty twenty dot zero twenty four is the remote address and doing the the the same in reverse on the other firewall then we would uh we would solve that issue because the traffic would not be dropped on the ipsec selector anymore okay and here's another example of a non-working environment let's say that we've we've ran a debug flow for 192.168.112.4 okay so we're just gonna you know in in this particular scenario someone's trying to ping 192.168.102.4 but then that that traffic is not actually reaching that um that that destination so you know we can run a debug flow uh what i'll do then is i'll you know go on to the machine that can't access 112.4 let's run that ping okay there we go we can stop the ping pretty quickly we can see actually what the issue is here so in this particular case what the firewall is trying to tell us is that there is a reverse path check fail so what this means is that the the source is 192.168.111.9 the destination is 192.168.112.4 the source interface is one two so that's the interface that the 48 receives the this echo request from so you know the the 40 gate is pretty much in this case it's saying i don't actually have a route back to the 192.16 network via the interface that the fortigate received the traffic from which is wan2 right so how we can confirm that in the routing table would be going route get router info routing table we'll go details and then let's put in information about the source which would be 192.168.11.9 we're going to say you know how do we access that source which route in the fortigates routing table do we have to access the the source ip that we receive the traffic from in that case we can see that we were the the route that the 48 actually has is via one one there's actually no route um to this destination via when two so so that's ultimately the reason why the traffic is actually not getting forwarded to the destination okay so let's say that we we wanted to solve that issue and we you know we looked into it and realized okay when two should have actually been the destination interface to reach uh 192.168.111.0 so we would just fix things up okay so we would just fix up the route to actually use the correct destination interface now let's resend that ping and see if it's successful okay so you know as we can see you know now when we run the ping okay we're not getting the um the reverse path check failure anymore uh but we are getting another issue you know we have a denied by forward policy check pretty much we've hit just a basic issue here where even though we've fixed that routing problem um you know we don't actually have a firewall policy to allow this traffic so you know in my case i'm just going to create you know a policy to allow the traffic real quick here okay and then let's let's give it another go okay there we go so now our ping is is successful now okay so that wraps things up hopefully this will give you an idea at least uh on on where to start when you're troubleshooting traffic flow through the 48 firewall a lot of these examples may not apply specifically to you but again hopefully the filtering and a bit of the review as to how the basics are on how to read this output will give you a hand so thanks everyone for for joining in and we'll see you in the next video
Info
Channel: ToThePoint Fortinet
Views: 6,778
Rating: undefined out of 5
Keywords: FortiGate Troubleshooting, Debug Flow, Sniffer, Session, FortiGate, FortiGate how to, Fortinet how to, FortiGate tutorial, Fortinet tutorial, Security, No matching IPsec selector, drop, Allowed by Policy, reverse path check fail, Denied by forward policy check (policy 0)
Id: jOBdIOsGA2g
Channel Id: undefined
Length: 10min 39sec (639 seconds)
Published: Wed Jun 22 2022
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.