[Swan] xl2tpd does not respond

Bob Miller bob at computerisms.ca
Sun Feb 28 01:56:47 UTC 2016

People were starting to get frustrated so I ripped out pretty much all 
the software, upgraded the box to debian stretch, reinstalled every 
thing and tried again.  l2tp still failed, so I created an ikev2 conn, 
and that is connecting.  so users are back in the system remotely, but I 
haven't found a way to log them into the domain over the vpn yet...

On 16-02-25 08:00 PM, Bob Miller wrote:
> hm, this is interesting.
> Seems I can crash pluto quite reliably, looks like it was reported here:
> https://lists.libreswan.org/pipermail/swan-dev/2015-November/001282.html
> the error is:
> /home/packages/src/libreswan/libreswan.git/programs/pluto/connections.c:316:
> c->spd.this.virt == NULL
> So I rolled back to 3.15, and I still get:
> /usr/src/libreswan-3.15/programs/pluto/ikev1.c:2843: r != NULL
> to be very sure, I did a rm -rf /usr/local/sbin/ipsec
> /usr/local/libexec/ipsec and reinstalled, both versions give same results.
> I have removed all but the l2tp conn from my ipsec.conf.  It is the same
> as a dozen+ other config files I have to compare against.  so I can say
> for sure this is something to do with the l2tp conn.
> conn rw-l2tp-withnat
>     rightsubnet=vhost:%no,%priv
>     also=rw-l2tp-nonat
> conn rw-l2tp-nonat
>     left=
>     leftnexthop=
>     leftcert=firewall.ctfn.ca
>     leftprotoport=17/%any
>     right=%any
>     rightprotoport=17/%any
>     rightca=%same
>     auto=add
>     pfs=no
> On the other hand, if I remove the l2tp conn and just leave the two
> net-to-net conns, pluto runs without error (or apparently any problems).
> hmph.  the investigation continues...
> On 16-02-25 04:38 PM, Bob Miller wrote:
>> Hi,
>> Sorry to pester on this topic again, but I am spinning my wheels.  maybe
>> someone can point out error in my thinking...
>> As a recap, I have added a 2nd internet connection and lan to the
>> existing firewall.  VPN was working fine before.
>>> I tried loading libreswan and xl2ptd on the 2nd internet connection,
>>> just to see what would happen, and discovered an oddness; it seems I
>>> cannot ping from the 2nd connection to IP addresses within my ISP's
>>> range.  can ping the gateway and outside the service area.  would seem
>>> something routing-wise is wobbling, might be the source of the
>>> problem...
>> I trace this down to a missing ip rule command, and all interfaces are
>> working as expected now.  I have added a routing table, and set a fwmark
>> so all traffic from the 2nd lan uses the 2nd routing table and goes out
>> the 2nd internet connection.  both internet connections are on the same
>> subnet, however they both respond on the external and internal side as
>> expected, that is to say I got it all configured so traffic doesn't show
>> up on one connection and leave on another.  At least that I can find.
>> I have also upgraded to the latest libreswan 3.16, but I am still using
>> the original xl2tpd-1.3.1.
>> I have set ipsec saref = no in xl2pd.conf, and compared it closely with
>> a working solution, and find nothing amiss.  I have enabled all debug
>> options, but since there is no connection there is no debug information.
>> xl2tpd is listening on the correct IP address and port 1701, and can
>> receive traffic sent via netcat.  I can TRACE this in iptables, dump it
>> on eth0, and record it on stdout when I run xl2tpd with -D.
>> I have two net-to-net tunnels up and running, all traffic passes fine
>> and the tunnels are stable.  When I connect the road warrior, I also see
>> "IPsec SA established tunnel mode", but when deleting the state, it
>> reports "ESP traffic information: in=0B out=0B".
>> This smells like iptables, but port 1701 is open to regular traffic, and
>> net-to-net tunnels come up.  Why/how could iptables block port 1701 from
>> the roadwarrior's tunnel?
>> I can't seem to trap any udp/1701 traffic in iptables anywhere when
>> connecting from the roadwarrior, I have tried at every stage in the
>> nfpacketflow diagram, as well as using TRACE from the raw table, it
>> really seems to me that the l2tp traffic is not exiting the tunnel.
>> I can confirm that the windows machine does send l2tp to another
>> firewall.
>> For grins and giggles I enabled plutodebug=all, but I see nothing
>> interesting there.
>> The only other thing I can think of that could play into it is
>> protoport.  I currently have both sides set to 17/%any, but have tried
>> all combinations of 17/0, 17/1701, and 17/%any.
>> Does anyone have any suggestions on how I can find out where this l2tp
>> constipation lives?
>> _______________________________________________
>> Swan mailing list
>> Swan at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan

More information about the Swan mailing list