Following this thread, wouldn't it be better to have Libreswan ignore
any non-compatible settings when vti-routing=no, and perhaps log
warnings when the conn is loaded, rather than rely on a note on the wiki
which is liable to get overlooked?
Nick
On 2016-09-27 11:45, Reuben Farrelly wrote:
On 27/09/2016 10:40 PM, Tuomo Soini wrote:
On Tue, 27 Sep 2016 21:58:08 +1300
Reuben Farrelly <reuben-libres...@reub.net> wrote:
mtu=1438
That one forces routing too.
Thanks Tuomo. That looks much better now. Is the MTU automatically
calculated if it is not specified?
Paul - perhaps it could be noted on the wiki page that these options
are not compatible with vti-routing=no . It doesn't seem to be
obvious that this is the case.
The one outstanding problem though is if we were to use (the default)
vti-routing=yes, would we not want to insert a host route for the
remote host/endpoint so that the data towards it leaves via the
unencrypted interface? Without it it appears we end up with a
recursive routing situation where the traffic to reach the remote
public device is via the tunnel itself. Currently that route is not
added and my observations a few days ago is that this behaviour breaks
the tunnel once it has almost come up. I was observing IKEv2 almost
not quite going to completion on the client side and a loss of
connectivity to the remote the moment after these routes were
installed.
Reuben
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
