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

[Tim Bouwer]

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
today.

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.  

regards
Tim


-----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 


-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "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
edge
    Tim> so I can't use that test on this network.  On the DSL side, there
is

  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
is
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
architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device
driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security
guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBP/ecfYqHRg3pndX9AQHVoQQAoHYdR9Na1Vku54ntOx6+OS0e6TkLeTNA
l1DfX6zW9abm/y9pOve/k57BByOYtD8AnBhGzBbT9iHySuEx1wdMdYG1XQcuWzQp
UWKzCK/CAm24D7XtuG7rG+o6NHua8eNitrSssBYjVe6ok4yYQHR/2sQ72dlqSbio
YWz9f+7fvpw=
=rgQQ
-----END PGP SIGNATURE-----
_______________________________________________
Users mailing list
Users at lists.openswan.org
http://lists.openswan.org/mailman/listinfo/users