Hi Paul, Thank you for the confirmation! We were following an example from here: https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec (3.3 Assign networks).
Without the priority override it defaults to clear for all connections, so priority was just an attempt to find a workaround (other than not to specify 0/0) Kirill. On Thu, Nov 15, 2018 at 9:51 AM Paul Wouters <[email protected]> wrote: > On Thu, 15 Nov 2018, Kirill Logachev wrote: > > > We were trying to configure LibreSwan opportunistic IPSec in a cluster > with the next configuration. > > conn private > > > > conn clear > > left=%defaultroute > > right=%group > > type=passthrough > > auto=route > > priority=65535 > > I strongly recommend not setting a priority. OE requires some careful > priorities, especially if using it with protocol and port selectors. > > > IP ranges configurations: > > [root@vm0 ipsec.d]# cat policies/clear > > 0.0.0.0/0 > > Don't put 0/0 in the clear group. Just leave it empty. Think of the clear > group as a special override forbidding ipsec. > > > [root@vm0 ipsec.d]# cat policies/private > > 10.0.0.0/24 > > So if you wanted only 10.0.0.13 to be in the clear, you would add that > to the clear group. But for 1.2.3.4 you just want it to match no OE > group, or you put 0/0 in the clear-or-private group, meaning it will > go out in the clear but if others try IKE to you, you will accept it. > > > The expectation is: IPSec is enforced in the cluster subnet & clear is > allowed for everything else.First, we didn't set a priority, but clear > connection has > > higher priority than private in that case. > > When we lower clear priority, libreswan fails to establish a tunnel. > > Paul >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
