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

[Reuben Farrelly]

Hi again,

On 23/09/2016 10:09 AM, Paul Wouters wrote:
> On Tue, 20 Sep 2016, Reuben Farrelly wrote:
>
>> 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
>
> My guess is this would resolve your issue:
>
> diff --git a/programs/_updown.netkey/_updown.netkey.in
> b/programs/_updown.netkey/_updown.netkey.in
> index 3031ac5..2fd1a83 100644
> --- a/programs/_updown.netkey/_updown.netkey.in
> +++ b/programs/_updown.netkey/_updown.netkey.in
> @@ -481,9 +481,6 @@ doroute() {
>
>      case "${PLUTO_PEER_CLIENT}" in
>         "0.0.0.0/0")
> -           # need to provide route that eclipses default, without
> -           # replacing it.
> -           it="ip route $1 0.0.0.0/1 ${parms2} && ip route $1
>             128.0.0.0/1 ${parms2}"
>             ;;
>         *)
>             it="ip route $1 ${parms} ${parms2}"
>
>
> We should probably check for the conn doing VTI and skip it in that
> case.
>
> Can you test this and let me know?
>
> Paul

Thanks Paul.  That fixes things up quite a bit - it works for me.

The other fix which will help things quite a bit more (currently this is 
something I have to hack manually) is when the leftvti= and rightvti= 
options are committed and part of the configuration.  This seems to be 
the missing piece of the puzzle.  How far away are these options from 
being committed to git -master ?

Things seem to now be working, after a few machine restarts.  I'm still 
not convinced it is robust, but it's better than it was before in that 
it is more or less working.  Once some of these easy things are fixed up 
I can start to test it for reliability.

There are some cosmetic oddities which look odd yet don't seem to be a 
big problem from running 'ipsec status':

000 "router-2.reub.net":   IKE algorithms wanted: 
AES_CBC(7)_256-SHA1(2)-MODP1536(5)
000 "router-2.reub.net":   IKE algorithms found: 
AES_CBC(7)_256-SHA1(2)-MODP1536(5)
000 "router-2.reub.net":   ESP algorithms wanted: AES(12)_128-SHA1(2); 
pfsgroup=MODP1536(5)
000 "router-2.reub.net":   ESP algorithms loaded: AES(12)_128-SHA1(2)
000 "router-2.reub.net"[1]: 
0.0.0.0/0===139.162.51.249<139.162.51.249>[@lightning.reub.net]...1.129.83.190[router-2 at reub.net]===0.0.0.0/0; 
erouted; eroute owner: #2
000 "router-2.reub.net"[1]:     oriented; my_ip=192.168.6.1; their_ip=unset

1. ESP algorithms loaded is not the same as ESP algorithms wanted or 
found.  Is this supposed to be this way?

2.  their_ip=unset .  Should this be unspecified?  In my case I would 
have thought this would have been the far end VTI IP (for a numbered link)

000 #2: "router-2.reub.net"[1] 1.129.83.190 esp.5c6fe196 at 1.129.83.190 
esp.28bcdccd at 139.162.51.249 tun.0 at 1.129.83.190 tun.0 at 139.162.51.249 
ref=0 refhim=0 Traffic: ESPin=63KB ESPout=61KB! ESPmax=0B

3.  What's the reference to tun.0 ?  That doesn't match up with any 
interface on my system.

4.  Also:

vti01: ip/ip remote any local 139.162.51.249 ttl inherit key 12 . We 
know the remote end IP, should this really be 'any' ?

5.  'ipsec auto --rereadall' barfs:

lightning ~ # ipsec auto --rereadall
002 forgetting secrets
002 loading secrets from "/etc/ipsec.secrets"
002 loading secrets from "/etc/ipsec.d/router-2.reub.net.secrets"
003 ERROR "/etc/ipsec.d/router-2.reub.net.secrets" line 1: index "%any%" 
illegal (non-DNS-name) character in name
lightning ~ #

The .secrets file has:    @lightning.reub.net %any% : PSK "<removed>"

However the service it is happy to start up, but not reload.

Thanks,
Reuben