[Swan-dev] ip_vti0 preventing proper routing in updown ?

Paul Wouters paul at nohats.ca
Fri Jul 6 16:49:44 UTC 2018


This is the 2nd report I get of updown not working properly, and
removing the vti kernel module, that removes the ip_vti0 interface,
resolves the issue ?

Should we revert configuring obtained IP addresses on the loopback?
Or can we do something else prventing the bad interaction with ip_vti0 ?

Note that no vti-* options or marking was used for this configuration.

Paul

-------- Forwarded Message --------
Subject: vpn.nohats.ca setup - fixed
From: Francesco Giudici <fgiudici at redhat.com>
To: Paul Wouters <pwouters at redhat.com>
Date: Fri, 6 Jul 2018 11:24:50 +0200

I found the root cause of the issues I was experiencing with the setup.
I had two issues:
1) the ""vpn.nohats.ca": We cannot identify ourselves with either end of
this connection.  193.110.157.148 or 193.110.157.148 are not usable" error
2) bypassing 1 with left=%MYIP, I was not able to route/forward
correctly packets through the VPN, resulting in no traffic

TL;DR: when starting ipsec I noticed the ip_vti kernel module is loaded.
When loaded, it creates a default interface ip_vti0. Removing the module
before adding the vpn.nohats.ca connection fixed both issues 1 and 2.
Everything worked as expected.

-- long version --
Diagnosing issue 2) I found the network config looked weird: the address
gained from CP was added to the lo interface. The new default routes so
where added as "link scope". Mangling the network (I moved the CP
address on the main interface and updated the routes) I was able to let
packet flow through the VPN (I could see the ESP packets going in both
directions) but still not end to end connectivity...
I noticed that the clear text traffic arrived on a ip_vti0 interface...
so, removing the ip_vti module before starting the connection did the trick.

All of this on F28, both Desktop and client.



More information about the Swan-dev mailing list