<div dir="ltr">Hi everyone, I just joined the ML, first of all thank you for your patience and help; I don't have a huge experience with vpn in general and this is the 1st time I used strongswan.<div><div><br></div><div>Recently I setup up a test environment for a project where the objective was to implement kerberos SSO between one of our application servers (10.1.0.137, an AWS EC2 instance which runs some J2EE applications) and one of our customers Active Directory domain (10.128.4.15, 10.128.4.16 are the two domain controllers), after that the application have to search for some user attributes using AD as ldap directory.<br>To archive this I managed to setup a site-to-site ipsec vpn between our systems and our customer datacenter, on our side I used another EC2 instance as vpn endpoint (10.1.0.144, which is behind NAT by AWS with a public ip 74.74.74.74) using CentOS 7 and strongswan 5.7.2, on our customer side I don't have control or visibility, the only thing I know is that the vpn endpoint should be a Fortinet appliance with a public ip (217.217.217.217).<br><br>You can see the whole architecture on this png <a href="https://sc.burrfoot.it/vpn.png" target="_blank">https://sc.burrfoot.it/vpn.png</a><br><br>The vpn setup went pretty smooth:<br>- tunnel established (<a href="https://sc.burrfoot.it/strongswan.png" target="_blank">https://sc.burrfoot.it/strongswan.png</a>)<br>- I made my application server to use our vpn endpoint as gateway for the two domain controllers with a static route<br>- adjusted EC2 security groups to allow kerberos and ldap communication (TCP and UDP 88 for kerberos, TCP 389 for ldap), on the other side our customer sysadmin did the same on his firewall.<br>- no masquerade rules on our vpn endpoint because our customer allowed requests from our application server internal ip.<br><br>Everything seeems ok and a quick test using nmap from the application server (10.1.0.137) worked pretty well (<a href="https://sc.burrfoot.it/nmap.png" target="_blank">https://sc.burrfoot.it/nmap.png</a>), but after some tests (some basic ldapsearch queries) I noticed the ldap did not respond anymore, so I tried on the second domain controller and it worked... after that also the second domain controller did not respond anymore.<br>At this point I made another nmap test which resulted in traffic filtered (<a href="https://sc.burrfoot.it/nmap2.png" target="_blank">https://sc.burrfoot.it/nmap2.png</a>).<br>After a couple of minutes I did some other tests, the ldap seem returned reachable and queries went ok, but after a while TCP 389 turned unreachable.<br><br>To clear out this strange beahvior I setup some basic tcp check with Nagios, which resulted ok most of the time, except when we did some ldap queries, at that point port 389 seems to close for a while and returned available after a few minutes.<br>At first I thought the problem seems related to some strange firewall behaviour on our customer side because we don't have any security appliance or tool on our side (only a basic EC2 security group) but before asking our customer to do some checks I wanna be sure that our strongswan configuration is ok and couldn't be the cause of this problem.<br><br>I also tried to capture some traffic on our strongswan endpoint (10.1.0.144), for instance I was looking for TCP port 389 and ESP protocols, when I made a nmap test on port 389 (open) this is the result --> <a href="https://sc.burrfoot.it/tcpdump1.png" target="_blank">https://sc.burrfoot.it/tcpdump1.png</a><br>When the port result closed I saw not a single packed passing through, not a single one, not even a SYN packet from our application server.<br>Checking strongswan tunnel status I never had a single disconnection, everything seems very stable from a vpn point of view.<br><br>This is my strongswan configuration, I know that some protocols are not the best from a security point of view, but we had to follow our customer's specifications.<br>---<br>conn aws-customer<br>    ikelifetime=1440m<br>    keylife=60m<br>    rekeymargin=3m<br>    keyingtries=3<br>    keyexchange=ikev1<br>    aggressive=no<br>    mobike=no<br>    ike=aes128-sha1-modp1536<br>    ike=aes256-sha256-modp1536<br>    esp=aes128-sha1-modp1536<br>    esp=aes256-sha256-modp1536<br>    left=10.1.0.144<br>    leftid=74.74.74.74<br>    leftsubnet=<a href="http://10.1.0.137/32" target="_blank">10.1.0.137/32</a><br>    leftauth=psk<br>    right=217.217.217.217<br>    rightid=217.217.217.217<br>    rightsubnet=<a href="http://10.128.4.0/26" target="_blank">10.128.4.0/26</a><br>    rightauth=psk<br>    type=tunnel<br>    auto=start<br>    dpdaction=restart<br>---<br><br>Do you think this strange behaviour can be cause by our strongswan configuration?<br>Can you suggest me some more in deep tests to figure out why we have these strange interruptions?<br>Do you have any other suggestions?<br><br>Thank you very much for any informations.</div><div><br></div><div>Tas</div><div><br clear="all"><div><div dir="ltr" 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></div></div></div></div></div></div></div></div>