day in the life of an Encapsulating Security Payload(ESP) packet in Linux

Martin T <[email protected]>
Newsgroups org.kernel.vger.lartc
Message-ID <CAJx5YvFfZ_Q9Et0VQMyTGifOAFVS9DZm9xh+jYS1aRDLhRHF7A@mail.gmail.com>
Hi,

I have a simple site-to-site IPSec VPN where "server-A" is connected
to a "firewall-A" over an IPSec tunnel. In front of "server-A" there
is a switch with has a 1500 byte MTU interface facing the server.
Sometimes clients behind "firewall-A" send large packets to "server-A"
and server replies with ICMP "unreachable; frag needed" messages:

11:19:22.309296 IP 10.10.10.135 > 192.168.100.4: ICMP 10.10.10.135
unreachable - need to frag (mtu 1438), length 36

10.10.10.135 is the IP address on "server-A" eth0 interface and
192.168.100.4 is the IP address of the end-client behind "firewall-A".

Am I correct that ICMP "unreachable; frag needed" messages are sent
only in case (server acting as) a router wants to route a package to
another interface, but this interface has a smaller MTU than the
package and router is not allowed to fragment this package because DF
flag is set? If yes, then "server-A" does not do any routing. It's
"left side" Openswan configuration is following:

        left.10.10.135
        leftsourceip.10.10.135
        leftsubnet.10.10.135/32
        leftnexthop=%defaultroute


When I check the packet flow diagram in
Wikipedia(https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg),
then ESP packet should traverse "routing decision" step twice- first
when the packet is encapsulated and second time when it is already
decapsulated. However, in both occasions the destination IP address is
10.10.10.135, which is a local physical interface(eth0) in "server-A":

server-A# ip route get 10.10.10.135
local 10.10.10.135 dev lo  src 10.10.10.135
    cache <local>
server-A#

..and thus the routing is done via lo interface which has a 65536 byte MTU.

Could anybody explain the day in the life of an ESP packet in Linux
and why does it sent out those ICMP "unreachable; frag needed"
messages?


thanks,
Martin
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.