Hello!

I am following the official guide to setup ispec connection among m
openshift nodes
https://docs.openshift.org/latest/admin_guide/ipsec.html


The doc mentions
For private policy (/etc/ipsec.d/policies/private),  "if the remote host’s
certificate does not authenticate, all traffic between the two hosts will
be blocked".

For clear policy(/etc/ipsec.d/policies/clear), "additional hosts and
subnets may be added to this file, which will result in all traffic to
these hosts and subnets being unencrypted".

Then what if a subnet is neither included in "private" nor "clear"? Should
traffic from cluster node to that subnet be blocked or just unencrypted?
>From my test, traffic from cluster node to that "undefined" subnet is not
block and in clear. Then what's the point to define "clear" policy?

By the way, is the ipsec setup described in the official document
production ready or recommended? I found sometimes communication must be
initiated by a certain node , otherwise other node cannot reach it.



My environment and test results:

OS: centos 7.4 x86_64
libreswan: libreswan-3.20-5.el7_4.x86_64
openshift: v3.9


/etc/ipsec.d/openshift-cluster.conf:

conn private
  left=%defaultroute
  leftid=%fromcert
  # our certificate
  leftcert="NSS Certificate DB:system:node:<host-fqdn>"
  right=%opportunisticgroup
  rightid=%fromcert
  # their certificate transmitted via IKE
  rightca=%same
  ikev2=insist
  authby=rsasig
  failureshunt=drop
  negotiationshunt=hold
  auto=ondemand

conn clear
  left=%defaultroute
  right=%group
  authby=never
  type=passthrough
  auto=route
  priority=100



/etc/ipsec.d/policies/private:
# all my openshift cluster nodes
10.65.150.31/32
10.65.150.32/32
10.65.150.33/32
10.65.150.36/32
10.65.150.37/32
10.65.150.38/32
10.65.150.39/32

all other polcy files are empty
/etc/ipsec.d/policies/block
/etc/ipsec.d/policies/clear
/etc/ipsec.d/policies/clear-or-private
/etc/ipsec.d/policies/private-or-clear


[root@node31a ~]# ipsec whack --trafficstatus
006 #20: "private#10.65.150.32/32"[1] ...10.65.150.32, type=ESP,
add_time=1525872506, inBytes=0, outBytes=0, id='O=system:nodes,
CN=system:node:node32a.lab.local'
006 #18: "private#10.65.150.32/32"[1] ...10.65.150.32, type=ESP,
add_time=1525872506, inBytes=0, outBytes=0, id='O=system:nodes,
CN=system:node:node32a.lab.local'
006 #7: "private#10.65.150.36/32"[1] ...10.65.150.36, type=ESP,
add_time=1525872391, inBytes=3017534, outBytes=500490, id='O=system:nodes,
CN=system:node:node36a.lab.local'
006 #8: "private#10.65.150.36/32"[1] ...10.65.150.36, type=ESP,
add_time=1525872391, inBytes=7420713, outBytes=36955784,
id='O=system:nodes, CN=system:node:node36a.lab.local'
006 #10: "private#10.65.150.37/32"[1] ...10.65.150.37, type=ESP,
add_time=1525872423, inBytes=0, outBytes=10320, id='O=system:nodes,
CN=system:node:node37a.lab.local'
006 #15: "private#10.65.150.37/32"[1] ...10.65.150.37, type=ESP,
add_time=1525872455, inBytes=4291092, outBytes=4017801, id='O=system:nodes,
CN=system:node:node37a.lab.local'
006 #16: "private#10.65.150.38/32"[1] ...10.65.150.38, type=ESP,
add_time=1525872461, inBytes=0, outBytes=0, id='O=system:nodes,
CN=system:node:node38a.lab.local'
006 #13: "private#10.65.150.38/32"[1] ...10.65.150.38, type=ESP,
add_time=1525872445, inBytes=0, outBytes=0, id='O=system:nodes,
CN=system:node:node38a.lab.local'

# note 10.65.150.34 is not included in any policy
[root@node31a ~]# ping 10.65.150.34
PING 10.65.150.34 (10.65.150.34) 56(84) bytes of data.
64 bytes from 10.65.150.34: icmp_seq=1 ttl=64 time=0.921 ms
64 bytes from 10.65.150.34: icmp_seq=2 ttl=64 time=0.303 ms
64 bytes from 10.65.150.34: icmp_seq=3 ttl=64 time=0.352 ms
64 bytes from 10.65.150.34: icmp_seq=4 ttl=64 time=0.317 ms
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to