<div dir="ltr"><div>Thanks you very much Tobias, I have another question.<br>During some tests I noticed that if I let run a simple script (basically a loop cycle with "nmap -sT -P0 -p 389 10.128.4.15 10.128.4.16" and 5 seconds sleep) to test 389 port on the two destination AD domain controllers, every ldapsearch action (or in general every action that involves a connection to 389 port of those two domain controllers) works perfectly fine and nmap always returns 389 port open.</div><div>If I stop the nmap loop cycle after a few ldapsearch runs I got problems, connection to ldap stuck and nmap test returns 389 port filtered.</div><div><br></div><div>I noticed that 389 port result unreachable for exactly 300 second, after that nmap detects it open again.<br><br>I added some debug parameters to my ipsec.conf file (charondebug="ike 2, knl 2, cfg 2") but I didn't noticed something significant when the ldap connection get stuck or opens again after 5 minutes.</div><div><br></div><div>Can be anything related to some dpd or keepalive feature? </div><div><br></div><div>Best regards</div><div><br></div><div>Tas</div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div><span style="font-size:12.8px">---</span><br style="font-size:12.8px"><span style="font-size:12.8px;color:rgb(153,153,153)"><i>"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."</i></span><br></div><br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 5, 2020 at 10:12 AM Tobias Brunner <<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Tas,<br>
<br>
> Do you think this strange behaviour can be cause by our strongswan<br>
> configuration?<br>
<br>
One thing that comes to mind in regards to TCP over IPsec are MTU/MSS<br>
issues [1].  But those would only have an effect on larger transmits,<br>
not on the initial TCP handshake.  That is, you should be able to create<br>
a new TCP connection even after another stalled.  If that's not the<br>
case, some firewall or routing issue could be the culprit (or a problem<br>
with the IPsec tunnel on the other end).<br>
<br>
By the way, you'll never see outbound plaintext traffic (e.g. a TCP SYN)<br>
in tcpdump [2].<br>
<br>
Regards,<br>
Tobias<br>
<br>
[1]<br>
<a href="https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues" rel="noreferrer" target="_blank">https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues</a><br>
[2]<br>
<a href="https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Capturing-outbound-plaintext-packets-with-tcpdumpwireshark" rel="noreferrer" target="_blank">https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Capturing-outbound-plaintext-packets-with-tcpdumpwireshark</a><br>
</blockquote></div>