[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:
>
> ASSERTION FAILED at
> /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:
>
> EXPECTATION FAILED at
> /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=205.234.62.3
> leftnexthop=205.234.62.254
> 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