AWS ARP Wire Capture - Network Deep Dive
Transcript
[Music] All right, this is a geeky but fun lab. I installed two Windows 2016 servers in AWS. Nothing really special. Default VPC. No fancy settings. Node one, node 2. I installed Wireshark on it. 20 bit classB network. I wanted to see what happens with when the mapping service intercepts ARP requests. We know that the in AWS's network and their SDN there is no layer 2. All layer 2 gets encapsulated. Anything that's not like a ARP request basically gets dropped.
So if node one and no if node one pings node two and you're going to go through that ARP process but the ARP isn't answered by node two directly. What does that really look like from a wire capture perspective? This is that lab. I I had fun doing it. I hope you enjoy it. You might have to watch it a couple of times because it's a little heady. Packet capture is not the funnest activity, but watching it in action is is actually quite amazing.
Let's first sort by protocol by clicking on the protocol but button. We can sort by alphabetically by protocol. So we're looking at all ARP requests. The first ARP request we're going to look at is the one that catches our eye, which is the broadcast. In AWS, there's no broadcast. So what's the catch exactly? Well, let's examine. 77 I'm sorry. So node one is asking the question who has node two. Just to validate that, let's take a look at the source MAC address and that the source MAC address matches up with our actual host that we're on on node one.
So, our physical addresses do match. Host one or node one is seeing its own broadcast. Just for a sanity check, let's sort by destination and make sure there's no other broadcasts in the destination field. H. Okay, so that's just a single broadcast. Now, let's switch over to node two and see what we can find out. All right, so node two, we've done the same thing. 42 tell node two. So node two is asking the question where's node one?
single broadcast address is being sent. And just the same on node one, we didn't see the broadcast from node two asking for node one. But yet the two nodes were able to communicate. Let's take a look at the next set of ARP replies. No one never got the ARP request. the messaging service or the mapping service rather has answered the ARP request on behalf of node one. How do we know that? Because we're getting the ARP reply. 200 host or node 2.
77 is at a physical address and the source and destination looks right. But we never saw that traffic on node one. Node one didn't originate the response because the mapping service originated the response. This isn't exactly how AWS explained it. At least this is not how I got it. This is why we do these experiments or these labs to actually see how this works. So that when it's not working or we have a OS misbehaving or application misbehaving, we understand exactly what's happening at the packet level.
The mapping service will intercept all broadcast and then answer those ART requests on behalf of the target system. It is a really well-run and well scalable solution. As you can see, there's no changes to the actual OS. ARP works as expected. All of your security and networking tools should work as anticipated. I highly recommend that you do variations of this lab. It was extremely fun. I hope you enjoyed walking through it. I know it was a little heady, but you know what?
This is what networking and deep diving is all about.
