[Openswan Users] DSL modems in bridge mode and UDP fragmentat ion

Tim Bouwer TBouwer at pfn.com
Thu Jan 8 09:42:23 CET 2004

Hi Michael

Well, yesterday I had an opportunity to take three different Westell modems
to a local Business Class Verizon circuit here in Boston where we were able
to connect the ipsec gateway directly to each ADSL modem in turn.

The modems all behaved very well with no dropped UDP fragments.  The tunnel
came up without any problems with even the oldest Westell.

Your instinct that there is something else on that network doing this
appears to be right on the mark! 

In the meantime we have the work-around that you suggested and are waiting
to test it on site.   Viz. branch1, where the fragments are being dropped
does not send its certificate when requested to and the data center side has
both its own and branch1's certificates when it goes to create the tunnel.
This turned out to be a little more than just disabling the send cert on the
one side because, depending on which side initiated the connection, the
expected next header fields did not always line up properly.

I was not able to test the changes that you made in openswan 2 since we are
using superfreeswan 1.99 out there. 

Later will post a list of modems that I test on the RAW Verizon ADSL circuit
to the list.  I have an Alcatel Speedtouch which I want to take out there

When we uncover it, I will also post what it is that caused this symptom.
We have asked for any ACL's on the switch to be disabled to determine if
that is the point of failure.  I understood that it was only icmp requests
that were being blocked but it seems likely now that there are more entries
in that list.

Thanks again for your help.  


-----Original Message-----
From: Michael Richardson [mailto:mcr at sandelman.ottawa.on.ca]
Sent: Saturday, January 03, 2004 11:54 PM
To: Tim Bouwer
Cc: users at lists.openswan.org
Subject: Re: [Openswan Users] DSL modems in bridge mode and UDP
fragmentat ion 


>>>>> "Tim" == Tim Bouwer <TBouwer at pfn.com> writes:
    Tim> There is no NAT or QoS.

    >>> What happens if you just do:

    >>> ping -s 5000 remoteend

    Tim> They (not the ISP's, the people we are installing the VPN gateways
    Tim> for) have acls preventing regular ICMP replies on their network
    Tim> so I can't use that test on this network.  On the DSL side, there

  Have this turned off. There is no point. 
  If you want to break your network, then you get problems with this. 
  ICMP is there for diagnostics.

  Also, many firewalls think they can not pass fragments onwards, because
they can't examine them. Maybe that CISCO is in fact the problem.
  A diagram would help.

    >>> If that breaks, your network is broken, and you should get a better
    >>> ISP.

    Tim> The problem is that this is a small town in Washington and I am
    Tim> being told that Verizon is the common ISP (well they are being

  That may be true, but it doesn't mean that they should provide you with no
service. As you point out, fragmented UDP packets are not common on WANs.

    Tim> So the problem is actually very similar when NAT-T comes into play
    Tim> since all communication is UDP - although the ESP packets would
    Tim> never be IP fragments and therefore are not be subject to this
    Tim> symptom.

  No, it is not the same problem.
  The PMTU problem is about packets that go through the tunnel. The tunnel
too small for them. (Smaller again with NAT-T)

  This is about packets on the outside.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device
] panic("Just another Debian GNU/Linux using, kernel hacking, security
guy"); [
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

Users mailing list
Users at lists.openswan.org

More information about the Users mailing list