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
gateway id: 1
local ip: 126.96.36.199
peer ip: 188.8.131.52
inner interface: tunnel.1
outer interface: ethernet1/5
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 8) 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!
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:
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
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!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!