The default AWS site-to-site VPN connection (Tunnel mode / AES128 / SHA HMAC / no AH) looks like it should be good for 1438 byte inner packets over a 1500 byte Internet:
New IPv4 Header for IPsec 20 ESP Header - SPI (4 bytes) - Sequence (4 bytes) 8 ESP IV 16 Original IPv4 Header 20 Original IPv4 Payload 1418 ESP Trailer - ESP Pad (0 bytes) - Pad Length (1 bytes) - Next Header (1 bytes) - ESP ICV (12 bytes) 14 ---- Total IPsec Packet Size 1496
AWS has several ways to export customer-side VPN config details, including:
-
API dump of CustomerGatewayConfiguration, an XML blob that includes:
<tcp_mss_adjustment>1379</tcp_mss_adjustment>
-
Configuration export formatted for a Cisco router, which includes:
interface Tunnel1
;ip tcp adjust-mss 1379
-
Configuration export fomatted for a Vyatta router, which inludes:
set interfaces vti vti0 mtu '1436'
There are a number of disparities that I'm struggling to reconcile:
- AWS recommended MTU (1436) looks a little pessimistic when compared to my expected 1438.
- AWS recommended MTU (1436) looks wildly optimistic considering we could switch to SHA512-HMAC, and wind up losing another ~20 bytes to ESP trailer. I do not believe that the numbers I'm getting from their config tool take into account the operational state of the tunnel (peer proposal and whatnot).
- AWS recommends 1436-byte MTU, but also MSS clamping at 1379 bytes... 43 bytes of IP+TCP headers?
- AWS config examples for some platforms set tunnel interface MTU while others don't (perhaps reflects more on AWS' faith in Vyatta than anything else)
- Is the strategy for non-TCP traffic (no constrained MTU and not MSS clamp ability) to just let it fragment as needed?
I'm hoping somebody can help fill in some of these gaps in my understanding.
Thanks!
No comments:
Post a Comment