Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 6584 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec, MTU, Fragmented packets

MadHakish
I've been pulling my hair out on this one. Am I dealing with a blackhole router? It sure seems that way..

*Please read the update at the end, as it contains the verbose output of tcpdump while the key exchange takes place.*

A client recently installed a new T1 in a branch office where 1 employee resides. She has the requirement of needing to connect to and use the file server located at a remote location where the Astaro gateway is located.

I can setup, and connect, without problems from every other internet connection I have tried, and MTU dosn't seem to be an issue (when watching with tcpdump, I see plenty of (DF) packets, and rarely a (frag) packet.)

However with this T1, I receive nothing but fragmented packets coming from the remote user, to the gateway when trying to establish the VPN link.

I have set the client side MTU as low as 200 without success, fragmented packets are still received and thus the connection fails.

My questions is has anyone else dealt with this, is there a graceful solution, or am I stuck setting such a low MTU that it actually affect throughput rates.

If you would like logs, tcpdump output or anything else, I can provide that information at request. As it stands I will copy some tcpdump output from a successful IPSec negotiation, and the unsuccessful negotiation.

Successful:
13:11:34.372187 client.dns.foo.isakmp > astaro.gateway.foo.isakmp: [|isakmp]
13:11:34.372784 astaro.gateway.foo.isakmp > client.dns.foo.isakmp: [|isakmp] (DF)
13:11:34.724401 client.dns.foo.isakmp > astaro.gateway.foo.isakmp: [|isakmp]
13:11:34.739293 astaro.gateway.foo.isakmp > client.dns.foo.isakmp: [|isakmp] (DF)
(There is more output than this during the actual negotiation, but every packet is received w/o fragmenting, ie all are (DF) and the link is alive.)

Now the failed negotiation:
13:15:22.620036 uslink.sucks.isakmp > astaro.gateway.foo.isakmp: [|isakmp]
13:15:22.625174 astaro.gateway.foo.isakmp > uslink.sucks.isakmp: [|isakmp] (DF)
13:15:22.763897 uslink.sucks.isakmp > astaro.gateway.foo.isakmp: [|isakmp]
13:15:22.771993 astaro.gateway.foo.isakmp > uslink.sucks.isakmp: [|isakmp] (DF)
13:15:23.190260 uslink.sucks.isakmp > astaro.gateway.foo.isakmp: [|isakmp] (frag 33972:976@0+) 
13:15:24.013571 uslink.sucks.isakmp > astaro.gateway.foo.isakmp: [|isakmp] (frag 34022:976@0+) 
13:15:26.028746 uslink.sucks.isakmp > astaro.gateway.foo.isakmp: [|isakmp] (frag 34087:976@0+) 
13:15:30.043434 uslink.sucks.isakmp > astaro.gateway.foo.isakmp: [|isakmp] (frag 34223:976@0+) 
13:15:32.764526 astaro.gateway.foo.isakmp > uslink.sucks.isakmp: [|isakmp] (DF) 
13:15:32.901845 uslink.sucks.isakmp > astaro.gateway.foo.isakmp: [|isakmp] (frag 34332:976@0+) 
 [:S]

I have obviously removed any ip's or DNS names for confidentiality.. However it appears to me that USLink (who is providing the client side T1) has a router somewhere along the route that has an MTU of 976 set.

**Update**
Running tcpdump on the gateway with the verbose option provides some more data.. Here's a breakdown of the exchange process using SSH Sentinel as the client.

This is the IKE exchange seen from TCPDUMP for keys only, following this is the certificate exchange where things are breaking down.

14:06:14.720402 astaro.vpn.gateway.isakmp > uslink.client.T1.isakmp: [|isakmp] (DF) (ttl 64, id 0, len 208)
14:06:20.869466 uslink.client.T1.isakmp > astaro.vpn.gateway.isakmp: [|isakmp] (ttl 111, id 4315, len 488)
14:06:20.869954 astaro.vpn.gateway.isakmp > uslink.client.T1.isakmp: [|isakmp] (DF) (ttl 64, id 0, len 108)
14:06:21.010222 uslink.client.T1.isakmp > astaro.vpn.gateway.isakmp: [|isakmp] (ttl 111, id 4316, len 213)
14:06:21.032161 astaro.vpn.gateway.isakmp > uslink.client.T1.isakmp: [|isakmp] (DF) (ttl 64, id 0, len 208)

This is the beginning of the certificate exchange after keys have been compared (above).
14:06:21.320309 uslink.client.T1.isakmp > astaro.vpn.gateway.isakmp: [|isakmp] (frag 4321:1176@0+) (ttl 111, len 1196)
14:06:22.335657 uslink.client.T1.isakmp > astaro.vpn.gateway.isakmp: [|isakmp] (frag 4390:1176@0+) (ttl 111, len 1196)
14:06:24.332881 uslink.client.T1.isakmp > astaro.vpn.gateway.isakmp: [|isakmp] (frag 4473:1176@0+) (ttl 111, len 1196)
14:06:27.026552 astaro.vpn.gateway.isakmp > 66.41.232.90.isakmp: [|isakmp] (DF) (ttl 64, id 0, len 172)
14:06:28.350374 uslink.client.T1.isakmp > astaro.vpn.gateway.isakmp: [|isakmp] (frag 4612:1176@0+) (ttl 111, len 1196)
14:06:31.036336 astaro.vpn.gateway.isakmp > uslink.client.T1.isakmp: [|isakmp] (DF) (ttl 64, id 0, len 208)
14:06:31.178625 uslink.client.T1.isakmp > astaro.vpn.gateway.isakmp: [|isakmp] (frag 4717:1176@0+) (ttl 111, len 1196)
14:06:51.044637 astaro.vpn.gateway.isakmp > uslink.client.T1.isakmp: [|isakmp] (DF) (ttl 64, id 0, len 208)

Notice nearly every packet transmitted during the Certificate exchange is fragmented. IPSec dosn't like that as it's using the keys previously exchanged to verify that the incoming certificate exchange packets are valid by comparing them with the key. This fails because each fragment is compared and discarded. but why is it fragmenting?  [:S]

Client side MTU is now set at 1200.


This thread was automatically locked due to age.
Parents
  • 0
    Hi MadHakish,

    try to enable the ICMP-Code 08 (Source-quench) an all Devices for the IPSec handling.
    I believe the Router as the T1 also, will try to handshake the mtu with this Protocol.

    HTH

    Regards

    Udo Seiler  
  • 0 in reply to Udo_Seiler
    Source Quench, Dest. Unreach|Type 4 and GRE are all enabled..
    I should mention there are 6 other tunnels operational right now and this one just will not work, AND the only one tunneling through a very different set of networks.

    19:51:13.552194 66.173.30.42.500 > 67.95.122.162.500: [|isakmp] (frag 29159:1176@0+) (ttl 113, len 1196)
    19:51:14.562230 66.173.30.42.500 > 67.95.122.162.500: [|isakmp] (frag 29215:1176@0+) (ttl 113, len 1196)

    is all I get during IKE exchange, like the first fragments are the only ones making it.

    Astaro logs absolutely nothing to the VPN logs during this process, and nothing work keeping debug logging on for either. (I've spent hours scouring them.. trust me.)

    Any help would be great..

     [:(]   
Reply
  • 0 in reply to Udo_Seiler
    Source Quench, Dest. Unreach|Type 4 and GRE are all enabled..
    I should mention there are 6 other tunnels operational right now and this one just will not work, AND the only one tunneling through a very different set of networks.

    19:51:13.552194 66.173.30.42.500 > 67.95.122.162.500: [|isakmp] (frag 29159:1176@0+) (ttl 113, len 1196)
    19:51:14.562230 66.173.30.42.500 > 67.95.122.162.500: [|isakmp] (frag 29215:1176@0+) (ttl 113, len 1196)

    is all I get during IKE exchange, like the first fragments are the only ones making it.

    Astaro logs absolutely nothing to the VPN logs during this process, and nothing work keeping debug logging on for either. (I've spent hours scouring them.. trust me.)

    Any help would be great..

     [:(]   
Children
  • 0 in reply to MadHakish
    MadHakish,

    please have a look into the kernel-logfile. Are there some icmp-drops? If yes, enable "ICMP on firewall".
    Reason: Maybe the firewall tries to tell the Roadwarrior to decrease the MTU (I know you already tried to manually configure the MTU but it is a try). But it can't tell, because ICMP is blocked.

    Cheers
    Xeno  
  • 0 in reply to Xeno
    ICMP on Firewall is and was on.  [:(]

    I think it has to do with the exchange of certs.. Although I cannot get PSK working either. 

    I finally enabled a RAS connection in Windows (yeah yeah..) added the registry key to enable and keep alive RAS through logoff/restarts and enabled PPTP/NT Domain auth on the ASL side. 

    This works fine, has the added benefit of making the change from one office to another transparent, and seems to work OK, however it lacks the quality of encryption I wanted for this link.. 

    IPSec will also have to work in the future when another ASL gw goes into the remote office instead of a directly connected windows machine.

    In the meantime we will replace the NetVanta T1 router with a real Cisco and see if it's the cheap NetVanta causing the problem.   
Cookie Information Banner