Analysis of changes in Ethernet frames during data transfer between routers
Let’s look at what frames (frames) look like at each stage of transmission from the client to the switch, router, firewall and server, and what fields are changed in them. I will proceed from the fact that the reader is familiar with the basic TCP / IP course, and touch only on the points necessary for the article.
Let’s do an experiment
Let’s connect the browser from the client to the web server and look at the source and destination IP and MAC addresses in all frames in each channel (in the picture below). The easiest way to see this for yourself is to connect a sniffer to each channel.
I propose to carefully look at the network equipment connection diagram below:
Scheme of connecting a client to a server through intermediate equipment with IP and MAC addresses.
A client with IP address 10.1.1.11/24 and MAC address 0000.0001.1111 connects to a server with IP address 10.1.3.33/24 and MAC address 0000.0008.8888. The mask /24 (255.255.255.0) is chosen as an example.
Ethernet frame structure during network transmission
Let me remind you what the structure of an Ethernet frame (frame) looks like when transmitted to the network: all the headers and data of the higher protocols of the TCP / IP stack are combined into a single data block for transmission. Your files, voice and video in the form of sliced pieces are moved to the Payload field. Inside the Ethernet header are the source and destination MAC addresses, and inside the IP header are the source and destination IP addresses. This data structure in our networks is used by switches and routers to send frames to each other. For example, the headers of the IP protocol version 4 and the TCP protocol are displayed below inside the frame (other protocols can be placed, such as ICMP or UDP):
Example of an Ethernet frame (frame) Ethernet MTU is the maximum frame size for a given transmission medium. Usually 1500 bytes. TCP MSS is the maximum size of a TCP data segment. Usually MSS = MTU-40 = 1460 Total frame length is 1518 bytes.
There is a good visualization of the scheme for transmitting frames (frames) over the network article by Artem Sannikovhere is a demonstration of how a frame is forwarded through a switch:
Interestingly, in the frame header, the destination address comes first, while in the IP header, the source address comes first.
Let’s study the first frame, between the client and the switch.
So, what will be the Source IP and Source MAC, Destination IP and Destination MAC in the first frame from the client computer? Try writing these addresses in frames yourself: look at the header field names in the picture below, write down your answers, and only then read on. Test yourself.
Source MAC Address = ???
Destination MAC Address = ???
Source IP Address = ???
Destination IP Address = ???
Try writing these addresses in frames yourself: look at the header field names in the picture below, write down your answers, and only then read on. Test yourself.
Intelligence: best to fill it out first
If you are a teacher, then give this task to your students: ask them to fill in all these cards in the picture below.
Fill in the frame header fields yourself before continuing to read the replies
We will assume that the client and server have already transmitted data to each other, and therefore all the necessary ARP tables and routing tables are configured all the way from the client to the server. The client’s default router is 10.1.1.1/24. Accordingly, the MAC address from this IP address has already been requested in one of the previously sent ARP requests, and the client’s ARP table has information about the MAC address for IP address 10.1.1.1. Netmask everywhere /24.
We fill the first frame with the data of IP and MAC addresses.
Frame from client: src MAC – MAC address of the sender, Dst MAC – destination MAC address, src IP – sender IP address, dst IP – Destination IP address
I believe that you understand what source and destination IP addresses will be in the frame from the client, because they are given in the problem statement: we want to send data from the IP address 10.1.1.11 to the IP address 10.1.3.33. Therefore, these addresses are entered in the IP header.
I have met students who entered the IP address of the next router (in the example – 10.1.1.1) in the field with the recipient’s IP address: this is a mistake. Always in frames when moving through networks, only the source and destination IP addresses will be in the IP header field.
- If you send a different address, then the real destination address will not be available to the router and there will be no information in the routing table about where to forward the packets.
- If you write a different source IP address, the router won’t know where to return packet delivery errors.
At the same time, IP addresses in frames can change if a device with Source NAT or Destination NAT enabled appears along the frame path. But in our task, such a device that performs address translation is not indicated.
It’s also easy to figure out what the sender’s MAC address will be: it’s the client’s MAC address, 0000.0001.1111.
What destination MAC address to write
Since this is the most important part of the text, I have separated it into a separate chapter.
What destination MAC address to write in a frame outgoing from the Client interface
- Sometimes people think that it will be the MAC address of the server, namely 0000.00008.8888. If you create such a frame and send it from the interface of the client computer towards the switch, then the frame will actually fall into the broadcast domain accessible through the switch (on the left side of the picture). The switch will receive this frame, check its MAC address table that there is no such address in it, and send the frame to all its ports at once. As a result, it will reach the router (on the left side of the picture above), which has a different MAC address (0000.0003.3333), and the router will simply discard this frame, because it came to the wrong address. Such a frame simply will not reach the server.
- The destination MAC address cannot be the switch MAC address either. When the switch receives the frame, it will determine that the frame was sent to it, and, most likely, it will simply “kill” it (depending on the device manufacturer), because the frame has already reached and it is not clear what to do with it. And I’m also wondering: how do you find out the MAC address of the switch on the Client computer? After all, the device does not inform its connected clients in any way.
You need to specify the MAC address of the router, which is your default router. The router’s IP address is set in the routing table when you set up your computer, or it can be obtained from a DHCP server. An ARP request was made in advance from the Client computer, thanks to which we find out the MAC address corresponding to the IP address of the router. It is he who must be substituted in the Destination MAC address field.
As a result, this frame from the client gets to the switch. The key here is that the switch does not change either the MAC address or the IP address. At the same time, the switch stores a table describing on which interface which MAC addresses are connected, and determines the interface on which the next router we need is 0000.0003.3333. From the switch, the frame is sent to the router (unchanged), where it is successfully received, because the recipient specified the correct MAC address.
I specifically drew a switch on the diagram, because I wanted to inform readers of important information: neither MAC addresses nor IP addresses in frame headers on switches change. It is also important to note that the switch address does not need to be specified in the Destination MAC address field.
Sometimes students ask: why is the MAC address of the upper switch interface on the left not shown in the picture? And you already know the answer: because it doesn’t matter. The Source MAC address field will contain the MAC address of the client computer interface, not the switch interface: the switch does not change either the Destination MAC address or the Source MAC address in frame headers. Did you repeat it three times? 🙂
The solution of the problem
The final picture will look like this: the IP addresses in the header inside the frame are always the same, but the MAC addresses change to the MAC addresses of all interfaces that have an IP address. This is how an Ethernet-based network works. There may be other ports along the way between routers: serial, frame relay, ATM. You need to understand that the MAC address is applicable only to the Ethernet protocol. Link layer protocols use different addressing schemes: for example, frame relay uses a number DLC, and the ATM protocol is VPI or VCI. Today we are talking only about Ethernet.
On a real network, you can look at all frames with a sniffer by connecting to the SPAN port of any of the devices, or use TAP devices or even network brokers. If this is virtualization, then use vTAP or vBroker.
A scheme for transmitting frames over a network from a client to a server. Client addresses are marked in blue, server addresses are marked in red
What happens if I add NGFW to this network
Let’s put in an NGFW schema that secures connections from clients to the server. You need to understand that NGFW will be a router for the network. There are IP addresses and MAC addresses on its interfaces, and then the frame passing scheme is similar to the scheme with a router ..
Frame transmission scheme in an NGFW network with routing enabled
I’m puzzled by requests from security colleagues to install a firewall with rules for checking the source and destination MAC addresses using NGFW. How will NGFW learn MAC addresses in a network with routers? Take a close look at the picture: NGFW only sees the MAC addresses of the nearest routers. You will never be able to receive a frame with the MAC address of the client or server, because routers rewrite MAC addresses along the way, and, in fact, NGFW itself too. Checks by MAC addresses can be done, but the field will contain either any or the MAC address of your router or the provider’s router.
What if I want a filter bridge
If you change the picture above and connect NGFW not as a router (layer 3 device), but as a switch (layer 2 device) or as a virtual line (layer 1 device), then NGFW will actually be filter bridge according to the typical classification of firewalls. And we still understand that it will be possible to filter only devices that are connected to NGFW either directly or through a switch. This, in principle, happens in SCADA networks, but all L3 devices are on the Internet, and it will not be possible to filter them by MAC addresses. In a SCADA network, it is more logical to make a VLAN insertion, divide one broadcast domain into several different VLANs, and replace the VLAN tags on the NGFW itself. Example described in my video lecture on YouTube.
Frame transmission scheme in a network with an L2 firewall (transparent to L3)
I would like everyone to know now that:
- When IP packets move around the network, the MAC addresses of the switches are not substituted into Ethernet frames.
- As IP packets move around the network, each router substitutes its own MAC address, and our sniffers or traffic analyzers (for example, NTA systems) determine the MAC address of the nearest router, not the real host.
- There is no point in filtering by MAC addresses. It is only needed for one LAN or one broadcast domain.
The TTL field and checksums will also change, but this needs to be discussed separately.
Update 02/08/2023. Recorded a video on the same topic:
Author Denis Batrankov, Head of Network Security at Positive Technologies.