Dear Paul,

 That's correct. The tunnel will be able to pass anything (0.0.0.0/0), and then 
the routing protocol will decide. 

That's also open up many deployment scenarios, based on individual needs: 

On my setup here i tried the following working scenario w/ BGP:
a) inject default route on remote end.
b) inject routes (eg. 66.66.66.0/24) on the remote end
c) inject routes (eg 77.77.77.0/24) on the hub end.

Best regards,
________________________________________
De: Paul Wouters <p...@nohats.ca>
Enviado: quarta-feira, 14 de setembro de 2016 13:13
Para: Bruno Lopes de Souza Benchimol
Cc: swan@lists.libreswan.org
Assunto: Re: RES: [Swan] feature request - route based (vti) vpn - ip address 
on tunnel interfaces

On Tue, 6 Sep 2016, Bruno Lopes de Souza Benchimol wrote:

>  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.
>

I'm still trying to understand the deployment here. Am I correct in that
you setup an IPsec 0.0.0.0/0 to 0.0.0.0/0 tunnel between the two IP
addresses on the VTI interface? And that the routing daemons will
then just add routes? Eg if the routing daemons want to send traffic
for 66.66.66.0/24 to the other end, it will just route it to the
remote VTI IP via dev vti0 ?

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

I think so. I'd like to add it for libreswan-3.19

Paul

--
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.

_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to