<div dir="ltr">It's not like IPsec protocols (it's a suite of protocols and concepts, not one) are proprietary or something. There are pretty ASCII pictures in RFCs with all about how the packets are put together. See section 3 of RFC 4303 to see how ESP transport and tunnel mode datagrams are put together.<div><br></div><div>For the tl;dr, in transport mode everything above IP header is the payload. In tunnel mode, the whole IP datagram is the payload. The contents of the payload are specified by the "Next Header" field of the ESP header. For an encapsulated IPv4 packet, it would be protocol 4 (IP-in-IP). For an IPv6 packet, it would be 41. For TCP in transport mode, it would be 6. UDP is 17. Etc.</div><div><br></div><div>If you want to see it in action yourself, you can set the encryption algo to NULL and do a capture.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 15, 2022 at 10:16 AM Grant Taylor via NANOG <<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Bill,<br>
<br>
On 2/12/22 8:55 PM, William Herrin wrote:<br>
> It's tunnel mode plus a tunneling protocol plus some implicit routing <br>
> and firewalling which gets in the way of dynamic routing.<br>
<br>
I assume you meant to say that it's /transport/ mode plus a tunneling <br>
protocol.<br>
<br>
I wonder if you are thinking more of an IPSec VPN management suite of <br>
sorts, e.g. wizard / helper that is included in some devices.  I'm <br>
thinking at a very low (manual) level.  The "implicit routing" and <br>
"firewalling" are the strongest indicators of this to me.  The manual <br>
IPSec that I've done on Linux (via the `ip xfrm` command) doesn't touch <br>
firewalling and I believe that addresses inside the tunnel would be <br>
completely separate operations / commands.<br>
<br>
> Try it if you don't believe me. Set up tunnel mode ipsec manually on <br>
> two nodes (no IKE) and get them talking to each other. Then change <br>
> one to transport mode and add I think it's an IPIP tunnel but I don't <br>
> remember for certain. And add the appropriate routes into the tunnel <br>
> virtual device. You'll find they talk.<br>
<br>
Unfortunately I don't have the leisure time to do this experimentation <br>
currently.  As such I'm going to put this on my to-do pile for future <br>
investigation ~> follow up.<br>
<br>
I do not recall reading about IPSec /Tunnel/ mode re-using an existing <br>
tunneling protocol; IPIP, etc.  Perhaps I'm misremembering.  Perhaps it <br>
inherently does so without declaring as such.<br>
<br>
> What did you think IPSec was doing? Transport mode encrypts the layer <br>
> 4 and up of the packet between two machines; it doesn't encapsulate <br>
> it. When they added tunnel mode, the inner layer 3 had to go somewhere.<br>
<br>
My understanding is that /Transport/ mode applies AH (no encryption) and <br>
/ or ESP (encryption) to L4 datagrams and that /Tunnel/ mode does the <br>
same to L3 packets.<br>
<br>
P.S.  I'm sending this reply to NANOG in case anyone else has any <br>
contribution / comments.  I suspect any future reply will be directly to <br>
Bill as this is getting further off topic, both for NANOG in general and <br>
for this VPN recommendations thread.<br>
<br>
<br>
<br>
-- <br>
Grant. . . .<br>
unix || die<br>
<br>
</blockquote></div>