Thermalcircle

climbing the thermals

User Tools

Site Tools

blog:linux:nftables_ipsec_packet_flow

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
blog:linux:nftables_ipsec_packet_flow [2022-08-14] – added details about xfrm bundle Andrej Stenderblog:linux:nftables_ipsec_packet_flow [2025-01-05] (current) – showing encaps more clearly, no linebreaks Andrej Stender
Line 36: Line 36:
 packets can travel through it. In case of //tunnel-mode// the IP packets which shall travel through the VPN tunnel are being encrypted and then encapsulated in packets of the so-called ESP protocol((Yes, there is also the AH protocol, which can be used as alternative to ESP, but AH only provides authentication and data integrity and no encryption. Thus, it is neither relevant for this article nor widely used in practice.)). The whole thing is then further encapsulated into another (an "outer") IP packet. The reason is that the VPN tunnel itself is merely a point-to-point connection between two VPN endpoints (one source and one destination IP address), but those endpoints are in that case VPN gateways which are used to connect entire subnets on both ends of the tunnel. Thus, the source and destination IP addresses of the "payload" packets which travel through the VPN gateway need to be kept independent from the source and destination IP addresses of the "outer" IP packets. Encapsulation then looks like this (example for a TCP connection): packets can travel through it. In case of //tunnel-mode// the IP packets which shall travel through the VPN tunnel are being encrypted and then encapsulated in packets of the so-called ESP protocol((Yes, there is also the AH protocol, which can be used as alternative to ESP, but AH only provides authentication and data integrity and no encryption. Thus, it is neither relevant for this article nor widely used in practice.)). The whole thing is then further encapsulated into another (an "outer") IP packet. The reason is that the VPN tunnel itself is merely a point-to-point connection between two VPN endpoints (one source and one destination IP address), but those endpoints are in that case VPN gateways which are used to connect entire subnets on both ends of the tunnel. Thus, the source and destination IP addresses of the "payload" packets which travel through the VPN gateway need to be kept independent from the source and destination IP addresses of the "outer" IP packets. Encapsulation then looks like this (example for a TCP connection):
  
-| <html><code>|eth|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<span style="color: navy;">ip</span>|tcp|payload|</code></html>((Of course, in the actual packet there is no "blank space" between the ''eth'' (ethernet) and the ''ip'' header. I just show it like this here to emphasize WHERE in the packet the ESP header and the outer IP header are being inserted.)) | A "normal" packet which shall travel through the VPN tunnel, is encrypted and encapsulated like this while traversing the VPN gateway. | +| A "normal" packet which shall travel through the VPN tunnel, is encrypted and encapsulated like this while traversing the VPN gateway: | 
-| <html><code>|eth|<span style="color: red;">ip</span>|esp<span style="background-color:#E5E4E2;">|<span style="color: navy;">ip</span>|tcp|payload|</span></code></html>((The darker grey background here shall indicate that this is the part of the whole packet which gets encrypted.))((There is one further detail which I intentionally omit here because it is not relevant for the topic at hand: The ESP protocol in reality does not only possess a //header// but also a //trailer// part which comes after the payload. So, to be completely accurate, the ESP encapsulation in reality looks like this: ''|eth|ip|esp-header|ip|tcp|payload|esp-trailer|''.)) | :::  |+| <html><code>|eth|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<span style="color: navy;">ip</span>|tcp|payload|</code></html>((Of course, in the actual packet there is no "blank space" between the ''eth'' (ethernet) and the ''ip'' header. I just show it like this here to emphasize WHERE in the packet the ESP header and the outer IP header are being inserted.)) | 
 +| <html><code>|eth|<span style="color: red;">ip</span>|esp<span style="background-color:#E5E4E2;">|<span style="color: navy;">ip</span>|tcp|payload|</span></code></html>((The darker grey background here shall indicate that this is the part of the whole packet which gets encrypted.))((There is one further detail which I intentionally omit here because it is not relevant for the topic at hand: The ESP protocol in reality does not only possess a //header// but also a //trailer// part which comes after the payload. So, to be completely accurate, the ESP encapsulation in reality looks like this: ''|eth|ip|esp-header|ip|tcp|payload|esp-trailer|''.)) |
  
 If //Nat-traversal// is active, then ESP is additionally encapsulated in UDP: If //Nat-traversal// is active, then ESP is additionally encapsulated in UDP:
  
-| <html><code>|eth|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<span style="color: navy;">ip</span>|tcp|payload|</code></html> |In case of //Nat-traversal// additional encapsulation in UDP (same port ''4500'' as for IKE is then used here). | +| In case of //Nat-traversal// additional encapsulation in UDP (same port ''4500'' as for IKE is then used here): | 
-| <html><code>|eth|<span style="color: red;">ip</span>|udp|esp<span style="background-color:#E5E4E2;">|<span style="color: navy;">ip</span>|tcp|payload|</span></code></html> | :::  |+| <html><code>|eth|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<span style="color: navy;">ip</span>|tcp|payload|</code></html> | 
 +| <html><code>|eth|<span style="color: red;">ip</span>|udp|esp<span style="background-color:#E5E4E2;">|<span style="color: navy;">ip</span>|tcp|payload|</span></code></html> |
  
  
Line 584: Line 586:
   * [[https://ramirose.wixsite.com/ramirosen|Linux Kernel Networking - Implementation and Theory (Rami Rosen, Apress, 2014)]]   * [[https://ramirose.wixsite.com/ramirosen|Linux Kernel Networking - Implementation and Theory (Rami Rosen, Apress, 2014)]]
  
-//published 2020-05-30//, //last modified 2022-08-14//+//published 2020-05-30//, //last modified 2025-01-05//
  
blog/linux/nftables_ipsec_packet_flow.1660489201.txt.gz · Last modified: 2022-08-14 by Andrej Stender