[Swan] VTI interface ip tunnel missing endpoint ip

[Rav Ya]

Hi Paul,



Thank you for your time.



I switched to XFRMi and bumped into a different issue.


Apr 25 17:56:49.800303: | route owner of "gateway02"[1] 10.11.0.2 unrouted:
"gateway01"[1] 10.11.0.1 erouted; eroute owner: "gateway01"[1] 10.11.0.1
erouted
Apr 25 17:56:49.800310: "gateway02"[1] 10.11.0.2 #3: cannot route -- route
already in use for "gateway01"[1] 10.11.0.1



   - Is there a way to turn off routing for XFRMi interface? (Similar to
   vti-routing=no)



   - With the older release (LibSwan 3.25) I was able to set up multiple
   VTIs (routing disabled) but the IP-IP Tunnel End Points were the same
   across all the VTIs IP-IP (*link/ipip 10.11.0.254 brd 0.0.0.0*) which
   was causing an issue when I had more than one tunnel.



   - On my VPN server, I am using right=%any because of the dynamic nature
   of my client’s tunnel endpoint IP. To differentiate between the connections
   I am using righid=@dummyN (This is allocated to every client).



   - For my scenario, I can’t even use modeconfig because I have to
   preserve remote subnet IPs sitting behind the IPSec clients. (Plan is to
   run iBGP across IPSec).



   - Any suggestion/recommendation or read up material would be highly
   appreciated. Thank You



*Libreswan IPSec Config:*



config setup

        uniqueids=no



conn %default

        ike=3des-sha1-modp2048

        esp=aes256-md5-modp2048

        dpdaction=clear

        dpddelay=30s

        dpdtimeout=90s

        ikev2=insist

        rekey=no

        ikelifetime=24h

        lifetime=24h

        authby=secret

        left=10.11.0.254

        leftsubnet=0.0.0.0/0

        leftid=@libswan

        right=%any

        rightsubnet=0.0.0.0/0

        replay-window=0

        nic-offload=auto

        type=tunnel

        auto=add



conn gateway01

        rightid=@dummy01

        ipsec-interface=yes



conn gateway02

        rightid=@dummy02

        ipsec-interface=yes



Thank You,

Rav ya


On Sat, Apr 25, 2020 at 3:35 PM Paul Wouters <paul at nohats.ca> wrote:

> Multiple VTI tunnels with right=%any is not possible. It is a design
> limitation of VTI and why XFRMi was created.
>
> Paul
>
> Sent from my iPhone
>
> On Apr 25, 2020, at 13:17, Rav Ya <ravin.ya90 at gmail.com> wrote:
>
> 
> Hello All,
>
> Can someone please advise me on the below.
>
>
> *Overview of my configuration:*
>
> The righsubent and leftsubnet on the Libreswan VPN server are set to
> 0.0.0.0/0. The plan is to run iBGP over IPSec. On my server-side. I have
> set right=%any (For my use case this is unknown). I have enabled the
> vti-interface with routing turned off so that I can run iBGP across IPSec.
>
>
>
> On my test setup, I have client tunnel endpoint: 10.11.0.1 and server
> endpoint 10.11.0.254.
>
>
>
> *Observation:* On the Libreswan Server
>
> The tunnel is established as desired:
>
> *0.0.0.0/0===10.11.0.254
> <http://0.0.0.0/0===10.11.0.254><10.11.0.254>[@libswan]...10.11.0.1[@dummy01]===0.0.0.0/0
> <http://0.0.0.0/0>; erouted;*
>
>
>
> But the VTI (IP-IP Interface) configured by Libreswan does not define the
> client tunnel endpoint.
>
>
> *ipsec01 at NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN
> mode DEFAULT group default qlen 1000    link/ipip 10.11.0.254 brd 0.0.0.0*
>
>
>
> *Questions:*
>
> In my knowledge we should read the endpoint IP (10.11.0.1) and use it for
> configuring the IP tunnel. Is my understanding correct? or am I missing
> something?
>
>
>
> This works just fine for a single tunnel but when I have multiple tunnels
> with individual VTI interface all set to  link/ipip 10.11.0.254 brd 0.0.0.0
> the ESP packets get dropped. The ESP packets are seen on the outer
> interface but they don't get routed to the respective VTI interface and are
> dropped.
>
>
>
> Will switching to route based XFRMi (ipsec-interface) help in this case?
>
>
>
> Regards,
>
> -Rav ya
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20200425/6c7e848d/attachment-0001.html>