[Openswan Users] PPP issues (was Re: openswan + l2tpd + iptables problem)

[Paul Wouters]

On Mon, 23 Oct 2006, mechanix at debian.org wrote:

> > > 22:57:44.146242 IP GW.IP.ADDR.ESS.4500 > REM.OTE.ADDR.ESS.4500: UDP-encap: ESP(spi=0xb1f325b8,seq=0x10), length 52
> > > 22:57:46.267167 arp who-has REM.OTE.ADDR.ESS tell GW.IP.ADDR.ESS
> > > 22:57:48.969962 IP REM.OTE.ADDR.ESS.4500 > GW.IP.ADDR.ESS.4500: UDP-encap: ESP(spi=0x537cb518,seq=0x17), length 76
> > > 22:57:48.975399 arp who-has REM.OTE.ADDR.ESS tell GW.IP.ADDR.ESS
> > > 22:57:49.975476 arp who-has REM.OTE.ADDR.ESS tell GW.IP.ADDR.ESS
> > > 22:57:50.975562 arp who-has REM.OTE.ADDR.ESS tell GW.IP.ADDR.ESS
> >
> > > Oct 19 22:57:42 scotos l2tpd[20820]: ourtid = 12824, entropy_buf = 3218
> >
> > Does the problem go away with xl2tpd ? We did quite some fixing of the l2tpd code.
>
> Unfortunately, not. Well, actually I seem to run into a different problem
> again -- with xl2tpd I now get this in /var/log/debug (and nothing more):
>
> Oct 23 16:04:45 scotos l2tpd[27457]: control_finish: Peer requested tunnel 4 twice, ignoring second one.
> Oct 23 16:04:50 scotos last message repeated 2 times
> Oct 23 16:04:55 scotos l2tpd[27457]: Unable to deliver closing message for tunnel 18614. Destroying anyway.
> Oct 23 16:05:08 scotos l2tpd[27457]: control_finish: Peer requested tunnel 4 twice, ignoring second one.
> Oct 23 16:05:10 scotos l2tpd[27457]: Unable to deliver closing message for tunnel 62456. Destroying anyway.

those can be "ignored" (see other posts). They are not the cause for not starting pppd.

> pppd never gets started this time.
>
> Running tcpdump at the same time shows that arp packets are still lost,
> I see the same arp who-has queries as before.

I am not sure what is causing that. Run ipsec verify. Are there no "redirect" warnings?
Try changing the mtu on the external interface of the l2tp server to 1472, or even 1400

> I also tried with not iptables rules at all just to make sure nothing was
> in the way there but the results were the same.

If that doesn't resolve it. can you recompile xl2tpd with debugging enabled and
run it in the foreground and see if that will show us something?

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155