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/documentation_tkb/525/1/How_to_Configure-Dynamic_Routing_over_IPSec_against_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 192.168.168.1/30 on site
A (palo alto) and 192.168.168.2/30 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 192.168.168.2/30 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 192.168.168.2/30 dev vti-pdp
Also, we need to modify to read {VTI_IP} from the configuration file. I
would suggest another keyword:
vti-ip=192.168.168.2/30
I think this is a good idea, and we should add support this. Although I would
prefer to use:
leftvti-ip=192.168.168.2/30
rightvti-ip=192.168.168.1/30
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.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
