[Openswan Users] DSL modems in bridge mode and UDP fragmentation

[Tim Bouwer]

Hi

I am interested in whether anyone has a list of DSL modems that properly
handle UDP fragments when they are in bridge mode and where no PPPoE is used
as the transport? 

The following is a somewhat lengthy description of the problem and how we
have been uncovering it.  I have written it up in detail so that people with
a similar problem will have some reference material to use since I found few
articles about this after several searches.

We have a business-class DSL connection on the West Coast of the USA where
the carrier (Verizon) only approve two modems for use (Westell 2000 and
Westell 2100).  These modems have to be configured in bridge mode.

We are using Super FreeS/WAN 1.99.7.3 in this case, but this is a general
problem.

When we created a tunnel between this site and another we noticed that the
outbound IKE was failing.  It was reaching State M3 on the DSL side but on
the remote side it was never completing the IKE.   We used tcpdump on each
end and discovered that where the IKE was fragmented (seemingly inevitable
if you use
x509 certificates for authentication), only the first packet in the
fragmented chain was arriving.  All of the others were being discarded.

The DSL side is called branch1 and the remote site is called headoffice.

tcpdump -i eth0 <hostip> udp and host <remotehostip>  - on the sending side;
06:01:09.699671 branch1.isakmp > headoffice.isakmp: isakmp: phase 1 I
ident[E]: [|id] (frag 30873:1480 at 0+)
06:01:09.699691 branch1 > headoffice: (frag 30873:172 at 1480) - on the
receiving side
06:02:28.507581 branch1.isakmp > headoffice.isakmp: isakmp: phase 1 I
ident[E]: [|id] (frag 30873:1480 at 0+)

This rang a bell - there have been a series of discussions on the freeswan
lists about PMTU - along with a overridemtu setting in ipsec.config to allow
for networks that for some reason don't tell you if you have to fragment
packets (a similar symptom described variously as a "black hole router" but
which will cause problems with ipsec traffic as well as the IKE).

However, the initial fragment has a size of 1480 and gets through -
the subsequent fragment is smaller and doesn't.

Another bell that was ringing was that we had experienced problems with
NAT-T and some cable routers which were resolved by ugrading the firmware.
I know that this has nothing to do with IKE, but it created a suspiscion
about the DSL modem.

The business class DSL world apparently use either DSL routers or DSL modems
in bridge mode.  The bridge mode supposedly forwards all packets to the
DSLAM and from there on to the internet.  We have several people using DSL
routers on other carriers and this problem has never come up before.  

We also tested identical models of the Westell modem on residential grade
DSL (with PPPoE) and they worked fine there - we suspect that since the UDP
IKE packets are PPPoE encapsulated they are not handled in the same way by
the modem and therefore not subject to this symptom (since no IP fragment
handling is required of the modem). 

Using google did not yield any likely explanation (at least not with the
search terms I tried) - in particular I was looking for IKE, freeswan, ipsec
related articles and UDP fragments.  We proved to ourselves and to the
people at branch1 that this was unrelated to ipsec by using a home-grown
utility that sends udp packets of a settable size.  This confirmed the
symptom.

It is sort of obvious why this hasn't come up much.  Large UDP packets are
probably only found in tftp, nfs and IKE (any others). tftp and NFS are not
used on public networks (well, hopefully not) and since many VPN solutions
use pre-shared keys which are smallish, the UDP packets in the IKE are small
enough never to need fragmenting.

After several searches on google I stumbled upon an article on the cisco
website - a year old, but describing exactly what we were experiencing and
describing it as a problem with some dsl routers.
<http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/rel3_5_4/354_3kc
l.htm>   
This implies that, since Cisco knows about the issue, they would have
been sure to test their dsl modems for this symptom?  The article is
copywrite to Cisco so I suppose I can't quote it here - the relevant part is
in the caveat section labled CSCdu86399.

I called Verizon tech support and the helpful tier 2 person had a look at
the traffic on the line and was able to confirm that he could not see the
fragments leaving the DSL site but could see them coming in from the
headoffice - another reason to  suspect the modem.

KenB on the freeswan irc channel was helpful in pointing out that he has
used several cisco dsl (600 and 800 series?) modems and the Alcatel
Speedtouch on business class
DSL.

It would be great to get a list of dsl modems in this mode that actually do
handle UDP fragments properly.

I have been in touch with Westell tech support (I send them a copy of this
message) and am 
waiting for more information from them regarding this problem.

... and any further information or comments would be appreciated.

regards
Tim