show vpn flow: Should "tunnel mtu" be renamed to "suggested tunel mtu"?

[cstech]

Hello,

Can you answer these questions regarding the tunel mtu that appears in the output below?

cstankevitz@PA-500-Local> show vpn flow tunnel-id 27

tunnel  Sterling

        id:                     27

        type:                   IPSec

        gateway id:             1

        local ip:               164.67.80.124

        peer ip:                53.103.78.197

        inner interface:        tunnel.1

        outer interface:        ethernet1/5

        state:                  active

        session:                20027

        tunnel mtu:             1428

1. Who/what computed this MTU?

2. Did the thing that computed this MTU consider the encryption parameters I am using for the tunnel?

3. Why does this MTU value not participate in PMTUD?

4. (Same question as 3) Why does the MTU listed above not appear in a tracepath?

5. (Same question as 3) Why does the MTU listed above not appear in a "show routing fib"?

6. Am I expected to copy the MTU value listed above and paste it as the MTU value for the tunnel interface, overriding the default of 1500?

7. If the answer to (6) is "yes" (which I believe it is), then why didn't the PAN just do it for me?

8. Why would PAN confusingly give a tunnel interface two MTUs:the real MTU on the interface that participates in ICMP and another "fake" MTU that displayed above that does not participate in ICMP?

9. (Same question as 😎 Should the label "tunnel mtu" that appears in the output of "show vpn flow tunnel-id" be renamed to "suggested tunnel mtu"?

Thank you for your help!

Chris

[HULK]

Hello Chris,

For ethernet interface, the Max MTU size is 1500 bytes. The ESP protocol header will be placed in the top of the IP header.

IP header would be 20 Bytes, hence the original data+ EST header size can be max (1500-20)=1480 Bytes.

ESP header can be 52 bytes, including below mentioned option field:

---------------------------------

ESP header

--------------------------------

Security Parameters Index =(32 bits) Arbitrary value used (together with the destination IP address) to identify the security association of the receiving party.

Sequence Number (32 bits) =A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect against replay attacks. There is a separate counter kept for every security association.

Padding (0-255 octets)= Padding for encryption, to extend the payload data to a size that fits the encryption's cipher block size, and to align the next field.

Payload data (variable) =The protected contents of the original IP packet, including any data used to protect the contents (e.g. an Initialisation Vector for the cryptographic algorithm). The type of content that was protected is indicated by the Next Header field.=Size of the padding (in octets).

Next Header (8 bits) =Type of the next header. The value is taken from the list of IP protocol numbers.

Integrity Check Value (multiple of 32 bits) =Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.

Payload data (variable, max 6 byte) =The protected contents of the original IP packet, including any data used to protect the contents (e.g. an Initialisation Vector for the cryptographic algorithm). The type of content that was protected is indicated by the Next Header field.

So, the actual data can pass through the tunnel without fragmentation will be (1480-52)=1428 Bytes.

The tunnel  MTU would not depend  on encryption parameter. Because, encryption parameter will be identified by SPI (Security parameter index-to identify the security association SA )

Path MTU is not being calculated, and any packet more than 1500 Bytes on an ethernet interface will be fragmented

Thanks

[cstech]

Hulk,

Thank you for your help.  Would you please consider answering my question #4 and #6 in my original post?

Thank you again!

Chris

[cstech]

Assuming the answer to (6) was yes, I dropped the interface MTU down to 1400 and my VPN bandwidth improved, certainly due to the reduced number of fragmented packets.

Why is the PAN-OS going through the trouble of computing an ideal MTU but not actually applying it to an interface so that it can participate in PMTUD?  What am I not getting?  Arg!

Chris