[strongSwan] Services unreachable after first connection

[Tasslehoff Burrfoot]

Hi Tobias and thanks again for your time,

> Are new TCP connections created or is the same connection used for
> several searches?  Are there constantly packets exchanged in these
> tests?  If not, for how long is there no traffic?

All the TCP connections are brand new, during my test I used a very
simple ldap searches to reduce the amount of data involved (anche make
the dump mure readable).
Every single successfull ldapserch involves around 12 packets and
around 3.6KB of data transfer completed in around 0.1 seconds, the
most significant amount of data between hosts involves the search
result which is around 2KB, there's no continuos flaw of data during
the test.

This is a cool example --> https://sc.burrfoot.it/tcpdump.jpg
I made an ldapsearch request to host 10.128.4.16 with ok result
(packet 1-12), after that I suddenly repeated the same ldapsearch and
It was stuck, and after 60 seconds ldapsearch returned error
"ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)", that's the
result (packet 13-37).

> Interesting.  Maybe some 5 minute client-IP block after certain traffic
> patterns?  Or perhaps some timeout.

Seems strange, I mean if there was some specific block after certain
traffic I don't understand why everything works perfectly if I keep
making tcp connections on 389 every 5 seconds with my keepalive
script.
As you can see from the screenshot I linked before, even if I wasn't
able to complete the ldapsearch there's still some strange data
flagged as "TCP Spurious Retransmission" coming from the host on the
other side of the vpn.

The more I looked to it the more I feel there's something strange on
the other side of the VPN, something like a weird security appliance
which temporarily block traffic; it's strange this is not happening
with those nmap loops, maybe it doesn't trigger the same logic because
it's a basic SYN-ACK-RESET connection and does not involve any
significant data through it.

> Depends on what exactly is going on.  It definitely sounds like a
> firewall issue (either affecting the ESP packets or traffic after the
> tunnel).  You'd have to debug where exactly packets get stuck (e.g.
> whether ESP packets are sent, if they reach the peer or where they are
> dropped, how far decrypted TCP packets get, if a response is sent, if
> that's encapsulated in ESP again, where those may get dropped and so
> on).  Use packet counters or captures to do so.

Thank you for your suggestions, I'll dig deeper, now I'm trying to
understand if it's possible to do some checks also on our customer's
side.

Thanks

Tas

---
"Arguing that you don't care about the right to privacy because you
have nothing to hide is no different than saying you don't care about
free speech because you have nothing to say."