[Swan] RES: feature request - route based (vti) vpn - ip address on tunnel interfaces

Bruno Lopes de Souza Benchimol bruno.benchimol at tjpa.jus.br
Tue Sep 6 19:18:55 UTC 2016

Dear Paul,

You're 100% correct. The args and vars seems easier to understand the way you said.

 On the last comment, that's right, we do not need to remove the IP as it goes down when we 'destroy' the interface. I was just pointing that we would use that on tunnel interface on  /30 subnet, it would be impossible to use this interface as shared. (At least when thinking on routing protocols).

  Im also glad to hear that you also think its a cool feature to add. Im not exactly a developer but i think that should be fairly easy to devel. I wish i could help more on the code part, but i can help on testing it.

  Do you think we can get it on a roadmap to implement on a next version?

 Best regards,

Bruno Benchimol

Tribunal de Justiça do Estado Pará
Chefe do Serviço de Segurança e Sistemas Básicos
(91) 3250-8383

-----Mensagem original-----
De: Paul Wouters [mailto:paul at nohats.ca] 
Enviada em: segunda-feira, 5 de setembro de 2016 18:19
Para: Bruno Lopes de Souza Benchimol
Cc: swan at lists.libreswan.org
Assunto: Re: [Swan] feature request - route based (vti) vpn - ip address on tunnel interfaces

On Mon, 5 Sep 2016, Bruno Lopes de Souza Benchimol wrote:

>  I would like to request a new feature. Let me explain our scenario and what we trying to do libreswan:

>   We have on our Datacenter, a Palo Alto device that does handle as 
> our VPN Server (IPsec) to multiple sites, and we use dynamic routing protocols (BGP and OSPF) -- currently BGP on the VPN side. We can make it properly work w/ other Palo Alto and Cisco devices.

>    The following links describes what we need to configure on devices:
> https://live.paloaltonetworks.com/twzvq79624/attachments/twzvq79624/do
> cumentation_tkb/525/1/How_to_Configure-Dynamic_Routing_over_IPSec_agai
> nst_Cisco-vc.pdf

>    We have many sites that we are using Linux, and we choose Libreswan 
> to be our VPN IPsec software. We first started using policy based VPN 
> but we quickly found a problem: Dynamic Routing Protocols did not work as expected. The real trick is that routing protocols demand IP on tunnel interfaces to work properly and exchange adversites and routing protocol information. I was glad i found VTI support on the beta release, that really solves the issue, as i have a tunnel interface to route thru.
>    I quickly found the problem. We need to have configured IP on the 
> tunnel interface, and libreswan did not the manage that to do it properly. We could get the tunnel UP with properly local/remote ip address, but the interface did not have IP address (which is required to by routing protocols).
>   What we need to do is configure one ip address, like 
> on site A (palo alto) and on site B, 
> and the local and remote tunnel which are the real ip address that we 
> use to connect (that works good). To solve the issue i had to manually 
> set the ip address by myself: # ip addr add dev 
> <vti-interface>

> So its fully working as i would like. I had to do a nasty workaround with systemd to get it working:
> I had to add to ipsec.service ->
> ExecStartPost=/opt/set-tunnel-ip.sh
> # cat /opt/set-tunnel-ip.sh
> #!/bin/bash
> sleep 5
> ip addr add dev vti-pdp

>     Also, we need to modify to read {VTI_IP} from the configuration file. I would suggest another keyword:
>     vti-ip=

I think this is a good idea, and we should add support this. Although I would prefer to use:


While you can leave out one of these, it keeps the idea that you can use the same config on both endpoints.

This would also translate in the updown scripts to MY_VTI_IP and PEER_VTI_IP

>     I believe the modifications should be fairly easy to implement. It 
> should not be compatible with vti-shared as each tunnel must have its own unique ip. And by adding this feature it would make libreswan compatible with most VPN software (commercial) w/ Route based and Dynamic Routing Protocols.
>      I would like to hear back from you guys if that's possible to do, and i believe it should not be much hard to implement.

I guess since this option would only be used with vti-shared=no, we wouldn't need to delete the IP from the VTI device, as the entire device will be removed from the system when the connection goes down.


This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the Swan mailing list