Re: [strongSwan] Possible to broadcast packets down each IPsec tunnel from the SeGW ?
Hi Martin, I'm interested in this topics (broadcast packets down each IPSec tunnel) as well. However, I still have some problem about this solution. Below is my understanding based on Graham's example. our strongSwan-based SeGW defines a conn config entry in ipsec.conf where IPsec tunnels established using that config are assigned inner IP addresses from a pool (e.g. 10.17.0.0/24). Server may assign an IP (e.g. 10.17.0.1) to client A and assign another IP (e.g. 10.17.0.2) to client B. On Client A, it will have one outgoing xfrm policy - src 10.17.0.1/32 dst 0.0.0.0/0 dir out .. On Client B, it will have one outgoing xfrm policy - src 10.17.0.2/32 dst 0.0.0.0/0 dir out .. Both client can send out broadcast traffic over tunnel without error since the broadcast address (10.17.0.255) is within the outgoing xfrm policy. On the other hand, the server side will have 2 outgoing xfrm policies - src 0.0.0.0/0 dst 10.17.0.1/32 dir out .. to Client A src 0.0.0.0/0 dst 10.17.0.2/32 dir out .. to Client B If we create a socket on server side which listen for broadcast packet, re-inject the packet to client A and client B, the packet will be transfered into a unicast one (with destination IP changed to 10.17.0.1 and 10.17.0.2, accordingly), is that correct? In that case, client A and client B still received a unicast packet, not broadcast one. Please tell me if my understanding correct or not, and let's discuss is it possible to send out broadcast packets (with dest address 10.17.0.254) to client A and client B. Best regards Iris Su 2011/11/2 Martin Willi mar...@strongswan.org Hi Graham, Is it possible to send a packet to a subnet's broadcast address on the secure side of a SeGW and have the packet sent down each IPsec tunnel whose inner IP address belongs to that subnet ? It's not trivial, but it can be done. You'll need to: * include the broadcast address into the IPsec tunnel * separate the tunnels with the XFRM mark functionality to avoid conflicts in the kernel * open a socket that listens for broadcast packets and re-inject them for each active tunnel using the XFRM mark of each tunnel I actually have some unreleased code that does exactly this. It does not perform that well because it handles broadcast sniffing and re-injection all in userspace, but it is usable. If performance is a problem, we'd have to delegate that job to the kernel. Another part of this plugin does the opposite, it listens for broadcasts coming from tunnels and re-injects them to the local subnet. The code is not usable out of the box, but let me know if you're interested. Maybe we'll find a solution how we could make it usable in a more generic way and include it in the mainline distribution. Best regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] How to bypass CRL checks?
Hello Mugur, with IKEv2 revocation checks can be easily disabled by not loading the revocation plugin. What is not possible is to disable CRL checking on a per connection definition basis. Regards Andreas On 11/24/2011 08:50 AM, ABULIUS, MUGUR (MUGUR) wrote: Hello, Our understanding in case of setting strictcrlpolicy to **no** for charon is that strongSwan denies the authentication if the certificate appears in the fetched CRL. But, if the certificate does not specify an uri or if the CRL can’t be fetched the authentication is not denied. Can you please check our understanding? In case our assumption is correct we are looking for a way to set-up strongSwan (for some specific run scenarios) to bypass any CRL checks (even if strictcrlpolicy=no). We are looking for this capability even if received certificates specify an uri and the corresponding CRL can be fetched from CDP. Thank you Mugur == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Linux VPN Solution!www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[ITA-HSR]== ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] How to bypass CRL checks?
Hello Stephen, Thanks again. I have seen at http://wiki.strongswan.org/projects/strongswan/wiki/Autoconf that plug-ins are specified at strongSwan binary creation (./configure). There is any way when strongSwan is load to make the choice of plug-ins to load (e.g. revocation). Which is the best strongSwan deployment policy when some runs need the revocation plug-in and some other runs do not need the plug-in. Context: Charon under Linux Best Regards Mugur -Original Message- From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] Sent: jeudi 24 novembre 2011 12:51 To: ABULIUS, MUGUR (MUGUR) Cc: users@lists.strongswan.org; SCARAZZINI, FABRICE (FABRICE); Pisano, Stephen G (Stephen); WASNIEWSKI, ALAIN (ALAIN) Subject: Re: [strongSwan] How to bypass CRL checks? Hello Mugur, with IKEv2 revocation checks can be easily disabled by not loading the revocation plugin. What is not possible is to disable CRL checking on a per connection definition basis. Regards Andreas On 11/24/2011 08:50 AM, ABULIUS, MUGUR (MUGUR) wrote: Hello, Our understanding in case of setting strictcrlpolicy to **no** for charon is that strongSwan denies the authentication if the certificate appears in the fetched CRL. But, if the certificate does not specify an uri or if the CRL can't be fetched the authentication is not denied. Can you please check our understanding? In case our assumption is correct we are looking for a way to set-up strongSwan (for some specific run scenarios) to bypass any CRL checks (even if strictcrlpolicy=no). We are looking for this capability even if received certificates specify an uri and the corresponding CRL can be fetched from CDP. Thank you Mugur == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Linux VPN Solution!www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[ITA-HSR]== ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Site to site vpn using certificates-no peer config in log files
Thanks, that let me connect the 2. One thing I found is that the public key of my SUN server needed to be in the /etc/ipsec.d/aacerts of MOON. Once that was done, I was able to send traffic. If I put the public key of the CA into the cacerts directory would I need to keep the SUN cert on MOON? -Original Message- From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] Sent: Tuesday, November 22, 2011 1:06 AM To: Edward Cooke Cc: users@lists.strongswan.org Subject: Re: [strongSwan] Site to site vpn using certificates-no peer config in log files Hello Ed, on the moon side you must configure rightid=***SUN DN ON CERTIFICATE*** Regards Andreas On 11/22/2011 07:59 AM, Edward Cooke wrote: Hi all, I'm trying to get a site to site VPN set up between to strongswan Linux systems. I can't get past the no matching peer config found message on Sun (my datacenter). I've tried using the net-net ikev2 config example in the tests as that is closest to what I am trying to do. Does anyone have any suggestions, below is detailed info on the setup's. If anybody could help it would be most appreciated. Thanks in advance, -Ed- The way my setup looks is this: Moon - Firewall - internet - Sun Here's the log entries during the connection attempts: SUN --- Nov 21 23:31:55 firewall1 charon: 12[NET] received packet: from ***MOON EXTERNAL IP***[65146] to ***SUN IP***[500] Nov 21 23:31:55 firewall1 charon: 12[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] Nov 21 23:31:55 firewall1 charon: 12[IKE] ***MOON EXTERNAL IP*** is initiating an IKE_SA Nov 21 23:31:55 firewall1 charon: 12[IKE] ***MOON EXTERNAL IP*** is initiating an IKE_SA Nov 21 23:31:56 firewall1 charon: 12[IKE] remote host is behind NAT Nov 21 23:31:56 firewall1 charon: 12[IKE] sending cert request for *** Nov 21 23:31:56 firewall1 charon: 12[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] Nov 21 23:31:56 firewall1 charon: 12[NET] sending packet: from ***SUN IP***[500] to ***MOON EXTERNAL IP***[65146] Nov 21 23:31:56 firewall1 charon: 04[NET] received packet: from ***MOON EXTERNAL IP***[11060] to ***SUN IP***[4500] Nov 21 23:31:56 firewall1 charon: 04[ENC] parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ] Nov 21 23:31:56 firewall1 charon: 04[IKE] received end entity cert *** Nov 21 23:31:56 firewall1 charon: 04[CFG] looking for peer configs matching ***SUN IP***[SUN HOSTNAME]...***MOON IP***[***MOON DN ON CERTIFICATE***] Nov 21 23:31:56 firewall1 charon: 04[CFG] no matching peer config found Nov 21 23:31:56 firewall1 charon: 04[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ] Nov 21 23:31:56 firewall1 charon: 04[NET] sending packet: from ***SUN IP***[4500] to ***MOON IP***[11060] MOON --- Nov 21 16:43:54 linuxfw charon: 11[IKE] initiating IKE_SA site-site[22] to ***SUN IP*** Nov 21 16:43:54 linuxfw charon: 11[IKE] initiating IKE_SA site-site[22] to ***SUN IP*** Nov 21 16:43:54 linuxfw charon: 11[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] Nov 21 16:43:54 linuxfw charon: 11[NET] sending packet: from ***MOON IP***[500] to ***SUN IP***[500] Nov 21 16:43:54 linuxfw charon: 14[NET] received packet: from ***SUN IP***[500] to ***MOON IP***[500] Nov 21 16:43:54 linuxfw charon: 14[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] Nov 21 16:43:54 linuxfw charon: 14[IKE] local host is behind NAT, sending keep alives Nov 21 16:43:54 linuxfw charon: 14[IKE] received 1 cert requests for an unknown ca Nov 21 16:43:54 linuxfw charon: 14[IKE] authentication of '***MOON DN ON CERTIFICATE***' (myself) with RSA signature successful Nov 21 16:43:54 linuxfw charon: 14[IKE] sending end entity cert ***MOON DN ON CERTIFICATE*** Nov 21 16:43:54 linuxfw charon: 14[IKE] establishing CHILD_SA site-site Nov 21 16:43:54 linuxfw charon: 14[IKE] establishing CHILD_SA site-site Nov 21 16:43:54 linuxfw charon: 14[ENC] generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ] Nov 21 16:43:54 linuxfw charon: 14[NET] sending packet: from ***MOON IP***[4500] to ***SUN IP***[4500] Nov 21 16:43:54 linuxfw charon: 04[NET] received packet: from ***SUN IP***[4500] to ***MOON IP***[4500] Nov 21 16:43:54 linuxfw charon: 04[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ] Nov 21 16:43:54 linuxfw charon: 04[IKE] received AUTHENTICATION_FAILED notify error And ipsec.conf files SUN --- # ipsec.conf - strongSwan IPsec configuration file # basic configuration config setup #strict is new strictcrlpolicy=no plutostart=no conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 keyexchange=ikev2 mobike=no conn site-site left=***SUN IP*** leftsubnet=***SUN INTERNAL
