Troubleshooting Packet Flows (Episode 26) Learning Happy Hour

hello welcome back to learning happy hour today we're gonna once again do two of our favorite things we're gonna have some fun and we're going to have a very informative deep dive session so Mitch what are we gonna talk about today so today we're gonna focus on two things related to troubleshooting that a lot of people want to know more about and that first thing is flow logic what the firewall does is it receives traffic thinks about that traffic processes that traffic and then sends it on its way and then we're gonna do a packet diagnostic capture to analyze that exact same process on a packet per packet basis this can be really illuminating for us to understand why the firewalls doing what it's doing when things are working as you expect or more importantly when things aren't working as you expect that's great so what we're really gonna be doing is we're gonna be kind of following the packet through the firewall kind of like Magic School Bus right we're gonna kind of see what happens inside and we're gonna take a trip just like you're on a trip right now where are you broadcasting from well I am on assignment this week in Bengaluru India or Bangalore if we use the old name and it's one of my favorite cities in the entire world it's uh well I got some footage we'll show you so I think you guys are gonna like it I'm looking forward to that this is going to be a great episode let's do it [Music] I've never seen it like it even related the magics you don't know the magic school that's all about no they go on school trips and then this the school bus shrinks and like goes inside the human body and like travels around through the nose and the heart and different parts of the body so that's like what you're gonna be doing with this flow logic thing right you're gonna be locking us through what happens inside the firewall yeah we're gonna be down to miniature size like the movie inner space you know 1980s awesomeness yes exactly just like inner space all right well what's the first thing we're going to talk about that what it let's get started with this so here's we're gonna talk about today Jason and the main point is to understand how traffic flows through the firewall but more importantly what to do when the traffic does not flow like you expect so and that's important point I don't jump in and mention that the reason why people want to pay attention to this and what they'll get out of this conversation is I'll have a better understanding of how the firewall works for the sake of troubleshooting and also for you know understanding how the rules actually process the traffic because if you've ever tried to troubleshoot the network you know how important the OSI model is well these things that you're going to be looking at here those are just as important when it comes to understanding how traffic flows through the firewall and troubleshooting that yeah that's a great analogy I mean the flow logic is like an OSI model reference that you can use to kind of understand how things work that's great so for this discussion we're going to be pulling information from three documentation sources the first one is a document we call day in the life of a packet you can look for it on google or our live community site or down on the show description I'll have a link to it it's always known are also known as document 1628 and it's a very illuminating document that shows you how in great detail the firewall processes traffic at each stage all legs are called the dill yeah LP he's not ready for that yes pulling from the edu 3:30 course which is a three-day troubleshooting course and and Jason you have an affinity for this course what is it I love this course um one of the great things about this course is it's three days of troubleshooting so and really what we're going to be doing here is giving folks a great primer where we kind of expand on that in this course so if you like what we're gonna be talking about today and you want to learn more about the tools utilities and specific kind of troubleshooting cases this course is a great course and it's also great because you can reference back to it later on so a lot of the great stuff in this class yeah one thing if I'm a plug on that the the courseware developer for the 3:30 course he he spent so much time with our engineers and our TAC folks and he's built a student guide that's literally that thick and it's an amazing shelf reference that goes into so much detail I even though I'd been at politie networks for several years I learned so much when I took that course for the first time it's a fantastic course agreed in addition to these two documents we're going to be pulling from our support guide the knowledge base top Palo Alto Networks comm and we're gonna be focusing specifically on one of the diagnostic captures that we call a float basic again link down in the description so at a high level I want to introduce you to the various processing stages in the pilot the network's firewall the first is your ingress stage where you go through packet processing defragmentation and any kind of VPN termination or decapsulation next we're gonna get into the session setup phase which is often referred to as slow path and when we get into the actual captures you'll see that term slow path used and this is where the firewall does you know forwarding lookups and determines destination zones and employs some flood thresholds for like syn floods UDP floods things like that so session setup is a very important step after that we get into we call fast path or the security processing step and you'll see us refer to this is either fast path or the inspection and enforcement stage and this is really where the rubber meets the road for most types of traffic this is the the rest of the session and then we get into the egress phase where we do any kind of QoS egress shaping reef Ragman tation if we're gonna drop the traffic onto a link with a lower MTU and if this is gonna go across the VPN tunnel IPSec or SSL wery encapsulate or encapsulate for the first time and then send it on its way and then one thing we won't be talking about in great detail here is a concept called session offload sometimes refer to as Hardware offload and this is where the firewall can take certain kinds of traffic that's not subject to application shift or we can't inspect inside for various types of threats and we'll send it off through the network processor inside of your data plane as a kind of a cut through fast processing it's important to understand that that is a feature within the firewall so when you do some of these diagnostic captures you may want to turn that feature off so that the traffic goes through the full series of processes for the entire session but that would only be temporary because that session offload is an important performance enhancement right it's an efficiency feature and this is also only for our Hardware versions of the firewall yes something we would only muss around with during a troubleshooting exercise actually it's required only if it's necessary yeah exactly okay so before we get into the actual nitty-gritty I want to give you an analogy for the slide I'm gonna show you in a second and so since I'm in Bangalore this is very near and dear and relevant recent to me this analogy is about international travel so let's say you want to come to India like I'm here now you need to first check and see if you have any travel plans and if you do not have any travel plans well that's when you would go through the travel setup process with your travel agent or your favorite website and we would figure out what your departure Airport is they would ask you know are you on a no-fly list or you somehow unable to travel and then would check the route that you would take and you would pick you know how many connections I want how long my layover is and then you've got your arrival Airport your destination and then the the airline needs to validate that you're capable of going to that destination so they would validate that your passport is valid that you do or do not have a visa depending on where you're going and then once you've gone through all that initial processing stuff then they can issue your boarding pass and then you can head off to the airport so now that your travel plans exist we're going to go through the pre-flight processing at the airport and the first thing we all encounter is inspection right so they're gonna check to make sure you have a boarding pass otherwise bye-bye birdie and then they're gonna do a body scan or metal detector check to make sure you don't have any dangerous items on you now as a part of that scan they're gonna see if there any risks were found and we're gonna see what happens in either case so let's say a risk was found they'll check to see if they can remove that risk and if they can remove that risk you go back through scan to make sure there aren't any other risks they didn't catch if there are no risks or if they cannot remove that we get to the enforcement stage where a TSA agent and this is a TSA is the Transportation Security Administration that we use in the United States but almost every country has their own flavor of their their customs and enforcement what the Border Patrol stuff and those folks or possibly law enforcement would take action based on the results of the scan the inspection stage and then action maybe let you go on and take your trip where the action may be something more severe so obviously you made it all the way to India so this is a you went through this flow without any problem what I did yes thankfully I'm yeah let me know fly list I don't travel with risks so yeah I got here just fine so let's talk about how this traffic goes through Apollo the network's firewall traffic comes in firewall this we call a flow key lookup and this is a hash taken of the source IP source port destination an IP destination port ingress interface and that information is all hashed together and compared to what we call the flow lookup table and if that hash is not found in the flow lookup table the firewall says this must be the first packet of a brand-new session and so we'll send that traffic through the session setup process so we don't have a flow lookup we'll go then and infer what the source zone is based on the Association it has to the ingress interface and then we imply or sorry apply any zone protection profile thresholds for floods reconnaissance or denial of service protection thresholds for floods and session exhaustion after that we do our forwarding lookup this may be a routing decision if the traffic's coming in on layer 3 interfaces or if it's coming in through a layer 2 or the wire interface we do a look-up on those tables and then decide where this traffic will egress from aka egress interface which must be associated with an egress zone now one last thing I want to mention in the forwarding lookup step this is where we can also do a check for any policy based forwarding rules where you can take action and override the default forwarding logic by the virtual router or or the other types of forwarding logic mechanisms great in the destination zone will also do a check to see if this traffic will be network address translated at all and this will affect how traffic will later be compared to the security policy and maybe you've heard the term as you've been prepping for your PC NSC test the the statement posts in that destination zone pre NAT everything else this is kind of where that begins to matter the firewall says what's the true destination zone of this traffic after it will be NAT 'add and that destination zone is what we would put into our security policy rules that every other security policy aspect would match on the pre NAT values of that traffic and the reason for this I think is and this is one of the things I like to point out to students is is because we're checking this because of the very next step we need to know what that destination zone is because we're going to do a security policy check and I think there's a really interesting niche that we're doing this but we haven't done actually any application labeling or inspection so what's the deal with this policy check during sessions setup that's a good question so just like we have the zone and das protections very early on in the session to prevent floods and stuff like that I call this pre session enforcement this security policy check that you see here is done to make sure that the traffic is on an authorized destination port or that it's not coming from a blocked source IP or going to a blocked destination IP this is what we call a 5-tuple check things like protocol source IP destination IP source port destination port we check those five things at this very early stage and this is an efficiency process so that we don't go down into the inspection and enforcement stage and burden the firewall looking at things that we could have easily thrown away on the very first packet of a session all right so that I've got a great example of this to them because when we go to create policy rules that block traffic based on IP addresses particularly if we want to use the built in Palo Alto Networks malicious IPS or we're going to create our own external dynamic list we're feeding the firewall this list of bad IPs this is where that deny rule would actually be enforced because we are doing it against a list of known IP addresses you've already done the intelligence right we already know that the seas are bad sources let's block this traffic and from for an efficiency purpose or an efficiency perspective we want to block it as early as possible as soon as we have that information we don't need to do application inspection because we know it's coming from a bad idea is that a good place to talk to mention that here yeah absolutely right and one symptom that you can use to know when traffic is denied in session set up versus down in the inspection enforcement stage is if you look in your traffic log the application column your application labels if it ever says not applicable that's your indicator that this session was killed during session set up for a various number of reasons as we said destination ports or sport are sorry source IP destination IP that would be denied in your security policy and I really like the fact that you brought up the malicious IPS the high-risk IPs and then even the bulletproof IP s these are ones that we encourage everyone to consider adding to your block list and the difference between them the known malicious we as peloton networks are confident these are bad IPs the high-risk ones however we have been told they're bad by other members of the cyber threat Alliance which we are a member of and then the bulletproof IPs these are ones that are often used by malicious actors because their ISP has said we won't block you no matter what you do so the risk is pretty high with the high risk and the bulletproof IPs but I don't know why you would never block the known malicious that's an easy button you can press they are bad we know they're bad it's easy to block them so why not do it perfect all right after we go through all of that we assign a session ID and then we move down to the inspection and enforcement process this is and that's of course assuming that it's passed right we didn't block it if it passed the security policy check at this stage then we know we're going to actually install a session yeah great point because at any one of these steps we could throw the traffic away and it does not progress any further through the flow logic now down in the inspection and enforcement stage also known as fast path you got your first inspection step where we'll do deep packet inspection the signature match processor will identify what the application is and it will identify what any kind of content and when we say content we mean like threats or brute force attacks or things like that maybe URLs that you do not want and I have a fun analogy about the difference between these two processes being in a foreign country right now you ask yourself are you able to identify when you hear someone speaking to someone else in a different language a language that is not your native language and if even though it's not your native language are you able to identify what the language is they're using and to be honest I'm getting pretty good at identifying when people are speaking in Tamil versus Hindi and you know other ones like German Spanish yeah those are those are pretty easy even though I can speak those languages yeah I can tell the difference for you know between Spanish and French and maybe German but I wouldn't be able to do much more than that yeah it's it's kind of the the word inflection and especially when I was in Chennai earlier last year it became very apparent when I was hearing Tamil versus Hindi and being here in frenetic estate you know it's kind of between you know Chennai and other parts of the country and you get a good mix here so it's kind of month to be able to identify different languages while you're on travel and so that's like app ID right app ID is able to say the difference between say HTTP traffic and BitTorrent traffic right that's the ideas that's your analogy exactly right versus Content ID does require that you have some capabilities to understand the language being spoken so when you listen in on a foreign language and you're listening to you know each word that's being said and the context of the conversation you know picking up you know subtle inferences and whatnot listening for threat speech that is very analogous to Content ID and as you look at our data sheets you'll see that app ID has one throughput and content or threat throughput is about half of that because it's much more intensive and and labor 'some for the firewall to listen in to that conversation versus just identify what the language is it's like invoking a translator I like that I like that analogy that's good thank you thank you all right so after we do that inspection there's one check that the firewall to do will do to see if this traffic is either SSH or SSL encrypted and if it is it will do a check to see do you have a decryption policy rule and if you do have one of those rules and it matches this traffic we will do decryption in the inspection and enforcement stage and then we'll send the traffic back through inspection again because as we all know the difference between HTTP and H ts is the s and that stands for SSL or secure when you take off that encryption the S is gone and the firewall needs to re-inspect it to see what was really inside and so you'll see traffic go through its first path as SSL and then you'll see another entry where it now says its web browsing for example now that we can see what's inside and then we have to inspect it for threats again then we get to the enforcement step and this is gonna be done based on the way you've written your security policy and any applied security profiles and if the traffic is allowed by either the security policy and the security profiles then it would be allowed to go out if the traffic was denied by the security policy or denied by one of the security profiles it would be dropped or take some other action based on the way you've configured the firewall perfect so just to reiterate here the security policy and the security profiles that's the enforcement portion of the rule so this would be if we had a file blocking profile that had a rule in it that said we're going to block executables and that's what Content ID detected was that there was an exe in that traffic then we would have our enforcement stage much like your your analogy of going through the airport if somebody had you know something a large container with too much liquid in it or something else that was kind of suspicious it would be at this stage where they would be you know tackled and that removed from the premises or a missile launcher in your checked bag as I read on the news somebody just did like earlier to remember to leave mine at home alright so let's talk about doing a diagnostic capture now before we talk about the actual capture steps we need to first put out a PSA public service announcement what you're about to do is going to be very intense for the firewall so never do a packet diagnostic capture without first creating a capture filter you can do this in the firewall CLI or you can do it up here in the web UI just on the monitor tab under packet capture create one of these capture filters as you see I'm doing here in my scenario I've created for capture filters the first one is from my DNS server out to the open Internet and you can see its destination port 53 and the protocol is 17 which if you do a lookup is for UDP traffic and then I've got a second filter for the inverse direction of traffic so I can capture the responses and then just for completeness of the scenario I've added two more filters that are using protocol 6 this is TCP but every other aspect is the same between 1 & 2 & 3 & 4 great alright so now just a quick reminder what we're about to show you is a flow basic diagnostic capture and it comes from our knowledge base the URL you see on your screen also linked down in this show description and you can follow this guide it gives you every command and it gives you some great context for what you're doing why you're doing it and what you should expect to see as a result this is a great article and I refer to it just about every time I'm doing a flow basic and when I'm demonstrating this so this is a good one too when you're done with this video in our time here go check it out and spend a little bit of time looking through it and bookmarking is part of your your troubleshooting tools for the firewall exactly right so shooting troubleshooting resources I should say there you go yeah your guides Sherpas all that your Sherpas yes so what I'm going to show you now is a quick demo and the first thing I'm going to do is validate that my filters are in place and that my login capture is turned off here you can see the command is you and right now you see my filters and there is no log feature turned on next I'm gonna set my log feature and I want to show you the different options that are available to you so we're gonna focus on a flow capture but there are many other capture types that can be done also different levels of information can be shown I'm going to focus on the basic now that I've set the flow logic or the flow feature to basic I'd do a quick check to make sure that it is enabled and you can see down there under features basic is selected so now we're going to go turn the logging feature on I noticed you got the filters up there listed as well the packet capture filters yes I created them earlier in the web UI now my log feature is running now go generate your traffic and and don't go spending a lot of time here because this is being pretty intensive for your firewall data playing CPU and I'm just doing a quick check to make sure that I do have sessions matching that that filter strings I'd created and then I'll turn off the log capture now let's go investigate that capture but first things first we may have a firewall with multiple data plane CPUs so we issue that command to aggregate the output data into a single unified document now you can then view that result that document using less it's either gonna be MP - log or DP - log if you have a smaller firewall or a larger firewall and you could go through the output in the CLI but to be honest I really struggle interpreting the logic here so I like to go out and analyze it inside of a tool like a notepad plus plus so let's look at that you made it look really easy I love it it's practice practice makes easy all right so I've taken the output that I've looked at in notepad plus plus and I've pasted it in here for us to look at and so here you can see the traffic arrives at the ingress stage now there's no tag value because this is the first time we've ever seen this traffic now tags gonna become important later so you'll see it repeated in the future but it does communicate some good stuff to us right now not much as you see it's shown up from my 10003 address to the Google DNS server and again protocol 17 tells me this is UDP traffic you can also see the source port and destination port as well as the packet length checksum etc and you can see the flow lookup key which the firewall creates during the ingress stage based on this traffic and again this is a hash of source IP source port destination IP destination port and the ingress zone next you'll see that where we're analyzing all of this in visas one if you have a firewall with multi visas that would be ver important to know and the firewall also says there's no flow key found matching this traffic and so we have to send this through slow path so we're going to include to create a session aka sending it through the session setup process so that was the first phase of setting up the itinerary in your travel analogy or session setup what we did that initial policy check just based on the quintuple right just the essential pieces of information now we're moving into creating the session and what follows next so next is the session setup stage or slow path as you see here now oh so I got actually got that wrong because that was just the ingress stage this here is the session setup stage yes exactly okay right so we receive our packet at session set up next week just validate this is the same packet from the same source to the same destination same protocol and we see that we're gonna do a policy based forwarding lookup now there is no PDF rules in my firewall right so it says none or there is none no results after this this check and if you did have a PBF rule you would see information there about which rule this traffic matched and what the forwarding decision would be as a result of that rule since I have none we move on to the next step where we can capture in for session set up the ingress interface was Ethernet 1/2 and the egress interface is gonna be Ethernet 1/1 so this is like knowing my source Airport and my destination Airport and then we do a lookup to see if this traffic would match any NAT rules we have you know like do I have to clear customs and things like this and so it does match a NAT rule you can see it's index 0 which is the first rule inside of my web UI so web UI starts numbering at 1 CLI starts numbering at 0 also you can see index 0 has a rule name of source net out and you can see down below how we're gonna translate this packet from 10003 as the source IP to 172 29 to 25 as the post net IP now one thing I should point oh you're gonna do it right now you're gonna highlight the policy look up okay I'm a little ahead of you I'm sorry that's okay yes the next thing I want to point out is you've got this policy look up now it's not very clear but this is a security policy check and it says it matched rule index eight now don't be confused by this numbering here again we start against we start numbering with zero and so this actually in my web UI is rule number ten so since we start numbering at zero you would assume that this would be index nine however there's a disabled rule in my policy between ten and one and so disabled rules don't count in the CLI hence it's rule number eight okay next we do this TC I inspect now if you don't have a firewall running pano s90 you won't see this entry here but this is tunnel content inspection this is an alibi of the dns security service that jason introduced us to in a previous learning happy hour episode and here you can see we're doing that lookup right now after that we'll allocate a session ID in this case five five three two seven and then down at the bottom we create the session and in queue to install essentially that install means we're putting this session ID into the firewall session table and now you'll be able to see this under show sessions all or in the session browser of the web UI right I was about ready to say that that all of this detail there's a lot of data here and this there's an easier way to see some of this and that's in the actual session browser itself and in the sea-ice session tool but what's nice about this is you're getting additional detail not just summary session data and and so I think the flow logs are really helpful in kind of looking at you know if you're troubleshooting you know a routing problem for instance this is one of those things will kind of expose the why behind that or if you have a land attack right where you have an address on the firewall with an ad in front of that so your source and destination addresses actually are the same you the flow logs give you a lot of the why as to what's happening and or detail but a lot of this is also in the session log session browser yeah great point and and to me this reads like a book there's a lot of stuff you know surrounding what I've highlighted that we won't necessarily always understand some of it may be reserved for our engineers or attack folks but the key points I'm trying to point out for us and yeah as I said reads like a book it really helps us understand what's happening at which point in processes so next yes not exactly a book you'd read to your children to go to bed it would be perfect go to banter I'll read the flow logic output to you the packet was received at the Fastpass stage so now we get to the inspection and enforcement stage as you'll see labeled as fast path and you can see now we have our session ID five five three to seven and notice that tag up there at the top also says five five three to seven so you can correlate against the tag value as it came in you know from ingress I was zero but then when we send it over to session setup we saw that entry where the tag or the session ID was created and for the rest of the processing that tag value will align with the session ID five five three two seven then you can see some more information like the source IP going to the destination IP protocol number again source port destination port but also we see here this is indicating this is IP version 4 as opposed to IP version 6 or as my boss likes to point out IP version five was real just not really used and there's a couple other things I want to point out here like type a service value or differentiated services code point these two values are QoS related and zero means that there isn't really any kind of header information for type of service or DHCP and so the firewall is not going to really do any extra QoS on this traffic but we could definitely add QoS markings with my security policy or use whatever values are defined here for my egress queuing if I want and as you all know I love QoS go back and watch episode 3 of learning happy hour and you'll get a feel for how much I love QoS next this is where we actually execute nat nat is now being performed on this traffic we did a lookup in session set up but we didn't do anything until we get into these inspection and enforcement or Fast Pass stage and this is where we rewrite the packet header now with the post NAT destination values then we now know our forwarding lookup this is going to egress out a different interface it came in on interface 17 and in my case is layer 3 interfaces so we're gonna do our route lookup again the lookup we did in session setup was just to determine the destination zone but for every packet flowing through the firewall we always do a route lookup in the fast path stage because you may have a route change as a result of a dynamic routing protocol or ecmp equal cost multi path could cause this packet to take a different route than the previous packet did however it's important to know that the destination zone must still be the same destination zone that was determined back in slow path if the routing decision would send this traffic out a different zone the session would die right now because it's not the same destination zone that was determined during slow path and you just actually captured a troubleshooting scenario I where traffic is being dropped and there's some question as to why and that could be exposed by identifying what the destination zone is and this could be a potential way of determining exactly right yeah and you can see you know the the route information that was determined now in fast path stage it was decided by virtual router run and you can see you know the lookup was done and then our egress interface is shown the zone associated and my next hop alright next you can see we do our ARP right we resolve our next hop interface we get our entry whether this was a cached ARP entry or we we do it you know fresh for the first time and then we move on to our egress stage you can see our tag value is the same as the session ID so we can correlate because if you've got a lot of traffic matching your capture filters they can be kind of meshed together and you need to be able to know which data from the output log matches the same okay and so that tag value is kind of your little key to be able to follow it through and you can also use like you know MAC addresses and and packet sizes and stuff like that as well as date and timestamp but still that tag value is going to be your best friend all right so that's my session ID then I've got my IP address information protocol number version all that type of service and we can see our ports again and now we transmit our packet out port 16 so that's the traffic going through a flow basic capture and I think it's it's pretty exciting to see you know all this stuff laid out for us because when we're trying to figure out what's happening here it is it tells us exactly what's happening this is great especially in the lab environment where you want to kind of follow package from a testing point of view and to learn more about the inner workings of that firewall and you know kind of like the Magic School Bus kind of scenario where you kind of working your way through some sort of you know series yeah arterial system the lungs whatever it does but if you are familiar with that it's like a little children show that back in the 80s or whatever the point is you can you can learn from the flow flow basic in the packet diagnostic logs but again just want to reiterate the importance of you do this on a production machine that usually you want to do that with the guidance of support and be sure that you have a capture filter in place and be aware of the fact that this does have an impact on the performance of the firewall exactly right okay so that's just a flow capture now there's several different types of captures you can do again we focused on flow but these are all other ones that I find very helpful so a lot of different logs beyond just that flow basic log that you broke through logs for a lot of other different troubleshooting cases exactly right alright folks we've we've dove deep right now and I want to kind of end on a refreshing note I've been having a fantastic time here in India and if you've never been to India or don't know much about it I want to introduce you to what I love about India the food the people the culture check it [Music] [Music] [Music] [Music] [Music] so I'm here in Bangalore Airport and this guy just found me he is a learning happy hour fast what's your name again Anna Rock I know dog right and your buddy Russell nice so hey you guys gonna be on our episode small world go panelist Paul that's fantastic Mitch thank you so much for sharing I love ya and we want to thank you for watching and we want to hear from you so please send us an email at learning happy hour Paul to networks calm and many of the things that we are doing and having our schedule and planning on doing well those things come by request so if there's something you're interested in learning more about by all means let us know thanks for watching cheers Cheers [Music] [Music] daddy where do packets come from well this one came from interface 17 the bedtime conversations are endless thank you for watching this episode of learning happy hour at Palo Alto Networks we are strong advocates of continuous learning and we hope you are too to continue learning about our fantastic products and services you can attend a class with one of our authorized training centers or you can self-study about these products and services through our digital elearning courses and if you liked this episode of learning happier consider watching this one or this one and don't forget to Like subscribe and share with your friends and thanks again for watching

Channel: Palo Alto Networks LIVEcommunity

Views: 25,125

Keywords: palo alto networks, ngfw, next-gen firewall, next-generation firewall, LHH, learning happy hour, risk, risk mitigation, CyberSecurity, cyber, security, troubleshooting, routing, NAT, flow, flow logic, doc-1628, day in the life of a packet, day in the life

Id: -4sLeiaIFHY

Length: 40min 0sec (2400 seconds)

Published: Fri Oct 11 2019