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[[email protected]]===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 [email protected]
[email protected] [email protected] [email protected]
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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
