Strange IPSEC activity over UUNet..

Andy Bradford bradipo at
Sun May 27 20:59:33 UTC 2001

Thus said "Craig Holland" on Fri, 25 May 2001 11:01:24 PDT:

> have any problems.  Then a couple of days ago, my Ricochet connection
> stopped working.  The only common denominator is any connection that passes
> through UUNet/AlterNet doesn't work.  Crazy? I dialup to a Telia pop, no

I can confirm that there are problems when routing IPSEC traffic through 
the UUNet/AlterNet networks.  At work, I have setup VPNs between our 
main corporate offices using FreeS/Wan and the setup run without 
problems for months.  Then a few months ago, the routes that were 
directing the traffic through the network switched to 
route through UUNet/AlterNet---this essentially killed all VPN traffic. 
 We have been working with our upstream provider to discover what the 
problem is, but have not yet been successful at determining the problem.

> problem.  I dial up to a WorldCom POP, no problem. I connect with a Ricochet
> (which goes through UUNet in this case)...broken. I dialup to a UUNet
> pop...broken.  I don't get it.

Yep, same for us.  Everything is fine until the route goes through 
UUNet/AlterNet, at which point it drops to almost nothing.

> The client reports that it is receiving fragmented packets, and that it
> doesn't have the other fragment in its cache.  Its almost like the packets
> are getting fragmented, and then some of those fragments are getting lost.

This also sounds familiar, but I can't confirm this much yet.  This 
basically means that all the packets will have to be retransmitted, 
however, it only does that intermittently.  I have monitored TCP 
traffic closely and it seems that the Window Size never changes, and in 
fact, the outgoing queue for traffic on the port (as displayed with 
netstat -vatn on linux) is very high and very close to the Window Size. 
 In addition, I am seeing a few TCP retransmits of the packets, so 
apparently something is taking a long time to ACK.  Eventually, the 
stream stalls and just sits there with a full outbound queue (full 

> I've checked all my MTUs and circuits. I've reduced my MTU on the client to
> attempt to stop this from happening. I'm running clean as far as I can tell,
> and the good connections through other ISPs tells me my system is working
> OK.  I've pinged my host from the destination network with large packets and
> don't lose any.  Does anyone have any idea what this might be about?  If

Same here.  I have attempted to reduce the MTU on all of our 
interfaces, but it doesn't seem to affect anything.  ping shows decent 
latency and even large ICMP packets go through  fine (with the 
exception of a few).  As of yet, I don't have any more information, but 
I'm sure this is something that will have to be fixed because we just 
can't go forward with a VPN that transfers at 200bps.

[-----------[system uptime]--------------------------------------------]
  2:59pm  up 18 days, 17:36,  4 users,  load average: 1.07, 1.16, 1.19

More information about the NANOG mailing list