Can one influence the max. packet size of ISAKMP packets of the other party when creating site-to-site VPN?

[Norbert Rozs]

Dear Community,

Can one influence the max. packet size of ISAKMP packets of the other party when creating site-to-site VPN just like the analogy when you use "ip tcp adjust-mss" and inform the other party about our max. MSS?

Thing is: I try to establish a cert. based site-to-site VPN and the local ISP's Layer 1/2 devices (of the branch router) are dropping packets (without ICMP notification) larger than 1452 bytes and DF bit set (as ISAKMP set it..). This happens to us: the branch office router don't receive the cert. of the concentrator because it is about 1800 bytes long (fragmented to two 1500+300 bytes packets) and the branch router goes back from MM5 state to Phase 1 because of the MM4 retransmissions. The concentrator has a lot of VPN tunnels so I cannot change anything on that part but I got the idea to somehow influence the packet size from the branch router just like when one configure "ip tcp adjust-mss" and influences the other side of the TCP session to lower the packet size/MSS. The router is a Cisco 3925 with IOS 15.1(2)T5 at the moment.

Is it possible somehow?

Sincerely,
Norbert

[Marcin Latosiewicz]

Norbert, 

Not on IKEv1, I believe there's MTU commands but they are impacting only RA in certain scenarios. 

What you're looking for is easily available in IKEv2. 

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/xe-3s/sec-flex-vpn-xe-3s-book/sec-cfg-ikev2-flex.html#GUID-E5A3890E-0A3B-411D-86C4-A4D08C6E54A9

But on your IOS version you'd have problems sharing IKEv1 and IKEv2 on same source interface. 

M.

[Norbert Rozs]

Marcin,

Yes, it is correct what you wrote but as I mentioned the concentrator is terminating a lot of other sessions so neither the change to IKEv2 nor change anything on the concentrator is possible to me (plus far as I know this is influencing only the side where you configure the command).

Norbert

[Marcin Latosiewicz]

Norbert,

This is worth pursuing with the ISP (or switching to IPv6 where you cannot fragment in transit :D).

Alternative, again impacting a wider range, is to decrease the physical MTU, or punt the IKE negotiation traffic (via local policy?) through some path which would cause fragmentation to occur prior to 1500 bytes leaving your environment. 

M.

[Norbert Rozs]

Marcin,

We reported it but the ISP cannot do anything with this.. The problem is not with the packets from the branch but from the concentrator - so the alternative solution to change anything on it is not possible. This is why I am chasing a solution to influence the concentrator somehow from the branch router.

Norbert

[Marcin Latosiewicz]

Norbert, 

There's no provision for this in IKEv1 standards(s), AFAIR, and I don't think it would be on top of the list of demands from most deployments. 

I don't believe there's an easy way to implement anything on branch to influence how HQ behaves. 

You'd need to trigger an unreachable somehow and if you're losing packets that might not be reliable. 

Does ISP drop both fragments or one of them? Initial or last?

M.

[Norbert Rozs]

Sorry for the late reply.

The ISP is dropping the first of the two packets (the first piece of the cert), we see the second, smaller one.