I thought we had some test cases for this use case. I will have a look at this next week.
Paul Sent from my iPhone > On Nov 29, 2019, at 16:17, MILLET, Laurent > <[email protected]> wrote: > > 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 >> <[email protected]> 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@fr0-viaas-004 ~]# ipsec trafficstatus >> [root@fr0-viaas-004 ~]# curl fr0-viaas-005:8888/commands/ruok >> { >> "command" : "ruok", >> "error" : "This ZooKeeper instance is not currently serving requests" >> } >> [root@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@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@fr0-viaas-005 ~]# curl fr0-viaas-004:8888/commands/ruok >> (hangs...) >> [root@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. > _______________________________________________ > Swan mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
