[Swan] Encrypting a single port cluster-wide works in one direction only

MILLET, Laurent laurent.millet.external at airbus.com
Fri Nov 22 15:13:38 UTC 2019


Hello,

I have an application that does not support native channel encryption, so I
am trying to secure the flow using IPsec encryption with libreswan. Using
full host-to-host encryption seemed to work fine, now I am trying to refine
the configuration to encrypt only the communications on the application
port and leave everything else in clear. (I am not sure if this is supposed
to work, but comments in the policy files suggest it should.)

The application works with a cluster of several nodes, each node exposes
the same port for the other nodes. With two nodes only (for testing), the
flow is working in one direction but not in the other:
- When initiating the communication from node A to node B, the IPsec tunnel
is created and the connection succeeds
- Then when initiating the communication from node B to node A, another
IPsec tunnel is created but the connection hangs
- If I invert the roles I have a similar behavior: the first connection
(e.g. B to A) always works, and the second (e.g. A to B) always hangs

Example : initiating the connection from node 004 to node 005 on port 8888,
initially there is no tunnel, the connection creates the tunnel
(certificate DNs edited)
[root at fr0-viaas-004 ~]# ipsec trafficstatus
[root at fr0-viaas-004 ~]# curl fr0-viaas-005:8888/commands/ruok
{
  "command" : "ruok",
  "error" : "This ZooKeeper instance is not currently serving requests"
}
[root at fr0-viaas-004 ~]# ipsec trafficstatus
006 #2: "private-or-clear#0.0.0.0/0-(0--6--8888)"[1] ...10.125.58.148,
type=ESP, add_time=1574434370, inBytes=454, outBytes=415,
id='CN=fr0-viaas-005'
Same tunnel on node 005:
[root at fr0-viaas-005 ~]# ipsec trafficstatus
006 #2: "private-or-clear#0.0.0.0/0-(8888--6--0)"[1] ...10.125.58.146,
type=ESP, add_time=1574434370, inBytes=415, outBytes=454,
id='CN=fr0-viaas-004'

Now initiating a connection from node 005 to node 004:
[root at fr0-viaas-005 ~]# curl fr0-viaas-004:8888/commands/ruok
(hangs...)
[root at fr0-viaas-005 ~]# ipsec trafficstatus
006 #4: "private-or-clear#0.0.0.0/0-(0--6--8888)"[2] ...10.125.58.146,
type=ESP, add_time=1574434661, inBytes=0, outBytes=300,
id='CN=fr0-viaas-004'
006 #2: "private-or-clear#0.0.0.0/0-(8888--6--0)"[1] ...10.125.58.146,
type=ESP, add_time=1574434370, inBytes=415, outBytes=454,
id='CN=fr0-viaas-004'
Tunnels on node 004 (I was not expecting two tunnels for "8888--6--0"):
006 #2: "private-or-clear#0.0.0.0/0-(8888--6--0)"[1] ...10.125.58.148,
type=ESP, add_time=1574434370, inBytes=454, outBytes=415,
id='CN=fr0-viaas-005'
006 #4: "private-or-clear#0.0.0.0/0-(8888--6--0)"[1] ...10.125.58.148,
type=ESP, add_time=1574434661, inBytes=300, outBytes=0,
id='CN=fr0-viaas-005'

I am using opportunistic IPsec (to simplify the configuration for the
cluster) with x509 authentication, with the private-or-clear policy and
restrictions in the policy file to specify the application port.

Configuration for node 004 (same for node 005, except leftcert of course):
conn private-or-clear
        left=%defaultroute
        leftid=%fromcert
        leftcert=fr0-viaas-004
        right=%opportunisticgroup
        rightid=%fromcert
        rightca=%same
        type=tunnel
        ikev2=insist
        authby=rsasig
        narrowing=yes
        negotiationshunt=hold
        failureshunt=passthrough
        retransmit-timeout=10s
        auto=ondemand

/etc/ipsec.d/policies/private-or-clear on node 004 (same on node 005,
except IP address):
# comments only at the beginning of the file
10.125.58.146/0  tcp  8888  0
10.125.58.146/0  tcp  0  8888

I am not including logs as this post is already too long :-) Let me know
what additional information would be relevant and I will gladly provide it.

Regards,
Laurent
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20191122/011d3e7c/attachment.html>


More information about the Swan mailing list