Re: [Swan] Various problems with VTI on Gentoo (with Cisco IOS as a client)

[Bruno Lopes de Souza Benchimol]

How is the configuration on your cisco-side ?

Cisco sometimes can be tricky. Especially w/ interop issues.


De: Swan  em nome de Reuben Farrelly 

Enviado: segunda-feira, 19 de setembro de 2016 20:07
Para: Paul Wouters
Cc: swan@lists.libreswan.org
Assunto: Re: [Swan] Various problems with VTI on Gentoo (with Cisco IOS as a 
client)

Responding to some but not all of these things for now:

On 20/09/2016 1:44 AM, Paul Wouters wrote:
> On Mon, 19 Sep 2016, Reuben Farrelly wrote:
>
>> I've been experimenting today with Vti based configuration and run
>> into a few problems.
>
> Thanks for testing the VTI support!
>
>> 1. The first problem is when the IPSec completes negotiation.  As
>> soon as the IPsec connects up, I lose all IPv4 access to the remote
>> box. This is made even worse because the public route to the client
>> is also wiped out, so the IPsec session basically kills the
>> connectivity to the box including that of the IPsec session due to a
>> recursive routing loop and more specific /1's for the global routing
>> table:
>>
>> lightning ~ # ip route
>> 0.0.0.0/1 dev vti01  scope link  src 192.168.6.1  mtu 1438
>> default via 139.162.51.1 dev eth0  metric 3
>> 127.0.0.0/8 dev lo  scope host
>> 127.0.0.0/8 via 127.0.0.1 dev lo
>> 128.0.0.0/1 dev vti01  scope link  src 192.168.6.1  mtu 1438
>> 139.162.51.0/24 dev eth0  proto kernel  scope link  src 139.162.51.249
>> lightning ~ #
>>
>> Even with:  vti-routing=no  I still see these routes appear, and
>> experience this problem.
>
> That's odd. with vti-routing=no there should be no VTI specific routing
> changes?

There is.

Here's after a clean reboot:

lightning ~ # ip route
default via 139.162.51.1 dev eth0  metric 3
127.0.0.0/8 dev lo  scope host
127.0.0.0/8 via 127.0.0.1 dev lo
139.162.51.0/24 dev eth0  proto kernel  scope link  src 139.162.51.249
lightning ~ #

The VTI won't come up though.  It fails, as towards the end of the
negotiation the box loses connectivity with the peer and from the
Cisco's perspective never completes negotiation - so I had to add a
route to cover the peer's public subnet:

1.0.0.0/8 via 139.162.51.1 dev eth0

And then the vti comes up on both ends.

What the Cisco does in this situation and what I would expect libreswan
to do is to install a host route to the peer so that when the default
route changes (or when those /1 routes are inserted) we still have
connectivity with the host and can complete the negotiation.

Here's the routing table after the vti comes up:

lightning pluto # ip route
0.0.0.0/1 dev vti01  scope link  src 192.168.6.1  mtu 1438
default via 139.162.51.1 dev eth0  metric 3
1.0.0.0/8 via 139.162.51.1 dev eth0
127.0.0.0/8 dev lo  scope host
127.0.0.0/8 via 127.0.0.1 dev lo
128.0.0.0/1 dev vti01  scope link  src 192.168.6.1  mtu 1438
139.162.51.0/24 dev eth0  proto kernel  scope link  src 139.162.51.249
lightning pluto #

This is with vti-routing=no set.

There is no route for 192.168.6.2 (the client side) but even if I add
one I still get no data flow and error counts increasing on each packet
received.

Still don't know why that 0.0.0.0/1 route is being put there though.

> You seem to have the "half routes" 0/1 and 128/1 installed via the vti
> device. Those are most certainly wrong, but I'm not sure why those were
> installed.
>
>> 2. What I would ideally like to do is have a tunnel interface on the
>> Cisco, and number it with 192.168.6.2/30.  Ideally then on the
>> Libreswan box I would set 192.168.6.1/30 which would give me a proper
>> traditional numbered link.  I only need connectivity across the
>> directly connected subnet (don't want or need any other routes to be
>> reachable just yet - I'm NATting for this purpose in the meantime).
>
> Yes we are adding a leftvti= and rightvti= option to allow updown to
> configure and ip address on the created vti device.

That'll take care of the routing bit nicely I think.

>> The Cisco insists on 0.0.0.0/0 as the src and dst proxy IDs for these
>> sorts of VTI connections on it's side.
>
> It should work fine to set leftsubnet=0.0.0.0/0 and
> rightsubnet=0.0.0.0/0 as long as you set mark="5" or some uniqu number.
> The marking should prevent anything from being directed into the xfrm
> path per default unless it was pointed to the VTI device.

I'm using mark=12/0xff in the config.  I tried using markin= and
markout= as well but those commands were rejected as invalid.

>> How would I configure Libreswan to work in this way?  [This would
>> allow me to match the config I have on the other IPsec Palo Alto head
>> end, and consistency is a great thing!]
>
> Currently, just manually configure the IP address in updown?
>
>> 3. I am seeing packets leave the Cisco across the Cisco Tunnel
>> interface, and I am seeing these packets enter the Libreswan vti.
>> However every single one of them is being dropped:
>>
>> lightning pluto # ifconfig vti01
>> 

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

[Bruno Lopes de Souza Benchimol]

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

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

[Bruno Lopes de Souza Benchimol]

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,

Att,
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:p...@nohats.ca] 
Enviada em: segunda-feira, 5 de setembro de 2016 18:19
Para: Bruno Lopes de Souza Benchimol
Cc: swan@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 
> 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 
> 

> 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

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

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

[Bruno Lopes de Souza Benchimol]

Dear,

  I didnt know much on which list to ask that, but i believe that's a more dev 
situation then users. Its also a double post from swan-dev list. I do not know 
if someone else has the same issue we have here, but here it goes:

 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 

   Here are my configs:

   # conn.conf
conn tjpa-vpn
authby=secret
auto=start
left=10.87.133.6
leftid=10.87.133.6
right=10.87.1.1
rightid=10.87.1.1
leftsubnet=0.0.0.0/0
rightsubnet=0.0.0.0/0
phase2=esp
phase2alg=aes256-sha1;modp1536
mark = 87/0xff
vti-interface=vti-pdp
vti-routing=no

# ip tunnel show
ip_vti0: ip/ip  remote any  local any  ttl inherit  nopmtudisc key 0
vti-pdp: ip/ip  remote 10.87.1.1  local 10.87.133.6  ttl inherit  key 87

# ifconfig vti-pdp
vti-pdp: flags=209  mtu 1480
inet 192.168.168.2  netmask 255.255.255.252  destination 192.168.168.2
tunnel   txqueuelen 0  (IPIP Tunnel)
RX packets 13  bytes 970 (970.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 10  bytes 1528 (1.4 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ip route show
default via 192.168.168.1 dev vti-pdp  proto zebra
10.21.0.0/16 via 10.21.133.1 dev eth0  proto static  metric 100
10.21.133.0/24 dev eth0  proto kernel  scope link  src 10.21.133.3  metric 100
10.87.0.0/16 via 10.87.133.10 dev eth2  proto static  metric 100
10.87.133.0/24 dev eth2  proto kernel  scope link  src 10.87.133.6  metric 100
10.139.0.0/16 dev eth1  proto kernel  scope link  src 10.139.0.20  metric 100
172.18.0.0/21 via 192.168.168.1 dev vti-pdp  proto zebra
192.168.168.0/30 dev vti-pdp  proto kernel  scope link  src 192.168.168.2


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


 Observation: If we do not "wait" to set up ip address, it fails because the 
interface is not created yet.

I think i already explained my scenario (hope thats enough details, even though 
long). As looking into the code and scripts i found _updown.netkey script and 
looked into addvtiiface() function on the following codes:

if [ ! -d "/proc/sys/net/ipv4/conf/${VTI_IFACE}" ]; then
# echo "creating vti interface"
vtipeer="${PLUTO_PEER}"
if [ "${PLUTO_CONN_KIND}" = CK_INSTANCE -o "${VTI_SHARED}" = 
"yes" ]; then
vtipeer="0.0.0.0"
fi
ip tunnel add ${VTI_IFACE} mode vti local ${PLUTO_ME} \
remote ${vtipeer} okey ${CONNMARK_OUT%/*} \
ikey ${CONNMARK_IN%/*}
sysctl -w net.ipv4.conf.${VTI_IFACE}.disable_policy=1
sysctl -w net.ipv4.conf.${VTI_IFACE}.rp_filter=0
sysctl -w net.ipv4.conf.${VTI_IFACE}.forwarding=1
ip link set ${VTI_IFACE} up


Modify here would fix everything. We just need to set the following command 
after the interface is up (or add another function).

 if [ -n "${VTI_IP}" ]; then