Re: [strongSwan] Calculating the generated MAC address when identity_lease is enabled
Hi Micah, > 1. Can I configure the strongSwan server to force the clients to send > the FQDNs as identities? No, that's a local decision. > 2. Alternatively, can I generate certificates differently to force the > clients to send the FQDNs as identities? Not that I'm aware. > 3. Am I misreading the documentation about rightid=%fqdn? If so, what > is it intended to do? It's mostly useful on clients to match the configured identity against SANs in the server certificate if the server uses the subject DN as identity. It doesn't change the IKE identity the peer sends. > 4. Can I avoid using two conn sections for each user somehow? If you want to match their identity, no. > 5. Even better, can I use a single conn section to match all users, > no matter their operating system, and enforce that they send their > client identifier to the DHCP server the same way? Have a look at [1] for my suggestion to Harald (who had a similar question) for a possible code modification to do this (i.e. get the client certificate, extract the first dNSName SAN and then forward that as host name in the DHCP request). Regards, Tobias [1] https://wiki.strongswan.org/issues/2581
Re: [strongSwan] Can't connect to peer network(showing INVALID_SYNTAX error)
Hi, > generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr > N(EAP_ONLY) ] > sending packet: from 159.*.*.*[500] to 4.*.*.*[500] (220 bytes) > received packet: from 4.*.*.*[500] to 159.*.*.*[500] (68 bytes) > parsed IKE_AUTH response 1 [ N(INVAL_SYN) ] > *received INVALID_SYNTAX notify error* > establishing connection 'net-net' failed Apparently, the other end doesn't like the IKE_AUTH request for some reason. Check the log there for details. Regards, Tobias
Re: [strongSwan] VICI: Stale SA's found even after unloading the connection.
Hi Noel, Thanks for your reply. As mentioned in previous mail, we did try using vici terminate api before calling unload to flush the stale entry. But problem still exist(Logs attached in previous mail). Is there any other api to terminate the session? Also, Can you please help me to understand why there is a difference in behavior between unload_conn of session's in established and connecting state? Thanks Vignesh Kesavan -Original Message- From: Noel Kuntze [mailto:noel.kuntze+strongswan-users-ml@thermi.consulting] Sent: Thursday, April 05, 2018 10:14 PM To: Vignesh Kesavan ; users@lists.strongswan.org Subject: Re: [strongSwan] VICI: Stale SA's found even after unloading the connection. Hello Vignesh, That is intended and normal behaviour. It is not a problem. You can implement your desired behaviour by terminating the IKE SAs with the connection configuration's name. Kind regards Noel On 04.04.2018 12:21, Vignesh Kesavan wrote: > > Hi, > > > > We are using Strongswan 5.5.3 and VICI python library to program IPSEC > tunnels. > > > > We use load_conn/unload_conn api’s to configure/delete a tunnel from > strongswan respectively. > > > > This problem arises when we try to unload a tunnel which is in CONNECTING > state. On issuing unload_conn, connection is getting deleted(verified using > swanctl –list-conns). But SA continue to exist and charon retries to > establish the tunnel(verified using swanctl –list-sas). Ideally we expect the > SA to get deleted after unload. > > > > Please find attached python script that we used to simulated the problem. The > destination used in the script(10.10.10.1) is not a reachable host. So tunnel > is in connecting state. In this sate, after calling unload_conn, connection > is getting deleted. But SA exists. > > > > Please suggest a way to overcome from this problem. > > > > */_Note: _/* > > 1. We tried calling Terminate api before calling unload. Even that didnt > help. We ended in the same behavior(Can be seen from the logs attached > (python_output.txt)) > > 2. This problem is not seen on tunnels which are in established state. > Unload_conn delete’s connection and SA's properly. > > > > Thanks > > Vignesh >
Re: [strongSwan] Example needed: both client and server networks are behind NAT
Hello all. Ok, another re-phrase, very quick question, hopefully for a quick answer. Please. Is it possible to have net-2-net vpn, with both vpn gateways: (a) behind NAT, (b) having only 1 network interface? What example/test would be closest to this? Thanks. >Пятница, 30 марта 2018, 23:53 +03:00 от strongswan_u...@mail.ru: > >In other words: how alice and bob from ikev2/double-nat-net should be further >configured so that alice2, 10.1.0.11 could ping bob2, 10.2.0.11? Assuming, as >in the test, that the tunnel goes from alice, 10.1.0.10 to bob, 10.2.0.10. > >Thank you. > >>Пятница, 30 марта 2018, 21:02 +03:00 от strongswan_u...@mail.ru: >> >>Hello! >> >>Is there an example that I can study - when both client and server networks >>are behind NAT? ikev2, and PSK for simplicity. >> >>The ikev2/double-nat-net test seems to be closest, and it is supposed to show >>a *network* (bob, bob2,...) behind the server, but bob is the only one there >>(and alice doesn't even ping bob, she pings internal NAT interface). In my >>similar setup I can only have 1 client (alice) successfully pinging the >>server (bob). bob2 can't ping alice, and alice2 can't ping bob (so, >>peer-to-peer only). >> >>Thanks. --
Re: [strongSwan] Calculating the generated MAC address when identity_lease is enabled
Hello Tobias, > > 5. Even better, can I use a single conn section to match all users, > > no matter their operating system, and enforce that they send their > > client identifier to the DHCP server the same way? > > Have a look at [1] for my suggestion to Harald (who had a similar > question) for a possible code modification to do this (i.e. get the > client certificate, extract the first dNSName SAN and then forward that > as host name in the DHCP request). > > [1] https://wiki.strongswan.org/issues/2581 Ah hah. I'm not sure that's the right path for my project, but I'll take it under consideration. Thanks for taking the time to answer my questions - you've gone above and beyond, and I understand the identity matching and DHCP systems much better now. - Micah
