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

[MILLET, Laurent]

Hello,

I reviewed the configurations on both sides and they look fine. I do not
understand why the tunnel from A to B is OK, but the one from B to A hangs.
Also the fact that I can swap the two hosts and get exactly the same
behavior (the connection from the first host always works, then the reverse
connection from the second host to the first does not) suggests that the
issue is not with the configuration, but rather an issue with the ipsec
stack itself. Should I file a bug report?

Cheers,
Laurent

On Fri, Nov 22, 2019 at 4:13 PM MILLET, Laurent <
laurent.millet.external at airbus.com> wrote:

> 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/20191129/75ad9e69/attachment.html>