[strongSwan] Services unreachable after first connection
tasslehoff at burrfoot.it
Tue Jun 9 16:51:36 CEST 2020
Thanks you very much Tobias, I have another question.
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.
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.
I noticed that 389 port result unreachable for exactly 300 second, after
that nmap detects it open again.
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.
Can be anything related to some dpd or keepalive feature?
*"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."*
On Fri, Jun 5, 2020 at 10:12 AM Tobias Brunner <tobias at strongswan.org>
> Hi Tas,
> > Do you think this strange behaviour can be cause by our strongswan
> > configuration?
> One thing that comes to mind in regards to TCP over IPsec are MTU/MSS
> issues . But those would only have an effect on larger transmits,
> not on the initial TCP handshake. That is, you should be able to create
> a new TCP connection even after another stalled. If that's not the
> case, some firewall or routing issue could be the culprit (or a problem
> with the IPsec tunnel on the other end).
> By the way, you'll never see outbound plaintext traffic (e.g. a TCP SYN)
> in tcpdump .
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users