Re: [strongSwan] best way to generate self-signed certs for strongswan-4, 5, x
On 08/09/2011 11:38 AM, luxInteg wrote: I am atttempting to use strongswan-4.5.2 after last playing with strongswan-2.x. some years ago. I have this questions. Which is the best way to generate certificates for strongswan? Since you already played around with strongSwan, I assume that you have a basic understanding of certificates and PKIs. Take a look at the following wiki page: http://wiki.strongswan.org/projects/strongswan/wiki/SimpleCA It might have the information you're looking for. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] [strongSwan-dev] PASS and DROP shunt policies (was: ANNOUNCE: strongswan-4.5.3rc1 released)
Dear strongSwan team, thanks for the great work. I have some comments regarding the following change: On 07/19/2011 01:00 AM, Andreas Steffen wrote: PASS and DROP shunt policies configurable by charon --- The IKEv2 charon daemon supports type=pass and type=drop shunt policies preventing specific traffic to go through IPsec connections. Installation of the shunt policies are possible either via the XFRM netfilter or PFKEYv2 IPsec kernel interfaces as the following two scenarios show: http://www.strongswan.org/uml/testresults45rc/ikev2/shunt-policies/ http://www.strongswan.org/uml/testresults45rc/pfkey/shunt-policies/ I'm looking at the IKEv2 example. It talks about a host called venus, but I can't find it in the picture. I believe that adding it to the picture would help avoid confusion. You say that install_routes=no has to be added to strongswan.conf. This raises some concerns. Doesn't this break other connections that depend on install_routes being set to yes? Why not change strongSwan in a way such that install_routes=no is applied to type=pass connections automatically? I believe that this would be an improvement in terms of user friendliness. I'm curious what would happen if you do not set install_routes to no. What do the routes look like and why are they causing failure. Again, from a user perspective, I see authby=never as part of the local-net connection which is of type=pass. On the same note, conn venus-icmp has the parameters leftauth=any and rightauth=any. Wouldn't it be nice to get rid of these parameters in this scenario? I'm thinking that authby, leftauth and rightauth are not applicable if the connection is of type=drop or type=pass. If it's an internal thing, maybe starter or charon can add this automatically. Thanks -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Test framework not showing iptables rules in tables other than 'filter'
On 06/14/2011 11:59 PM, Andreas Steffen wrote: usually the console.log shows the setup of the additional iptables rules: http://www.strongswan.org/uml/testresults45/ikev2/nat-two-rw-mark/console.log Hi Andreas and Johannes, thank you for your quick responses. I took note of the fact that console.log provides the iptables rules I was looking for, but I still think that this situation can be improved: console.log does not show the rules created automatically by /etc/mark_updown. It would be desirable to have all rules from the mangle table in one place. I would prefer iptables-save over iptables -L because the former outputs the rules in the format that is used by the iptables CLI. People are usually more familiar with this format. Either way, I think it would be helpful to the reader if these rules were visible no matter in which format. A shortcoming that I noticed here is that iptables-save prints the mark value in hexadecimal format which is different from the output of ip xfrm policy which uses a decimal representation. Thanks -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Test framework not showing iptables rules in tables other than 'filter'
I'm looking at the config example at http://www.strongswan.org/uml/testresults45/ikev2/nat-two-rw-mark/index.html and I'm wondering where I can find a complete list of all iptables rules that are in effect. iptables -L only displays the rules in the filter table. The rules from the nat and mangle tables are missing. Wouldn't it make more sense to use iptables-save to dump the complete picture. AFAICT, it outputs the nat and mangle table as well as the filter table. Thanks -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Wireshark: cannot see outgoing IPsec packets
On 05/20/2011 08:45 AM, Richard Chan wrote: Using wireshark and trying to sniff the cleartext packet, I can only see incoming packets. That's a peculiarity of the Linux kernel. Capture the (UDP encapsulated) ESP packets and use wireshark to decrypt them. See http://wiki.wireshark.org/ESP_Preferences Run the following command to determine the encryption algorithms and the symmetric keys used by the kernel. Depending on your configuration, strongSwan periodically changes encryption keys. Keep this in mind if you're capturing traffic over an extended period of time. ip xfrm state -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] StrongSWAN and AVM Fritzbox - Help!
If there's a way to detect the setup it would be great if leftfirewall automatically detects all rules for INPUT or FORWARD chain. I believe that this is not doable because the rules in your INPUT/FORWARD chain can be very complex, too complex for a general solution. Even with the current solution where strongSwan appends ACCEPT rules to your FORWARD chain, you might run into problems. Imagine you have DROP rules in your chain that get triggered by the decrypted packets. Adding ACCEPT rules at the very end won't make a difference because these rules will never be examined. I guess you're better off with manually managing these chains. Not yet. ;-) After ISP-forced DSL-disconnection (Thank you Deutsche Telekom AG :-( ) I have to restart IPSec on the Ubuntu machine (/etc/init.d/ipsec restart). Otherwise no IPSec connections can be established. Is there any configuration trick to reestablish the IPSec connection after disconnection/IP-change? Restarting IPsec is a bad idea because it brings down not only the IPsec tunnels which are affected by the disconnect of this single interface but all IPsec tunnels negotiated by strongSwan. After the disconnect, I guess you have to do a ipsec update (if your IP address changed) I use /usr/lib/ipsec/whack --initiate --name $conn --asynchronous for every IPsec connection. I also re-insert all the necessary source routes with ip route add 192.168.x.y/z dev $PPP_IFACE src $SRCIP Not sure if this is the best solution, however. If you continue to have problems, then post the output of the following commands before and after the reconnect: ip route show table 0 ip -4 address ip xfrm policy ip xfrm state ipsec statusall -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] StrongSWAN and AVM Fritzbox - Help!
On 02/13/2011 12:42 PM, Rene Bartsch wrote: On Sun, 13 Feb 2011 10:55:07 -0800, Daniel Mentz danielml+mailinglists.strongs...@sent.com wrote: On 02/13/2011 08:49 AM, Rene Bartsch wrote: After removing leftfirewall=yes from ipsec.conf and adding the incoming FORWARD rule created by leftfirewall=yes to the INPUT chain manually, it seems to work. xxx.xxx.xxx.20: eth0primary public IP of Ubuntu 10.04.2 LTS server xxx.xxx.xxx.102: eth0:0 secondary public IP of Ubuntu 10.04.2 LTS server (IPSec connection) 192.168.176.1: dummy0 Test for virtual servers eth0: 1000Base-T internet-uplink eth1: unused Hi Rene, so I guess there's a misunderstanding here. I thought your servers were behind your VPN gateway (your Ubuntu box), but it looks like your server daemons run on the same machine. That's why you set up the dummy0 interface, I guess. That's actually the reason, why the packets never hit the FORWARD chain. The fact that the IP address 192.168.176.1 is assigned to an interface which is different from the interface on which the ESP packets come in is not considered as forwarding. So I guess the rules which are created by leftfirewall=yes won't help you since you need those rules in your INPUT chain. You were asking whether your setup might send any plaintext packets, right? If you're worried about that then you might want to change the default policy of the OUTPUT chain from ACCEPT to DROP and insert appropriate rules. Does that answer your questions? If you finally have a working setup, you might want to share your experience on the strongSwan wiki so that other users can benefit from it. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Visit strongSwan at LinuxTag 2010 in Berlin
Andreas Steffen wrote: Visit us at our booth 115 in hall 7.2b and attend the strongSwan workshop which will be scheduled either on Friday June 11 or Thursday June 10. We will post the exact time as soon as the information becomes available. Hi Andreas, I'm excited about this workshop and I do understand that the exact date and time is not yet set. But have you decided on the agenda of this workshop yet? I would love to learn about it. Can we i.e. the community express wishes regarding what will be covered during the workshop? I would be interested in learning about the mechanics of charon i.e. understand the source code and software design. Best wishes -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Tunnel up, no packets routed through
Russ Cox wrote: The tunnel has come up ok, but no traffic appears to be getting routed through the tunnel. Hi Ross, could you please post the output of the following commands: ip -4 a s ip -4 r s t 0 iptables-save Did you use tcpdump on both interfaces of the gateway in order to find out whether the gateway sends out ESP packets? -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Is there possible for strongswan to support IKEv1 and IKEv2 at the same time at the same ho st?
Andreas Steffen wrote: in the default configuration the pluto daemon binds to the UDP ports 500 and 4500 whereas the charon daemon uses a raw socket with Linux Socket Filter (LSF) rules filtering and forwarding IKE version 2 messages to the IKEv2 daemon. Thus it is no problem to use racoon in place of charon for handling IKEv1 connections. I'm wondering if it should say it is no problem to use racoon in place of *pluto* for handling IKEv1 connections. charon implements IKEv2 whereas pluto implements IKEv1. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] routing all traffic through tunnel without local one
Peter Winterer wrote: Hi Daniel, Am 08.03.2010 10:02, schrieb Daniel Mentz: Matthias Dahl wrote: To tunnel all internet traffic, you'll need a 0.0.0.0/0 rightsubnet. This however, includes your local network in the tunnel too. One could consider this a bug. Most people certainly never will want their local traffic routed outside of their local network. The more I think about it, this could even have security implications. The default should be to have the local lan by-passed unless the user explicitely states otherwise. One might also argue that the current behavior is more secure: Imagine a road warrior being in a hotel room, connecting her laptop to the hotel's LAN in order to get Internet access. She probably does not care about other hosts on the local subnet. She just wants to have access to the corporate network via IPsec. Now, imagine that the hotel's LAN uses the same IP address space as some resource on the corporate network. The traffic would then be sent to the incorrect machine on the local subnet of the hotel that happens to have the same IP address, instead of the machine on the corporate network. I think you are right. However, what about dhcp traffic in the local network? A client could not renew his ip address, because the dhcp traffic on the local dhcp-server would also be blocked. I'm not sure, but I think with a linux client this would break the connection and therefore the ipsec-tunnel. Hi Peter, that is indeed an interesting question. I guess one of the following is true: 1. DHCP fails as you suspect. 2. The dhcp-client uses raw sockets to send/receive IP packets. Maybe ipsec policies do not apply to IP packets sent via raw sockets. 3. The dhcp-client sets a per socket policy of type IPSEC_POLICY_BYPASS. As a consequence, IP packets which are sent or received on that socket are not subject to IPsec processing. If you can read German, take a look at http://mirror.roe.ch/doc/hsr/sa-natt.pdf and search for Per socket policy. This document has some good information about this socket option. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Certificates in cacerts directory
ABULIUS, MUGUR (MUGUR) wrote: If rightca is specified then we only request certificates issued by rightca. Otherwise we send certificate requests for all CAs contained in /etc/ipsec.d/cacerts/ If rightca= is specified, then it is required that a certificate matching the specified DN to be present locally in /etc/ipsec.d/cacerts/ ? I guess yes. I mean strongSwan has to read the certificate from somewhere. You could also create a ca section as described at http://wiki.strongswan.org/projects/strongswan/wiki/CaSection if you want to store the certificate in a non-default location. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Possibly a bug in charon when auto=start
Hi Vladimir, I recommend not to depend on IPsec policies if you want to enforce that no unencrypted traffic leaves the gateway and that no unprotected traffic is accepted. Use the policy match provided by iptables. Here's an example: iptables -A FORWARD -m policy --dir out --pol ipsec -j ACCEPT iptables -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT # Do not forward packets to or from xyz if ipsec is off iptables -A FORWARD -d 1.2.3.4/26 -j REJECT --reject-with icmp-net-unreachable iptables -A FORWARD -s 1.2.3.4/26 -j REJECT --reject-with icmp-net-unreachable -Daniel Martin, thank you for clarification. I think it will be good if this 'auto=start' feature will be documented in ipsec.conf(5) man page. Because a strongswan-newbie sysadmin may use this option without knowing that unencrypted packets are not filtered if the tunnel is not up yet. This may be a serious vulnerability of a system. Thank you! Best regards, Vladimir Yes, this is the intended behavior. auto=start does not install policies until the tunnel has been negotiated. auto=route installs the policies and triggers a tunnel when required. ___ 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] Please help - Using strongSwan to connect to CheckPoint VPN-1
Hi Jana, please go to http://wiki.strongswan.org/projects/strongswan/wiki/IKEv1Examples for IKEv1 Configuration Examples. PSK with XAUTH authentication and virtual IP addresses or RSA with XAUTH authentication and virtual IP addresse is probably the right one for you. Please refer to http://wiki.strongswan.org/projects/strongswan/wiki/IpsecConf for definitions of the individual parameters. -Daniel Sucha Singh wrote: Hi Andreas, Thank you for your prompt response, I appreciate it. I can confirm that we are indeed using IKEv1 Main Mode. I have the pluto daemon installed, however I have no idea how to configure the ipsec.conf file. I have opened it in a text editor and I am struggling to make sense of most of the parameters. I can't appear to find anything in the online documentation to define what the parameters mean. Could you possibly construct the file for me based on the information I have already supplied? I will fill the blanks like site IP address etc. Thanks again for your time and support. Jana --- On Sun, 28/2/10, Andreas Steffen andreas.stef...@strongswan.org wrote: From: Andreas Steffen andreas.stef...@strongswan.org Subject: Re: [strongSwan] Please help - Using strongSwan to connect to CheckPoint VPN-1 To: Sucha Singh soorma_j...@yahoo.co.uk Cc: users@lists.strongswan.org Date: Sunday, 28 February, 2010, 12:12 Hi, as far as I know, the CheckPoint VPN gateway does not support the IKEv2 protocol. Therefore you can't use the strongSwan NetworkManager plugin to set up a connection. The CheckPoint VPN gateway most probably will use IKEv1 and XAUTH. The first thing to find out is whether IKEv1 Main Mode is used by the CheckPoint box since strongSwan does not support the potentially insecure IKEv1 Aggressive Mode. If Main Mode is possible then you can configure strongSwan's IKEv1 pluto daemon via /etc/ipsec.conf. Best regards Andreas Sucha Singh wrote: Hi, I'm looking to use strongSwan to connect to my company CheckPoint VPN, as I am new to Linux and networking I am really struggling to get anything working. I have a Actividentity token that generates a password that authenticates against a RADIUS server, below is a list of facts I know from my CheckPoint config from Windows: I have an IP address for company site Authentication - Challenge Response NAT-T protocol - enabled Office Mode - enabled Use NAT traversal tunneling - enabled IKE over TCP - enabled Force UDP encapsulation - enabled I have attempted to use the Network Manager GUI to connect but it fails with VPN service failed to start, the syslog file contains a host of errors. The settings I attempted were: Gateway: Address - IP address of my company site Certificate - None Client: Authentication - EAP Username - My id I use for my token to generate password Options - Request an inner IP address - unchecked Enforce UDP encapsulation - checked Use IP compression - unchecked My questions would be: 1) Does strongSwan support the protocols/authentication methods I describe for CheckPoint VPN 2) If yes, then does my setup through Network Manager look correct 3) If yes, then is it a case of posting the sys.log errors for someone to kindly look at I appreciate anyone's help and time with this. Regards, Jana == 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 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Home network config
Hi Razza, you need to setup your DSL/NAT Router to forward UDP datagrams destined for ports 500 and 4500 to your strongSwan box. You said that you want to allocate IP addresses for road warriors inside the 192.168.10.0/24 range. This could be difficult to achieve. Can you waive this requirement and come up with a separate IP prefix for road warriors? Like 10.x.y.0/24? This would make things much easier. I'm using this kind of setup for Win7 clients. Which IPsec client software do you want to use on Windows XP? -Daniel Razza wrote: Hi all, I’m new to the list and am looking for a bit of advice. I’ve looked around but can’t find any examples close to what I want to achieve, probably because it’s flawed from a purists security view point. Anyway, I want to use strongSwan in a home network environment, mainly so I can access home network machines whilst I’m away. E.g. ssh to my asterisk server, RDP/VNC to my partners machine etc. My network is as follows – 192.168.10.0/24 -- | 192.168.10.1 | | Dynamic RIPE IP | -- Internet Home Network | Inside i/f | | Outside i/f | | DSL/NAT Router | As I only have a single RIPE address on my DSL, I intend to port forward necessary ports to a single interface on my strongSwan box. My strongSwan box will have an address in the range 192.168.10.0/24. I would prefer to have a singe physical interface if possible, but could have two. When I connect from an internet connected machine (soon Win7, currently XP), I would like to be allocated a virtual IP in the range of my home network ( 192.168.10.0/24). Is this possible? ___ 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] Home network config
Hi Raza, I never used the L2TP/IPsec client so I can't tell how to set it up. If you want to use plain IPsec you have - in my opinion - the following options: IKEv1: WindowsXP + NCP Secure Entry Client for Win32/64 (142 EUR) WindowsXP + Shrew Soft VPN client (free of charge) Windows 7 + NCP Secure Entry Client for Win32/64 (142 EUR) IKEv2: Windows 7 + built-in IKEv2 VPN client If you decide to use IKEv1, you are going to setup the pluto daemon (plutostart=yes). If you want to use IKEv2 you are going to use the charon daemon on the strongSwan side. You have to make sure that your NAT router forwards packets destined for 192.168.1.0/24 to your strongSwan box. Do you know how to create X.509 certificates? If you want to use Windows 7 you could use a connection definition which is similar to config setup charonstart=yes plutostart=no conn win7 keyexchange=ikev2 ike=aes256-sha1-modp1024! esp=aes256-sha1! dpdaction=clear dpddelay=300s rekey=no left=%any leftsubnet=0.0.0.0/0 leftauth=pubkey leftcert=razz_home_network.pem left...@vpn.razz.net right=%any rightsourceip=192.168.1.0/24 rightauth=eap-mschapv2 rightsendcert=never eap_identity=%any auto=add There's one issue I have with Windows 7: The native IPsec client sends all IP traffic through the IPsec tunnel; even traffic that is not destined for your home network. As a consequence, if the road warrior accesses some site on the internet, the traffic will be sent through your strongSwan box at home. -Daniel Razza wrote: Hi Daniel, I was thinking of the bundled L2TP/IPsec client, I don't mind paying for a VPN client if there are better/more flexible options. If the client is over £30 ($40) I would rather just buy Win 7. I am happy with a different range, say 192.168.1.0/24 http://192.168.1.0/24 for the VPN users. Kind regards, On 19 February 2010 12:29, Daniel Mentz danielml+mailinglists.strongs...@sent.com mailto:danielml%2bmailinglists.strongs...@sent.com wrote: Hi Razza, you need to setup your DSL/NAT Router to forward UDP datagrams destined for ports 500 and 4500 to your strongSwan box. You said that you want to allocate IP addresses for road warriors inside the 192.168.10.0/24 http://192.168.10.0/24 range. This could be difficult to achieve. Can you waive this requirement and come up with a separate IP prefix for road warriors? Like 10.x.y.0/24? This would make things much easier. I'm using this kind of setup for Win7 clients. Which IPsec client software do you want to use on Windows XP? -Daniel Razza wrote: Hi all, I’m new to the list and am looking for a bit of advice. I’ve looked around but can’t find any examples close to what I want to achieve, probably because it’s flawed from a purists security view point. Anyway, I want to use strongSwan in a home network environment, mainly so I can access home network machines whilst I’m away. E.g. ssh to my asterisk server, RDP/VNC to my partners machine etc. My network is as follows – 192.168.10.0/24 http://192.168.10.0/24 -- | 192.168.10.1 | | Dynamic RIPE IP | -- Internet Home Network | Inside i/f | | Outside i/f | | DSL/NAT Router | As I only have a single RIPE address on my DSL, I intend to port forward necessary ports to a single interface on my strongSwan box. My strongSwan box will have an address in the range 192.168.10.0/24 http://192.168.10.0/24. I would prefer to have a singe physical interface if possible, but could have two. When I connect from an internet connected machine (soon Win7, currently XP), I would like to be allocated a virtual IP in the range of my home network ( 192.168.10.0/24 http://192.168.10.0/24). Is this possible? ___ Users mailing list Users@lists.strongswan.org mailto: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] Policies should be available in Kernel even though SA is not established!
ashish mahalka wrote: establishes SA b/w the peers, it should over-write those discard policies and install ipsec policies in the kernel. Is this possible ? Hi Ashish, sorry, but I do not like this idea much. With your design, both, strongSwan and your shell scripts access the policy database. I'm afraid that this will end up in a complete mess. I suggest that you either have strongSwan *or* your shell scripts manipulate the SPD. How would I know the reqId of the strongswan's connection ? I guess you could just temporarily set installpolicy=yes and find out by executing ip xfrm policy what reqids strongSwan allocates for each individual connection. However, from looking at the source code, I get this feeling that those IDs might change if you swap the order of the connections in ipsec.conf or if you add new connection definitions. I'm not exactly sure what you are trying to achieve. I guess you want to make sure that none of those IP packets that should be protected, leaves the gateway unencrypted. From my experience, I suggest to use some iptables rules in combination with the policy match. Here are the rules that I crafted for our gateway. Maybe you can take advantage of these: iptables -A FORWARD -s 192.168.10.0/24 -m policy --dir out --pol ipsec -j ACCEPT iptables -A FORWARD -d 192.168.10.0/24 -m policy --dir in --pol ipsec -j ACCEPT # Do not forward packets to or from MUCDMZ (Muenchen DMZ) if ipsec is off iptables -A FORWARD -d 80.14.76.128/26 -j REJECT --reject-with icmp-net-unreachable iptables -A FORWARD -s 80.14.76.128/26 -j REJECT --reject-with icmp-net-unreachable The idea is basically to accept traffic that is secured by IPsec. A subsequent rule makes sure that traffic that did not match the IPsec rule will be rejected. Does this help? -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Documentation: IKEv2CipherSuites, Integrity Algorithms
I'm wondering if we should change the wiki page http://wiki.strongswan.org/wiki/strongswan/IKEv2CipherSuites so that it maps to http://www.iana.org/assignments/ikev2-parameters I'm focusing on Integrity Algorithms at this moment: I suggest to add additional columns that refer to the information given in the IANA document. An example should help clarify this: Keyword: sha2_256 or sha256 Description: SHA2_256_128 HMAC IKE: 128 bit ESP: 128 bit Name (according to IANA) (new column): AUTH_HMAC_SHA2_256_128 Registry Number (new column): 12 I also suggest to make it very clear that sha2_256_96 is not a standard transformation but Linux/strongSwan proprietary. Also, please mention the registry number you allocated in the private use block. I do believe that interoperability does benefit from this documentation change. I can help out and take care of the changes if you let me. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Policies should be available in Kernel even though SA is not established!
Hi Ashish, did you try auto=route in ipsec.conf? strongSwan should then install the policies and leave them installed if the connection goes down. An outgoing packet triggers a negotiation of an appropriate SA. It might also be worth having a look at the installpolicy parameter: ---QUOTE--- installpolicy = yes | no decides whether IPsec policies are installed in the kernel by the IKEv2 charon daemon for a given connection. Allows peaceful cooperation e.g. with the Mobile IPv6 mip6d daemon who wants to control the kernel policies. ---END QUOTE--- If you use installpolicy=no, you might be able to install the policies by yourself. -Daniel ashish mahalka wrote: Hello Andreas, Hope you are having a good time! I have certain queries for which if you can provide me answers/solutions would be really great. #1 - Policies should be available in the kernel even though SA is not established. I have this particular requirement wherein the kernel should have all the policies in its database even though strongswan fails to establish the SA. Right now policies are put by strongswan only when the SA's have been established. I tried to overcome this limitation by manually adding the policies using ip xfrm policy add command. But when strongswan established the SA and tried to over-write already existing kernel policies, it failed. Is this expected or something is going wrong here ? Then I came across ipsec route command which adds the policies in the kernel. When I executed the command ipsec route conn-name, it added only the outbound policy. Whereas I need both inbound/outbound policy.Again is this behaviour correct ? Can some modification be done to include inbound policies also with this command ? #2 - When the connection goes down, the policies should be updated in the kernel. Again this requirement arises from the fact that when a particular connection goes down, the SA/SPD in the kernel also gets deleted. But I need to still have the policies in the kernel. To get this work done, I made use of left|rightupdown option available in the ipsec.conf. I wrote a small shell-script and made use of PLUTO_ macros available in strongswan to get the policy details. I was successful till here. But I have some conflicting observations: a) In case of pluto, when I execute the command ipsec down conn, my script is executed when down-client case arises. Here I tried to add the polices in the kernel using ip xfrm policy add command. It failed because the strongswan policies were still there in the kernel at this point. b) In case of charon, on saying ipsec down conn, my script was never executed. I remember you mentioning that in case of charon, ipsec update does not delete the old SAs/SPs. But I have observed that if you just say connection down on one peer only, the SAs/SPs are still there. You have to execute conn down in both the peers to remove the SAs/SPs. Can this be modified so that charon deletes the SAs/SPs when we say conn down on local peer. #3. Deleting the strongswan configured policies through external application. Is it possible to delete the strongswan policies manually ? I tried deleting policies configure in the kernel through strongswan but got some NETLINK error. I executed the following command. /sbin/ip xfrm policy delete 10.10.10.0/24 10.10.10.0/24 proto 6 sport 200 dport 200 dir out action allow/block. Basically I tried both allow/block options in the action field. But it failed. Is there any other way to remove the strongswan policies ? Do we need to make use of reqId. It would be really nice if you could give me some pointers on how to go about meeting this requirments. Thanks for all the help in advance! regards, Ashish. ___ 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] Problems with network-manager-strongswan on Ubuntu Karmic
Patrick Ben Koetter wrote: * Andreas Steffen andreas.stef...@strongswan.org: the Debian/Ubuntu package is based on strongSwan 4.2.9 without any augmentations. The ipsec.secrets include feature has always been in the man pages because the IKEv1 pluto daemon supported it. We have just recently extended this feature to the IKEv2 charon daemon triggered by a user request. let me rephrase: The current Debian/Ubuntu package does not support an include statement in ipsec.secrets. It's an implementation fault. Don't use it. ;) Servus Patrick, that's, in my opinion, a bit confusing for new users: strongSwan ships two daemons - charon which implements the new IKEv2 protocol and - pluto which implements the old IKEv1 protocol. You are using charon for your setup. The thing that is IMHO confusing is that *both* daemons read the *same* config files (ipsec.conf and ipsec.secrets) but interpret them *differently* in some cases. As regards the old strongSwan version you are using, pluto does support include statements whereas charon does not. As a result, it depends on which daemon is reading the config file. Newer versions of charon do support the include statement. So the behavior is more consistent with newer versions of strongSwan. Does that make sense? -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Problems with network-manager-strongswan on Ubuntu Karmic
Patrick Ben Koetter wrote: Jan 31 23:05:50 gw charon: 07[IKE] no private key found for 'C=DE, ST=Bayern, L=Muenchen, O=State of Mind, OU=VPN, CN=gw.state-of-mind.de, e...@state-of-mind.de' This should be at least the current problem, right? Correct. Please post the output of ipsec listcerts It should say something like 000 pubkey:RSA 1024 bits, has private key for the certificate of the subject 'C=DE, ST=Bayern, L=Muenchen, O=State of Mind, OU=VPN, CN=gw.state-of-mind.de, e...@state-of-mind.de' Check your /etc/ipsec.secrets file. Make sure it's in the correct format. Also, try ipsec rereadsecrets and check the log file for error messages. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] rightid=%any or wild characters - ikev1 not working
Hi Ashish, here are my test results: You can't use right=1.2.3.4 and right=%any at the same time i.e. you can't specify an IP address for the remote end and use %any for the ID. However, DN wildcards appear to work ok. I just spotted a typo in your original mail: rightid=C*, ST=*, O=*, OU=*, CN=*, E=* You're missing a character there. It's should be: rightid=C=*, ST=*, O=*, OU=*, CN=*, E=* I successfully tested it with a simpler pattern: rightid=/CN=*/ I should mention, though, that the certificate I'm using only has a Common Name (CN), no other RDNs. What I can read from your config files is that you do know the remote IP address but you do not know the DN of the peer. Is that correct? -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] rightid=%any or wild characters - ikev1 not working
Hi Ashish, when I carried out the test, I was thinking about an instance of strongSwan that only *responds* to connection setup requests. I did not have strongSwan *initiate* connections. What you are basically saying to strongSwan is: Initiate a connection to 10.10.10.2. Ignore the identity of the peer because I do not know it. But make sure that the peer has a valid certificate that is signed by a CA I trust. This kind of configuration is unusual in my opinion because you are trying to initiate a connection but you do not even know what the identity of the peer is. However, it makes sense to *respond* to requests from unknown peers because those requests might come from road warriors. I'm afraid that pluto simply does not support the kind of configuration you are thinking about. Charon apparently does support it. I do not know whether this is a limitation of the protocol (IKEv1) or the implementation (pluto). I suggest addressing the strongSwan core developers and ask if there is a way to overcome this limitations. -Daniel ashish mahalka wrote: Hi Daniel, Yes, you are correct. I know the remote IP address but dont know the DN of the remote peer. If I remember correctly, when using DN wildcards, I was getting error which said cannot initiate connection with wildcards. I am using strongswan 4.3.4. Can you tell me what version of strongswan u r using ? Also, would it be possible to establish the connection if we specify rightid=/CN=*/, though the DN of the peer contains all the values( I mean C, ST, O,...) If possible, can you please test on your setup, if specifying rightid=C=*, ST=*, O=*, OU=*, CN=*, E=* like this establishes the connection. Thanks in advance! regards, Ashish. On 1/19/10, Daniel Mentz danielml+mailinglists.strongs...@sent.com wrote: Hi Ashish, here are my test results: You can't use right=1.2.3.4 and right=%any at the same time i.e. you can't specify an IP address for the remote end and use %any for the ID. However, DN wildcards appear to work ok. I just spotted a typo in your original mail: rightid=C*, ST=*, O=*, OU=*, CN=*, E=* You're missing a character there. It's should be: rightid=C=*, ST=*, O=*, OU=*, CN=*, E=* I successfully tested it with a simpler pattern: rightid=/CN=*/ I should mention, though, that the certificate I'm using only has a Common Name (CN), no other RDNs. What I can read from your config files is that you do know the remote IP address but you do not know the DN of the peer. Is that correct? -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] rightid=%any or wild characters - ikev1 not working
Hi Ashish, thank you for the log files. The following lines which I copied from pluto-host2.log are the most interesting: conn1 #1: no suitable connection for peer 'C=IN, ST=KAR, O=WIPRO, OU=NSN, CN=wipro.com, e=...@wipro.com' conn1 #1: sending encrypted notification INVALID_ID_INFORMATION to 10.10.10.2:500 Please get rid of rightid=%any on host2. Execute the command ipsec update and ipsec statusall Please send the output of the last command. Try to setup the connection again with rightid=%any removed and send the log file of host2. Thanks -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] rightid=%any or wild characters - ikev1 not working
ashish mahalka wrote: rightid=%any or rightid=C*, ST=*, O=*, OU=*, CN=*, E=* I get an INVALID_ID_INFORMATION error. Please provide more information than that. Please send the ipsec.conf files of both peers. Plus the syslog output. If one end-point receives an INVALID_ID_INFORMATION error, the log file of the other peer usually contains provides information about the reason why it sent INVALID_ID_INFORMATION. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan gateway behind NAT
Eldar Yusupov wrote: How should I alter the strongSwan config? It seems to me that I've specified that my subnet is 192.168.1.0/24 http://192.168.1.0/24 there. Try leftsubnet=0.0.0.0/0 I'm using Cisco VPN client at the moment, however I plan to change it later. In any case I'd like to keep the most of the configuration details defined on the gateway, not the client. That sounds reasonable. The concept of Cisco's VPN client is to tunnel all traffic through your IPsec gateway not only the traffic that is destined for your subnet i.e. 192.168.1.0/24. In a default configuration the Cisco VPN client does not allow you to access any host on the Internet without passing through the VPN gateway. I'm not an export on Cisco's VPN client, though. Maybe you find a solution that fits your needs. You can also try the VPN client of Shrew Soft. NCP Secure Entry Client for Win32/64 is even better but costs 142 EUR per license. Am I correct that in theory strongSwan should notify the peer about the local subnet, however for some reason this does not happen or the peer discards that information? That is true for IKEv2. Maybe Cisco has some proprietary extension for IKEv1 which supports that as well but I guess not. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] [strongswan]ikev2 with plutostart=yes
ashish mahalka wrote: I might further add here that host1 has only ipv4 support whereas host2 has both ipv4 and ipv6 support. I am not sure whether this information does matter in the creation of the sockets for charon. I remember that there was some kind of problem related to ipv4 and ipv6 support. Have a look at https://lists.strongswan.org/pipermail/users/2008-November/002925.html and check if this is related to your problem. Also please run netstat --raw -a -p and netstat --ip -a -p -n | grep -E :4?500 and post the output. The first command should list charon in the Program name column. Thanks -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Establish connection with DynDNS peer
Peter Daum wrote: B is a Bintec VPN25 router with a dynamic address published via DynDNS. A tries to bring the tunnel up. However, A fails since it tries to connect to the OLD IP address. A ping from A to B shows that name resolution works perfectly. So A seems to cache the old IP address within strongSwan and does not update it. Why does strongSwan not recognize the new address? The only thing which helps is a ipsec update. This is not feasible as I would have to have a script in place monitoring the connections, recognizing the tunnel went down and issuing a ipsec update (albeit not too early). Hi Peter, there's this tool called starter. It reads the config file, resolves the DNS name into an IP address and provides the connection definition including the IP address to pluto. pluto is the IKEv1 daemon. IMHO, it only deals with IP addresses. It does neither store nor resolve the DNS name of the peer. Only if you run ipsec update, the tool starter kicks in again, performs a fresh DNS lookup and provides the altered connection definition to pluto. I can think of three different solutions: 1. Tweak pluto so that it saves FQDNs instead of IP addresses and performs a new DNS lookup after it declared its peer dead. This would result in a rather large modification of pluto. 2. Configure strongSwan to respond to setup requests but not to initiate connections. Can you configure the Bintec router in a way that it re-initiates the IPsec connection everytime it reboots? Does it support DPD? The Bintec router should basically keep the connection permanently open. 3. Follow Gerd's recommendation and make use of ipsec starter --auto-update seconds. But I personally don't like this solution because it hammers the DNS server. Plus the update of the IP address might be delayed for up to seconds. Btw, can you recommend Bintec's VPN25 router? Does it support NAT-T (NAT traversal), DPD and certificate based authentication? I recently evaluated a Netgear FVS318 v3 and I got disappointed. It does not support NAT-T. The support for X.509 certificates is bad (you cannot import private keys) plus the whole firmware crashes when I try to connect to strongSwan. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Multiple CA Cert support in ipsec.conf
vivek bairathi wrote: Actually my problem is I can't specify the directory. I don't want the files for cacert to be picked from /etc/ipsec.d/cacerts/. I can only specify filename as many other files are going to be there in that directory, so for that I need the entry in ipsec.conf in the way I have written. Try defining a ca section for each CA certificate: http://wiki.strongswan.org/wiki/strongswan/CaSection This does not require you to store the certificates in /etc/ipsec.d/cacerts/. You can store them in other locations. Is that an option for you? ca Plane cacert=/home/vivek/RootCert1.pem,/home/vivek/RootCert2.pem crluri=/home/vivek/crl.pem auto=add Is this not possible? I guess you can specify only a single file as cacert. Is there no way to mention file names for all ca certs in ipsec.conf ? I guess not. Is it possible to change the code to made this thing possible? Sure. You can always change the code. Using --sysconfdir= when running ./configure might be an option. But then strongSwan also looks for ipsec.conf in a different directory. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Multiple CA Cert support in ipsec.conf
vivek bairathi wrote: If I have two ca certicficates then should I write the name of the file of cacertificates like the following way: ca Plane cacert=/home/vivek/RootCert1.pem,/home/vivek/RootCert2.pem crluri=/home/vivek/crl.pem auto=add You can store both ca certificates in /etc/ipsec.d/cacerts/ and remove cacert= from the connection definition. As a result, the two CAs will be accepted for other connections as well plus all other CAs in this directory are eligible for the connection in question. You can use a ca section inside ipsec.conf to specify the CRL URI: http://wiki.strongswan.org/wiki/strongswan/CaSection Is that an option for you? -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Try to use Cisco VPN client
Kalaj wrote: just want to use Cisco VPN client to connect Strongswan but failed. Used x509 authentication and enable --cisco-quirks , maybe I made a wrong certs or wrong conf, can you guys give me some advices? Thanks. Please provide more details that enable troubleshooting: log files and the exact error message you get from Ciscos VPN client. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Try to use Cisco VPN client
Kalaj wrote: conn %default ikelifetime=60m keylife=20m keyexchange=ikev2 rekeymargin=3m keyingtries=1 left=167.22.15.11 leftnexthop=167.22.15.1 leftcert=no2.crt left...@test leftsourceip=10.3.0.1 leftsubnet=0.0.0.0/0 right=%any rightsourceip=10.3.0.2 rightsubnet=10.3.0.0/24 auto=start You set up a some default parameters for connection definitions. But you still have to define at least a single connection. The conn %default clause specifies defaults parameters that will be used if an individual connection definition does not specify other values. But you failed to provide a single connection definition. Please post your new ipsec.conf plus the output of ipsec statusall. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Try to use Cisco VPN client
cisco[3] 218.240.6.69:56131 #3: policy does not allow XAUTHInitRSA authentication. Attribute OAKLEY_AUTHENTICATION_METHOD Not sure if that helps, but have a look at: http://www.strongswan.org/docs/readme4.htm#section_14.6 Try adding authby=xauthrsasig xauth=server -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Try to use Cisco VPN client
The following log messages is most relevant: cisco[5] 218.240.6.69:56413 #5: next payload type of ISAKMP Hash Payload has an unknown value: 197 I can't tell why the Cisco VPN client sends this type of payload. 197 is vendor specific. Only the strongSwan developers can help in that situation. What version of Ciscos VPN client are you using? ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] [strongswan]ikev2 with plutostart=yes
ashish mahalka wrote: Strongswan runs at the other end. i m not sure whether the packets where reaching the other end or not. But one thing is sure, there was no response from strongswan on the other end. I'm afraid you have to find out whether the packets make it to the other end. Are you familiar with tcpdump? tcpdump -npi ppp0 udp port 500 or 4500 should do the job. Replace ppp0 with the name of the interface you want to sniff on. Also, keep an eye on the syslog output of strongSwan at the remote end. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] NAT problem
Hi Jessie, I think you have to distinguish between transport mode and tunnel mode. In tunnel mode, the UDP-encapsulated ESP packet contains a complete IP packet. The outer IP header as well as the UDP header are simply discarded in that case. The IP packet which is carried by ESP has its own IP header. Not sure about transport mode, though. I remember Andreas saying that transport mode is insecure if used together with NAT traversal. I guess the receiving end can reconstruct the original IP header by querying the Security Policy Database. Did you check http://unixwiz.net/techtips/iguide-ipsec.html ? It has some good information on ESP and AH. -Daniel Jessie Liu wrote: Hi Andreas , When the UDP-encapsulated ESP traffic goes through NAT device and reaches the destination end, what will the destination endpoint do to the received packets? Following is my understanding, please correct me if there is anything wrong, thanks. The destination end will first check the outer IP header and then take off the UDP header, (of course the destination end has to support NAT-Traversal) and modify the outer IP header to the original IPsec outer IP header? After this, the ESP packet could be processed as usual. Is my understanding correct? If this is true, how the destination end reconstructs the outer IP header? Could you provide an example? Thanks ! ^__^ ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] [strongswan]ikev2 with plutostart=yes
ashish mahalka wrote: Basically the requirement is like there are two conn sections in ipsec.conf. One conn uses IKEv1 and the other uses IKEv2. Is it possible for the host strongswan to have IKEv1 and IKEv2 SA simultaneously with other strongswan peers ? Yes, that is indeed possible. Please provide more information like the output of charon. You're just saying I cannot establish IKEv2.. That is not enough information to help you. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Regarding CN as left/rightid
vivek bairathi wrote: Some doubts regarding CERT mode:- 1. Is it necessary to know the CN of peer before establishing an IKE SA? Generally speaking, no. It depends on your individual configuration. You can setup strongSwan in a way that it accepts an arbitrary DN. Wildcard matching is also provided. This is probably true if strongSwan is responding to a request to set up an IKE SA. I'm not sure what the rules are when strongSwan initiates a connection. 2. Is the left/rightid is always equal to the CN from the certificate? If leftid/rightid is a DN it must be equal to the DN in the certificate. If it is a FQDN, then this FQDN must be contained in the certificate as a subjectAlternativeName. Not sure about e-mail addresses and IP addresses, though. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] DNS resolution - revisisted
Andreas Steffen wrote: | right=home.example.com # bad addr: right=home.example.com [does not look numeric and name lookup failed] Well, if no default route exists then the host most probably is also not able to resolve hostnames via DNS. Did you try if nslookup works before starting the IKE negotiation? Hello Andreas, the laptop was indeed offline at that time. That's why there's no default route. My plan is to start charon at the time the laptop boots. By the time the PPP connection comes up, I call ipsec up home from /etc/ppp/ip-up. I also tried to call ipsec update from /etc/ppp/ip-up but that did not work out either. There appears to be a race condition. Starter still can't resolve the FQDN at that time. If I sleep 1 first and then call ipsec update, it works ok. But I don't like using sleep for that purpose. Getting back to the original problem: I had a look at confread.c: If ttoaddr() returns does not look numeric and name lookup failed, confread.c sets the address of the remote end to %any. To me, it looks like that starter never passes FQDNs to charon but only IP addresses. If I use right=%home.example.com, starter adds the connection but with in improper remote address (%any). Could you please comment on this. How can I pass FQDNs to charon? I'm also confused by the syntax of the stroke command. Add a connection: stroke add NAME MY_ID OTHER_ID MY_ADDR OTHER_ADDR\ MY_NET OTHER_NET MY_NETBITS OTHER_NETBITS where: ID is any IKEv2 ID ADDR is a IPv4 address NET is a IPv4 subnet in CIDR notation We haven't updated the stroke command line connection configuration option for years. Thus don't be surprised if nothing more than some very basic configurations actually work! Ok. Thanks for pointing this out. Best regards Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] DNS resolution - revisisted
Andreas Steffen wrote in his e-mail on dec 24: .the IKEv2 charon daemon receives the FQDN as a string via the stroke interface and does name resolution on the fly shortly before actually negotiating the IPsec tunnel. This appears not to work for me. The output of starter is as follows: Starting strongSwan 4.3.5 IPsec [starter]... no default route - cannot cope with %defaultroute!!! | Loading config setup | charonstart=yes | plutostart=no | Loading conn 'home' | keyexchange=ikev2 | left=%any | leftsourceip=%modeconfig | leftcert=danielCA_daniel-notebook.pem | leftfirewall=yes | right=home.example.com # bad addr: right=home.example.com [does not look numeric and name lookup failed] | rightid=/CN=Vaterstetten/ | rightsubnet=192.168.10.0/24 | dpdaction=restart | auto=add Please note that home.example.com is not the real DNS name. I replaced the real one for security reasons. I'm also confused by the syntax of the stroke command. Add a connection: stroke add NAME MY_ID OTHER_ID MY_ADDR OTHER_ADDR\ MY_NET OTHER_NET MY_NETBITS OTHER_NETBITS where: ID is any IKEv2 ID ADDR is a IPv4 address NET is a IPv4 subnet in CIDR notation It clearly states that it requires an IPv4 address no FQDN. Could you please help me with that. Thanks -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] feature request: Give a hint if --enable-eap-mschapv2 is not set
I tried to setup a strongSwan as a gateway for Windows 7 (MSCHAPv2). But it did not work. After some time of troubleshooting, it turned out that I failed to include the following parameters when running ./configure --enable-eap-mschapv2 --enable-md4 The log file of strongSwan wasn't very helpful while troubleshooting. My request is to improve on that. Example: If I include the following line in ipsec.conf leftauth=eap-mschapv2 and eap-mschapv2 is not compiled in, it should tell me something like Hey dude, you're trying to use MSCHAPv2 but it's not compiled in. Check the installation instructions and recompile Also, I think the autoconf script should complain if I enable eap-mschapv2 but not md4 at the same time. Should we add this hint also to the wiki page? I think we should. Thanks -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Several TS on a same connection
Hi Andreas Schuldei, Andreas Schuldei wrote: On Sat, Dec 26, 2009 at 5:11 PM, Daniel Mentz danielml+mailinglists.strongs...@sent.com wrote: Hi Andreas Schuldei, I guess that IKE traffic on port 500 is never protected by ESP because it has its own protection which is the IKE SA. So don't worry about IKE traffic. i didnt talk about protection but rather distortion that you get when the ipsec connection is somehow confused and traffic cant pass through it properly. is the port 500 exempted from going through the ipsec connection? then i am happy and wont worry about traffic interruptions that become longer then necessary. it would certainly make sense to special-case port 500. IKE traffic which runs on port 500 and 4500 is excluded from IPsec processing. Therefore, this kind of traffic will not be wrapped inside ESP packets. I do not know how this works, though. Either the kernel is clever enough to exclude it or strongSwan uses some special socket. Regarding ssh I do understand the problem. What you might want to try out is a passthrough setup like the one described on http://www.strongswan.org/uml/testresults43/ikev1/passthrough/ Try setting up a passthrough connection with a proto/port specification. Maybe the kernel selects the most specific policy for ssh traffic which is the passthrough policy. then i would need one additional connection definition for each host-host pair? that would double the size of my configuration files from very large to very very large (in case of my full mash of hosts). cant that be done more elegantly? Very interesting topic. A spent a few hours doing research on that. I kind of solved your problem by using the following commands to add entries to the Security Policy Database (SPD): ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp sport 22 dir in priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp sport 22 dir fwd priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp dport 22 dir out priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp dport 22 dir in priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp dport 22 dir fwd priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp sport 22 dir out priority 100 Please note, that the priority value is actually a bit confusing. Policies with lower priority values have higher priority. So priority 100 wins over priority 200. I also tried to use strongSwan's passthrough policy but this did not work out because strongswan assigned the corresponding policies a higher priority value which in effect means that they have lower priority. @strongSwan team: How can I control the priority values of the policies? If you run the commands above, all SSH traffic should be excluded from IPsec processing as long as there are no other policies with lower priority values. -Daniel Personally, I usually depend on a third host that I can use for troubleshooting. If the IPsec connection between A and B fails, then I can ssh to C and from there login into B. i have third hosts, too. Does that help? -Daniel Andreas Schuldei wrote: hi Andreas! (thanks to this thread i just discovered traffic selectors, reading this mailing list DOES help! :-) what i would like to do is to NOT send ssh (port 22) and ike2 traffic (port 500) via ipsec. that is because back in 2000 when i worked with ipsec i discovered that if the encrypted connection hang for some reason i would be unable to reach the other side via ssh (and fix the remote problem) and the connection could not be renegotiated quickly becaus even the key exchange could not be done because the connection which was responsible for renegotiation was unavailable. for that reason i would like to exclude those two ports from ipsec-transportation. but the syntax for transport selectors does not provide for a dont add THIS port to ipsec, does it? apart from this: do you people observe the described failiour modes in real life? perhaps these issues went away in the mean time. /andreas On Sat, Dec 26, 2009 at 2:48 PM, Andreas Steffen andreas.stef...@strongswan.org wrote: Hello Mugur, it does not matter if you define each tunnel between two peers independently or if you use conn %default or an also= construct to save typing work. All tunnels, i.e. a definition of traffic selectors are grouped under the same IKE_SA which is going to be established between the two peers. The IKEv2 charon daemon allows the enumeration of several traffic selectors for the same CHILD_SA using left|rightsubnet: leftsubnet=10.1.0.0/16,10.3.0.0/16 rightsubnet=10.2.0.0/16,10.4.0.0/16 will establish the following four IPsec SAs with a single CHILD_SA: 10.1.0.0/16 - 10.2.0.0/16 10.1.0.0/16 - 10.4.0.0/16 10.3.0.0/16 - 10.2.0.0/16 10.3.0.0/16 - 10.4.0.0/16 Currently traffic selectors with protocol/port restrictions using the left
Re: [strongSwan] Several TS on a same connection
Hi Andreas Schuldei, I guess that IKE traffic on port 500 is never protected by ESP because it has its own protection which is the IKE SA. So don't worry about IKE traffic. Regarding ssh I do understand the problem. What you might want to try out is a passthrough setup like the one described on http://www.strongswan.org/uml/testresults43/ikev1/passthrough/ Try setting up a passthrough connection with a proto/port specification. Maybe the kernel selects the most specific policy for ssh traffic which is the passthrough policy. Personally, I usually depend on a third host that I can use for troubleshooting. If the IPsec connection between A and B fails, then I can ssh to C and from there login into B. Does that help? -Daniel Andreas Schuldei wrote: hi Andreas! (thanks to this thread i just discovered traffic selectors, reading this mailing list DOES help! :-) what i would like to do is to NOT send ssh (port 22) and ike2 traffic (port 500) via ipsec. that is because back in 2000 when i worked with ipsec i discovered that if the encrypted connection hang for some reason i would be unable to reach the other side via ssh (and fix the remote problem) and the connection could not be renegotiated quickly becaus even the key exchange could not be done because the connection which was responsible for renegotiation was unavailable. for that reason i would like to exclude those two ports from ipsec-transportation. but the syntax for transport selectors does not provide for a dont add THIS port to ipsec, does it? apart from this: do you people observe the described failiour modes in real life? perhaps these issues went away in the mean time. /andreas On Sat, Dec 26, 2009 at 2:48 PM, Andreas Steffen andreas.stef...@strongswan.org wrote: Hello Mugur, it does not matter if you define each tunnel between two peers independently or if you use conn %default or an also= construct to save typing work. All tunnels, i.e. a definition of traffic selectors are grouped under the same IKE_SA which is going to be established between the two peers. The IKEv2 charon daemon allows the enumeration of several traffic selectors for the same CHILD_SA using left|rightsubnet: leftsubnet=10.1.0.0/16,10.3.0.0/16 rightsubnet=10.2.0.0/16,10.4.0.0/16 will establish the following four IPsec SAs with a single CHILD_SA: 10.1.0.0/16 - 10.2.0.0/16 10.1.0.0/16 - 10.4.0.0/16 10.3.0.0/16 - 10.2.0.0/16 10.3.0.0/16 - 10.4.0.0/16 Currently traffic selectors with protocol/port restrictions using the left|rightprotoport parameters cannot be grouped together in a single CHILD_SA. You will have to define a separate conn description for each protocol/port combination resulting in a separate CHILD_SA exchange. Thus the example conn net-net also=host-host leftsubnet=10.1.0.0/16,10.3.0.0/16 rightsubnet=10.2.0.0/16,10.4.0.0/16 auto=start conn proto1 also=host-host leftsubnet=10.5.0.0/16 rightsubnet=10.5.0.0/16 leftprotoport=tcp rightprotoport=tcp/http auto=start conn proto2 also=host-host leftsubnet=10.5.0.0/16 rightsubnet=10.5.0.0/16 leftprotoport=tcp rightprotoport=tcp/smtp auto=start conn host-host left=IP address of left right=IP address of right would create six IPsec SAs between left and right, using a primary IKE_AUTH and two additional CHILD_SA exchanges. Best regards Andreas ABULIUS, MUGUR (MUGUR) wrote: Hello, I looked to strongSwan connection parameters (http://wiki.strongswan.org/wiki/1/ConnSection) and I am not sure how to define several tunnels between the same endpoints, each tunnel with several traffic selectors. In my understanding an independent tunnel is defined by a conn name directive with the condition that its body does not contain an also = section name directive. Now, I want, for each tunnel to include several traffic selectors; i.e. several left|rightprotoport = protocol/port and several left|rightsubnet = ip subnet. Moreover I want to combine traffic selectors in a specific way for a same connection. For example to specify somehow leftprotoport=icmp ONLY for leftsubnet= 192.168.10.0/24 and leftprotoport=UDP ONLY for leftsubnet= 172.16.10.0/24 Can you please specify which are all possibilities of using the IKEv2 extended traffic selector concept with strongSwan. 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
Re: [strongSwan] with ipsec in place, how to replace ssh?
Andreas Schuldei wrote: hi! now that i have ipsec in place, how do i replace ssh? i would like to avoid double encryption, in order to not create extra work. Hi Andreas, I recommend not to replace ssh even in the presence of IPsec. Accept the fact that traffic is encrypted and authenticated twice. I think the impact on performance is negligible. The advantage is that you only have to maintain a single daemon on the server side. You don't need to take care of another server daemon for rsh. It's also more comfortable from a user perspective. The rule of thumb is: Remote access == ssh. The user does not need to decide between ssh and rsh which would require him to be aware of the underlying network infrastructure. how well do rsh, rcp and friend perform? i see there is a package rsh-redone-server (and client) in debian, working over inetd. does anyone use those? did someone come up with a useful set of iptable rules in order to allow the use of the respective ports only when coming from esp (or whatever good criteria there might be)? Can you read German? If yes, check out http://www.linux-magazin.de/heft_abo/ausgaben/2006/08/doppelnase If not, then search for ipsec policy match. The man page of iptables also provides some pieces of information. Type in man iptables and search for This modules matches the policy used by IPsec for handling a packet. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] just-in-time initiation of SAs?
Hello Andreas Steffen, this is an interesting topic. I'm wondering whether people should be advised to add dpdaction=hold to their ipsec.conf. I tried to setup a configuration that is similar to Andreas Schuldei's. The thing that was special about my setup is that it uses an ADSL dialup connection that disconnects every 24 hours. As a result, the ppp0 interface disappears and reappears shortly after. The problem I experienced was that the tunnel did not survive this short outage and strongSwan failed the connection. What made me worry is that strongSwan deleted the IPsec policy completely. The consequence was that traffic was sent unprotected i.e. unencrypted! If I set auto=route, I expect strongSwan to setup the IPsec policy and refrain from deleting it *in any event*. Please correct me when I'm wrong. -Daniel Andreas Steffen wrote: Hello Andreas, set up all the connections with auto=route which will install only the corresponding IPsec policies in the Linux kernel. As soon as the first packet wants to leave a host in direction to another host for which a secure connection is defined, the matching IPsec policy will trigger the IKE daemon and cause it to negotiate the IPsec tunnel just in time. Best regards Andreas Andreas Schuldei wrote: hi! i would like to inititate my SAa just in time, meaning that they should only set up the secure connection when there is real traffic, not ahead of time. background to that is that i want to do a full mash of host-to-host transports, both within one site in order to get rid of firewalls per site, and between sites, to avoid setting up tunnels between sites. not every host will talk to every other host all the time, but they might need to talk to any given host within the whole setup sooner or later. in order to not having to initiate a connection to every other host at ipsec startup i would like to configure strongswan in a way that it would only set up the secure host-to-host transport when its needed. otherwise i might be DoSing myself when a whole site gets cut off from the net and then later comes back again and a few hundret servers initiate connections to the rest of the network all at once. how can i solve that? /andreas ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan ipsec pki
Jean-Michel Pouré wrote: After compiling and installing strongswan 4.3.5, ipsec pki does not work: ipsec pki /usr/sbin/ipsec: unknown IPsec command `pki' (`ipsec --help' for list) Hi Jean-Michel, after compiling strongswan, do you have an executable called pki in strongswan-4.3.5/src/pki ? This binary should be installed to /usr/lib/ipsec. The exact path may be different on your system, though. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Help writing a Debian howto : adding to NetworkManager examples to IKEv2Examples
Jean-Michel Pouré wrote: Would it be possible for you to publish this page: http://wiki.strongswan.org/wiki/strongswan/NetworkManager In the IKEv2 examples: http://wiki.strongswan.org/wiki/strongswan/IKEv2Examples Hi Jean-Michel, I'm not quite sure if I got your question right. Could you please rephrase it? The URLs you mentioned are publicly available already. Are you asking for permission to redistribute this material? You have to ask the respective authors then. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan ipsec pki
Jean-Michel Pouré wrote: There is no pki after a successful compilation. My compilation line was: 1 cd strongswan-4.3.5 2 make clean 3 ./configure --disable-pluto --disable-tools --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib \ --disable-tools disable additional utilities (openac, scepclient and pki). Please retry without this switch. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Help writing a Debian howto : adding to NetworkManager examples to IKEv2Examples
Dear Jean-Michel, I'm glad that you take on the challenge and write a guide for beginners. I guess that a lot of users will be grateful for your documentation. Maybe you can continue the work of Ralf Spenneberg and update his IPsec Howto at http://www.ipsec-howto.org/ What about the note at the bottom of http://wiki.strongswan.org/wiki/strongswan/NetworkManager Depending on the used authentication methods, you can use gateway configurations very similar to Windows 7 (Certificate/MSCHAPv2), or use EAP-GTC to authenticate against PAM. Doesn't this help you to setup the server side. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Nokia VPN Client IKEv2
Robert Markula wrote: If the subjectAltName = DNS:cray.home.ro, this would be cray.home.ro, right? Yes And, one final question: if using the subjectAltName or the Subject DN, what kind of Remote ID type would that be on the client side? RCF_822_NAME or FQDN? I guess it's ID_DER_ASN1_DN or just DN if you use the subject DN. It's ID_FQDN if the type of the subjectAltName is DNS and ID_USER_FQDN if the type of the subjectAltName is e-mail address. Speaking about DNs. I'm not an expert on that topic but it might be worth the effort to find out how nokia encodes DNs. There are different formats out there. Examples: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com emailaddress=premium-ser...@thawte.com,CN=Thawte Premium Server CA,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA Those two lines represent the exact same DN. The encoding is just different. Also, note that the order of the RDNs i.e. the individual components like CN etc. is significant. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Issue about the tunnel
weiping deng wrote: I initiate ping form HNB (192.168.253.88 --- virtual ip) to GW (192.168.253.98- additional ip), but from tcpdump, I see: Only the packages go through normal tunnel (172.19.2.118 - 172.19.2.247) is ESP. And The packages go through virtual tunnel (192.168.253.88 192.168.253.98) is icmp Could you please rephrase the problem. Explain what you observed and how it differs from what you expect. Please do not send RAR files but rather .tar.gz files. The two files ipsec(client).conf ipsec(gw).conf were empty when I unpacked the RAR file. Please execute the following commands on *both* machines and send the resulting output. ip xfrm policy ip xfrm state ip route list table 0 Make sure to include the name of the host in the file name so that it is easy for us to distinguish those two hosts. The output of tcpdump might be helpful as well. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Access to local subnet when tunnel up
Hi Graham, could you please post the output of ip xfrm policy Hi Andreas, I guess that the problem is a different one. Graham uses two different source IP addresses depending on whether the traffic is destined for the local subnet or any other host on the Internet. He uses 192.168.50.154 as the source address for local traffic and 1.1.35.49 as the source address for traffic to all other destinations. So I guess he has to massage the routing table properly so that the kernel picks the correct source address for traffic originated from the local host. The ipsec policy only affects traffic with this pattern 1.1.35.49/32 = 0.0.0.0/0 So if the kernel picks 192.168.50.154 as the source address for local traffic then the policy does not match and there's also no need for a passthrough policy. So I guess it's all about setting up the routing table correctly. Please correct me if I'm wrong. -Daniel Andreas Steffen wrote: Hello Graham, this is a well known problem when all Internet traffic is going to be tunnelled via IPsec (rigthsubnet=0.0.0.0/, i.e. no split-tunneling) but local traffic should not go through the tunnel. The correct way to handle this is to define a passthrough IPsec policy for the local network 192.168.50.0/24 thus exempting it from IPsec. Since the IKEv2 charon daemon cannot set up passthrough policies [yet] I recommend to use the ip xrfrm policy command. Best regards Andreas Graham Hudspith wrote: Hello All, We're grappling with an access-to-local-subnet-when-the-tunnel-is-up problem. After a tunnel is brought up, the routing table is thus: *# ip route show* 192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.154 default via 192.168.50.1 dev eth0 *# ip route show table 220* default via 192.168.50.1 dev eth0 proto static src 1.1.35.49 where 1.1.35.49 is the tunnel's inner IP address. What we want is traffic destined for the local subnet (192.168.50.xx) goes via eth0 from the unit's IP address (192.168.50.154) and everything else to go via the tunnel. Unfortunately, that does not happen. If I ping something on the local subnet, it gets sent via the tunnel. The default route added in table 220 seems to take precedence over the subnet route in the default table. I've found two different ways to fix this. (1) Add the equivalent subnet route to table 220 ... ip route add 192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.154 table 220 or (2) (Quickly) delete the default routes from table 220 and the default table and then add in a new default route to the default table that is equivalent to the old one on table 220 ... ip route del default via 192.168.50.1 dev eth0 proto static src 1.1.35.7 table 220 ip route del default via 192.168.50.1 dev eth0 ip route add default via 192.168.50.1 dev eth0 proto static src 1.1.35.7 and then pings to the local subnet go via the local subnet and pings down the tunnel go via the tunnel. This is with strongSwan 4.3.5. Is this a bug in strongSwan ? Or, is this the expected (desired?) behaviour ? Or, am I misconfiguring something ? If this is the expected behaviour, how can I make strongSwan behave the way I want it too ? Recompile without support for table 220 ? Any hints gratefully received ! Regards, Graham. == 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 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] How can I shutdown the NAT-T feture of IKEv2
weiping deng wrote: How can I shutdown the NAT-T feature of IKEv2? http://wiki.strongswan.org/wiki/strongswan/ConfigSetupSection says NAT traversal is always being active in IKEv2. So I guess the answer is that you can't turn it off. Please explain your motivation for turning it off. Do you expect a more secure system? -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] How can I shutdown the NAT-T feture of IKEv2
Hi David, would you mind sharing the name of the other IKEv2 implementation you are using. Other users might be able to take advantage of this information. It's good to know with which implementations strongSwan inter-operates with and what the reasons are if inter operation fails. -Daniel weiping deng wrote: Because If two peer was placed into a no NAT environment, and one peer used strongswan, another peer used another IPsec tool. If strongswan default enable this NAT-T feature, and then the following message parsing will be encountered issues due to the 4 bytes of non-ESP and port floating RFC3948. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Sending eth1 traffic down eth0 tunnel
Hi Graham, I believe Andreas is correct. I just tried this here with my own setup. You can't depend on the MASQUERADE target if you want to source nat to the gateway's virtual IP address. This is what the man page says about MASQUERADE: Masquerading is equivalent to specifying a mapping to the IP address of the interface the packet is going out I infer that the kernel does not check the routing table when it selects an IP address as the source address. Try something like iptables -t nat -A POSTROUTING -s 172.16.250.0/24 -d 172.17.0.0/16 -i eth1 -o eth0 -j SNAT --to-source 10.10.2.147 If the address 10.10.2.147 is not static then you might need to come up with some fancy scripts that change the iptable rules everytime the IPsec tunnel comes up. -Daniel Andreas Steffen wrote: Hello Graham, the problem might be that although jupiter's satellites are NAT-ed to jupiter's eth0 address 192.168.50.159, jupiter itself uses the virtual IP address 10.10.2.147 within the IPsec tunnel. I know from personal experience that NAT-ing clients behind a gateway to the gateway's outer IP address will successfully route traffic through the tunnel (at least with Linux kernels = 2.1.16 which fixed a longstanding bug) but since the POSTROUTING -t nat chain is the last hook in the path it will not heed the source routing rule defined by table 220. Can you do without a virtual IP on jupiter? Regards Andreas Graham Hudspith wrote: Hi, I have a situation which I hope someone can please help me with. I have a machine (called jupiter) on our lan. Using it's eth0 NIC (we're talking linux, of course), jupiter can ping and connect to other machines on the lan. One machine it can reach (called saturn) acts as a gateway to a further network of machines (e.g. mimas, rhea, titan, etc.). These satellite machines can not be contacted directly by jupiter, they are hiding behind saturn. To get at them, jupiter has to set up a strongSwan tunnel. Once the tunnel is set up, jupiter can ping and connect to all of saturn's satellites. So far, so good. Now, we also have a network of machines hiding from the lan behind jupiter. These satellites of jupiter (e.g. io, europa, ganymede, etc.) are connected to jupiter's eth1 NIC. I've turned on ipv4 forwarding on jupiter and added an iptables nat rule to jupiter to allow these satellites access to the lan. However, the problem is that I have not found a way to allow jupiter's satellites access, through the tunnel, to saturn's satellites ? Is there something obvious I have missed ? Now for the details ... Our default gateway is 192.168.50.1 saturn has ip address 172.16.2.2 saturn's satellites have ip addresses in the range 172.17.x.x, e.g. titan (one of saturn's satellites) has ip address 172.17.100.151 jupiter has ip address 192.168.50.159 (acquired by dhcp from the lan for eth0) and 172.16.250.1 (statically assigned by jupiter for eth1). jupiter's satellites have ip addresses in the range 172.16.250.100-200 served by dnsmasq running on jupiter for eth1. At start-up, jupiter allows access to the lan for it's satellites via: iptables -t nat -A POSTROUTING -s 172.16.250.0/24 -o eth0 -j MASQUERADE echo 1 /proc/sys/net/ipv4/ip_forward Jupiter then sets up a strongswan (v4.3.2) tunnel using the following ipsec.conf: config setup charondebug=dmn 4, mgr 4, ike 4, chd 4, job 4, cfg 4, knl 4, net 4, enc 4, lib 4 plutostart=no conn %default ikelifetime=24h keylife=8h rekeymargin=3m keyingtries=1 keyexchange=ikev2 conn access-saturn-satellites left=%defaultroute leftid=036439001...@gan.mnc390.mcc364.3gppnetwork.org leftsendcert=never leftsourceip=%config right=saturn.foobar.com right...@saturn.foobar.com rightsubnet=172.17.0.0/16 authby=eap forceencaps=yes ike=aes128-sha-modp1024! mobike=no auto=start With the tunnel set up, ganymede (one of jupiter's satellites) can ping machines on the lan, but NOT ping saturn's satellites. The icmp request packets are sent out by jupiter onto the lan (and are therefore ignored) instead of being sent out over the tunnel to saturn. r...@jupiter:/opt/strongswan/sbin# ip addr show 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:17:3f:9b:8c:ad brd ff:ff:ff:ff:ff:ff inet 172.16.250.1/24 brd 172.16.250.255 scope global eth1 inet6 fe80::217:3fff:fe9b:8cad/64 scope link valid_lft forever preferred_lft forever 3: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:16:76:ca:bb:27 brd ff:ff:ff:ff:ff:ff
Re: [strongSwan] multiple traffic selector of which no local address is known
Joep Gommers wrote: 10.2.0.0/24 however is not a subnet in which the StrongS/WAN box resides. It resides behind yet another VPN appliance. So the routing table on the left side would include something like: to 10.2.0.0/24 via 10.1.0.254 metric 1 However, StrongS/WAN refuses to create the traffic selector giving me the error: no local address found in traffic selector 10.2.0.0/24 Hi Joep, I browsed the source code. If I understand it correctly the message you quoted is NOT an error message. The reason why strongSwan looks for a local address in the traffic selector is that it wants to install a route of this kind (if your router had a local IP address of 10.2.0.33): 10.2.0.0/24 dev ppp0 scope link src 10.2.0.33 But in your case there's no need to install such a route because your router is not in that subnet. What's the output of ipsec statusall ? Also, log files of charon would be helpful -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Problem on Virtual IP and SCTP packets
Jessie Liu wrote: But If I add leftsourceip=%config in ipsec.conf, the SCTP packets will not go through the tunnel, but ping packets will. ...If I remove leftsrouceip=%config from ipsec.conf, the SCTP packets will flow through the tunnel. Could you give me some hints what is happened and what should I check? I am using kernel version 2.6.28. Hi Jessie, what about TCP and UDP traffic? Do those packets stick to the tunnel? Your problem might be related to SCTP's multi-homing feature where each endpoint announces all of its IP addresses to the other peer. This is important for fail-over scenarios. In your case this feature might be counter productive. Both peers try to use all available paths that can be used to exchange data. But only one path is protected by IPsec. So I guess you need to setup firewall policies to block all alternative paths. This way you can force the SCTP implementation to use only one (secure) path. Let's say host A has IP address 1.1.1.10 and 2.2.2.10. Host B has 1.1.1.20 and 2.2.2.20. If host A initiates a connection to host B it sooner or later tries all four different combinations of IP addresses in the hope that the traffic flows on different paths if they switch the IP addresses. TCP always sticks to the same pair of IP addresses. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan - Linux Route Interaction Part 2
Hi Barry, I can confirm the behavior of the linux kernel. You need to set up a route to 192.168.2.0/24. It's not going to work otherwise. I understand that this is confusing. The nexthop determined by the routing table is irrelevant because an ESP and another IP header will be put in front of the existing IP header. The destination address from this new header will be the one that is relevant. But that's a feature of the Linux kernel and not specific to strongSwan. I can still think of situations where it makes sense to do a routing table lookup first: A route can be of type unreachable, prohibit or blackhole. In those cases the kernel should indeed check whether traffic may be routed to a given address. Also, you can specify a number of options per routing table entry like src address or cwnd (type in ip route help to get a list). If traffic originates from the local host then those options have to be accounted for before a packet is processed by IPsec i.e. the security policy database. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Internet traffic through VPN
Hi Tica, Hi strongSwan core developers, I just tried this kind of set up and it worked for me (although the setup was a bit tricky). Could you please provide us with more information regarding your setup. Please post the following files: ipsec.conf Post the output of the following commands as well: ip xfrm policy ip route show table 0 A network diagram would be useful as well. There's one question I would like to ask people on this list including the strongSwan core developers: I'm trying to setup a road warrior to pass all traffic (0.0.0.0/0) through the VPN tunnel. Only local traffic should be excluded. I'm using http://www.strongswan.org/uml/testresults43/ikev1/passthrough/ as a basis. In my setup the virtual IP address of the rw used inside the tunnel is different from the physical IP address in the local subnet. strongSwan inserts routing entries in the table 220. 0.0.0.0/1 via 192.168.10.2 dev eth0 src 10.33.44.1 128.0.0.0/1 via 192.168.10.2 dev eth0 src 10.33.44.1 10.33.44.1 is the virtual IP address inside the tunnel. Linux chooses this IP address as the source address for *local* traffic, too. But it shouldn't do that in my setup. I need linux to choose 192.168.10.78 as the source address for *local* traffic because that's the IP address of the interface. Routing table 220 has higher priority than the routing table main. Because of that the routing table entry 128.0.0.0/1 via 192.168.10.2 dev eth0 src 10.33.44.1 takes precedence over the correct routing table entry in table main for local traffic. What I ended up doing is to duplicate the routing table entry for local traffic and to insert it into table 220. 192.168.10.0/24 dev eth0 scope link 0.0.0.0/1 via 192.168.10.2 dev eth0 src 10.33.44.1 128.0.0.0/1 via 192.168.10.2 dev eth0 src 10.33.44.1 Does anybody know of a more elegant way to do that. For the sake of completeness here's the data of the local NIC. 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 192.168.10.78/24 brd 192.168.10.255 scope global eth0 inet 10.33.44.1/32 scope global eth0 Thanks Regards Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Internet traffic through VPN
Tica wrote: Now I need to route all internet traffic through the VPN... the remote office can only access internet through the main office structure. Yes. strongSwan provides this functionality. Are you using IKEv1 or IKEv2? Here's an example for IKEv1 you can take advantage of http://www.strongswan.org/uml/testresults43/ikev1/passthrough/ The key is to set rightsubnet=0.0.0.0/0 and to set up a pass through connection so that local traffic is not being processed by IPsec. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Trouble on establishing ESP channel
Salut Jean-Paul! A tcpdump on LAN interface Debian box shows the icmp request packets. A tcpdump on Public interface Debian box shows no icmp request packet. I have a similar setup here at our site. Regarding tcpdump you should see: - An outgoing ESP packet. (icmp request encrypted) - An incoming ESP packet. (icmp reply encrypted) - An incoming ICMP echo reply unencrypted. I admit that there's an asymmetry. One might expect to see a plaintext outgoing ICMP echo request. But that's a feature of the Linux kernel. The fact that your traffic doesn't go through appears like a firewall problem to me. Here are some examples from my setup: # Make sure not to block traffic handled by IPsec iptables -A FORWARD -s 192.168.99.0/24 -m policy --dir out --pol ipsec -j ACCEPT iptables -A FORWARD -d 192.168.99.0/24 -m policy --dir in --pol ipsec -j ACCEPT iptables -A INPUT -m policy --dir in --pol ipsec -j ACCEPT iptables -A OUTPUT -m policy --dir out --pol ipsec -j ACCEPT # Do not mess with packets comming over IPSec # Put those rules at the very top iptables -t nat -A PREROUTING -m policy --dir in --pol ipsec -j ACCEPT iptables -t nat -A POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT # Accept ESP traffic from ppp0 iptables -A INPUT -i ppp0 -p esp -j ACCEPT # Allow outgoing ESP traffic on ppp0 iptables -A OUTPUT -o ppp0 -p esp -j ACCEPT Let me know it works for you. Bonne chance! -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Ipsec routing / policy when leftside is part of rideside network
Please refer to Andreas' mail which you can find on https://lists.strongswan.org/pipermail/users/2007-June/001874.html This e-mail describes a very similar problem. You probably have to add something like the following to your ipsec.conf: conn pass leftsubnet=172.16.0.16/29 rightsubnet=172.16.0.16/29 left=%defaultroute right=a.b.c.d type=passthrough authby=never auto=route Let us know if this solves your problem. If the problem persists then please post your ipsec.conf and also the output of the following command: ip xfrm policy Btw: The problem is not located in the routing table but in the so-called Security Policy Database which determines which IP packets IPsec should be applied to. The connection description above adds an exception for local traffic. -Daniel Andreas Ascheneller wrote: Hello! I will create a VPN based on Strongswan. The IP-Range of the VPN is 172.16.0.0/22. No I have separate this big IP-Range in smaller range with the netmask /29 like that; 172.16.0.0/29 Central VPN Gateway 172.16.0.8/29 || 172.16.0.16/29 and so on... Now when I start the ipsec connection, Strongwan routes the local network packages through the ipsec tunnel. I think the problem is that the leftsubnet is a part of the rightsubnet. Is there a way to do that with the routing table or so? I use a analog solution with openswan - that works. regards Andreas Ascheneller ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Newbie Question... IP ROUTES
Michael Camino wrote: When i run a tracert from 10.0.3.1 to 10.0.2.1 it appears the traffic is going out my router interface instead over the vpn interface. First of all there's no such thing as a VPN interface. There used to be one with KLIPS but with Linux 2.6 and the native IPsec stack packets travel over the regular (e.g. eth0) interface. Is the reqid in the firewall config consistent with the one configured in the security policy database (SPD)? Please send the output of the following commands which helps troubleshooting a lot: ip xfrm policy ip xfrm state ip route show table 0 Also, use tcpdump -npi interface to do some debugging. Check if ESP packets are traveling across the link -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Multiple L2TP clients behind NAT using the same IP - status?
Andreas Steffen wrote: As a workaround I recommend to use IPsec tunnel mode with NAT-T. Windows XP's LT2P client can be configured to use tunnel mode instead of the default transport mode. But what's the virtual IP address of the windows box inside the tunnel then? The same as its LAN interface like 192.168.1.2? Don't you run into problems then when road warriors A and B are in two different hotels that both use the 192.168.1.0/24 subnet for internal addresses and the RWs also happen to have the same IP address inside the 192.168.1.0/24 subnets? But I think that the workaround is acceptable for the OP because he seems to be in control of the internal IP addresses. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] How to get the moonCert.pem
qhtf126 wrote: I want to konw how to get the mooncert.pem and Try openssl req -x509 -days 1460 -newkey rsa:1024 -keyout moonKey.pem -out mooncert.pem -subj /CN=moon/ -nodes Check out http://www.strongswan.org/docs/readme42.htm#section_3 Also familiarize yourself with the basics of Public key infrastructures. The return on investment might be good. what does the following mean : /etc/ipsec.secrets: : RSA moonKey.pem optional passphrase It means: Load the RSA private key stored in the file moonKey.pem so that every time you come in a situation in where you have to authenticate yourself with that key you have it available. Also, use optional passphrase to decrypt the key in case it is encrypted. -Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] no CREATE_CHILD_SA in Strongswan
Hi Tilak, I suspect that Andreas meant the log files output by strongswan. The file you sent seems to be created by some tool called IxANVL - Automated Network Validation Library (ANVL) which was built to verify the correct implementation of network protocols. So you are setting IxANVL at strongswan which is the Device under Test or DUT in order to verify its correct implementation. I'm unsure whether anybody has done this before. I guess that this testing product is freaking expensive, isn't it? But to troubleshoot IKEv2 connections strongSwan's own log files are usually sufficient. -Daniel Tilak Adhya wrote: Hi Andreas, !.5.txt is the log file we are sending to the Strongswan. Stongswan has the ip 10.1.1.42. And the corresponding configuration file is also attached with this mail. Waiting for valuable comments. Thanks in advance... Tilak On Mon, 18 May 2009 11:50:29 +0530 wrote H Tilak, without any log and configuration information we cannot possibly help you. Regards Andreas Tilak Adhya wrote: Hi, I am new to this list and using Strongswan for the last 2 months... I am facing a problem regarding the CREATE_CHILD_SA for IKEV2 with Strongswan. I have connected two Strongswan back to back but not able to send CREATE_CHILD_SAs. Also, I sent CREATE_CHILD_SA but Strongswan is not responding properly. It replies with No Proposal CHosen; but proposals configured in the Strongswan should match. Not getting the reason. If you need the log files I can post it. Your help is highly appreciated. Thanks Tilak *-- tilak = = 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]== *-- tilak ___ 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] Multiple tunnels between same peer
Arun Raj wrote: I am trying to bring multiple tunnels using PSK between same peers Is this option available in strongswan leftsubnet=192.168.10.0/24 rightsubnet=172.16.10.0/24 I guess you can specify multiple subnets with leftsubnet= and rightsubnet= Here's a quote from the manual page: leftsubnet ...Further, IKEv2 supports multiple subnets separated by commas. IKEv1 only interprets the first subnet of such a definition. I copied this info from the manual page over to the wiki page on http://wiki.strongswan.org/wiki/ConnSection Does this answer your question? Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] need some help : ipsec + xl2tpd
Reza ISSANY wrote: Both of these configurations stopped with a L2TP error on the XP client. Frankly speaking I don't know why the XP client doesn't like the Quick Mode response. Did you enable nat-transport with ./configure --enable-nat-transport when building strongswan. I heard that this is often the problem. Also, what's the error message on the windows side? I never tried L2TP by myself but I think this oakley log file might help. See http://technet.microsoft.com/en-us/library/bb490756.aspx for how to enable it. Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] network befind vdsl router
Hi Bernd, according to your network diagram you're (probably) using a 192.168.1.0/24 subnet to connect the router with the linux server. The address of the router is 192.168.1.0 (although I'm not sure if this is a valid IP address in this subnet) whereas the IP address of the linux server is 192.168.1.10. DHCP is disabled. You might get in trouble with this configuration because the subnet behind your remote IPsec peer is using the exact same subnet. Try changing the config of the NTT router and that of eth0 of the linux server. Use a completely different subnet like 10.x.y.0/24 where x and y are random numbers between 0 and 255. Assign 10.x.y.1 to the router and 10.x.y.10 to the linux server. Try using this config: conn xyz compress=yes authby=secret pfs=yes keyingtries=3 rekey=no left=%defaultroute leftsubnet=192.168.0.240/30 right=219.x.x.x rightsubnet=192.168.1.0/24 auto=start You know what just came into my mind and what might be the problem: You said that you switched from a linux machine that has a public ip address to a machine that sits behind a NAT router, didn't you? There's this thing called ID type you need to learn about. strongSwan knows four different ID types: DER_ASN1_DN, FQDN, USER_FQDN (like an e-mail address), IPV4_ADDR (an IP address). Before you switched to the new router you probably used IPV4_ADDR. But now your vpn gateway sits behind the NAT router. strongSwan will use the private IP address 10.x.y.10 as its ID in that case unless you tell it otherwise. I can imagine that your remote peer does not recognize your machine anymore b/c you're not using the public IP address (219.1.1.10) anymore but the private one. You might try setting leftid=219.1.1.10 or switching to FQDN or USER_FQDN like left...@host1.example.com But then you have to adapt the config of the remote end. Btw, did you enable nat_traversal on the remote end as well? If you've got further questions please send us the output of ipsec statusall and also relevant information from the syslog files. Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] No private key found for (Yeah, yeah again...)
Никоноров Григорий wrote: Thank for advice. As i see Exponents for swan1,swan2 are identical but different values of the modules! Wtf ? Perhaps I did not properly create certificates I guess that the public exponent is always 0x10001 because that makes the verification of signatures more computational effective. I also don't see the Modulus matching up. The public key in the certificate does not match the corresponding private key. Please share the sequence of commands you used to create the X.509 certificates. Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan and Watchguard Edge
Tica wrote: Just replace: 1.1.1.1 = External IP - left 2.2.2.2 = External IP - right 192.168.0.0/24 = Internal IP - left 10.1.1.0/24 = Internal IP - right left=1.1.1.1 leftid=1.1.1.1 leftsubnet=192.168.0.0/24 leftfirewall=yes lefthostaccess=yes I can't ping from one network to another... Please help!! Hi Tica, please try two things: Ping from one machine inside the 192.168.0.0/24 subnet to one machine inside the 10.1.1.0/24 subnet. Try leftsourceip=192.168.0.something If you ping from the VPN gateway 1.1.1.1 to 10.1.1.0/24 it won't work because the gateway uses 1.1.1.1 as the source IP address for its pings. And those packets won't travel through the tunnel. The tunnel uses 192.168.0.0/24 = 10.1.1.0/24 as the traffic selector. If you ping from 1.1.1.1 to 10.1.1.0/24. Then that's not going to work because it doesn't match the traffic selector. Using leftsourceip causes your gateway to use 192.168.0.xxx as source IP address. Can you run tcpdump on the 1.1.1.1 interface. Do you see ESP packets traveling across that link? Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Watchguard Edge - StrongSwan
Tica wrote: I changed the watchguard edge configuration. but I'm getting this message: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal Can you provide us with the logfiles of the Watchguard Edge? They might contain valuable information about why it rejected the proposal. Diffie-Helman Group: 2 This is equivalent to modp1024, isn't it? conn vpntest keyexchange=ikev1 ike=aes256-sha-modp1536 pfs=yes pfsgroup=modp1536 esp=aes256-sha1-modp1536 compress=no authby=secret left=200.111.111.111 leftsubnet=10.10.10.0/24 leftfirewall=yes lefthostaccess=yes right=200.222.222.222 rightsubnet=192.168.10.0/24 auto=start Try pfsgroup=modp1024 esp=aes256-sha1 The traffic selector which is 10.10.10.0/24 = 192.168.10.0/24 is IMHO also part of the proposal. Does this match with the configuration on the peer? Also, is the peer configured to use ESP in tunnel mode? Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Watchguard Edge - StrongSwan
Tica wrote: Mar 17 11:26:44 iked get_ipsec_pref: Unable to find channel info for remote(200.111.111.111) Hi Tica, this seems to be the most important message to me: Unable to find channel info for remote(200.111.111.111) I did a web search and found an entry in some forum. Somebody was getting the same error message. The response was: Did you set up a gateway then a channel (or tunnel) for the gateway and finally, as asked above, a routing policy for the channel on the firebox? The way in which you configure an IPsec gateway differs from product to product. I guess for Watchguard you have to set up a gateway and one or more tunnels for each gateway. I checked the web for a user manual for Watchguard but I didn't find a decent one. Can you send a link for the user manual? Or maybe you can post a screenshot of the configuration GUI. I guess you're missing some parameters on the Watchguard. Did you explicitly specify 10.10.10.0/24 = 192.168.10.0/24 somewhere in the Watchguard config? Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] host-host ikev2
abhishek kumar wrote: i can't understand failed to create a builder for credential type CRED_CERTIFICATE, subtype (1) in the syslog. To me it seems like your PKI has problems. Why are you using C=IN, O=rvce, CN=ajay as a CA? It should be a user certificate, right? Maybe strongSwan has trouble reading your certificates. Please do a openssl x509 -in /etc/ipsec.d/certs/abhishekCert.pem -noout -text and openssl x509 -in /etc/ipsec.d/certs/ajayCert.pem -noout -text just to make sure the certificates are readable. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] CA
Gbenga wrote: Here is a good site on how to work OpenSSL: http://www.madboa.com/geek/openssl/ Well, this site seems to have lots of information about OpenSSL although it does not describe how to set up a CA. I did a web search and found the following site http://sandbox.rulemaker.net/ngps/m2/howto.ca.html I did not check it in detail and there might be better sites. But I think if you mix the information you get from this site with the information from the strongSwan configuration guide then you should be able to set up a CA for using it with strongSwan. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] docu
j.witvl...@mindef.nl wrote: When trying to picture out the differences between tunnels, might this be a nice scheme (probably highly-simplified) Your document looks like an interesting way to visualize the protocol stack. I've got some comments: There's no BIND protocol. You're talking about DNS. BIND is a product name. Not every paket that results from web browsing does contain an HTTP header. Also, the HTTP header could be split up into two or more seperate packets. What's an SSL-Tunnel? You're depicting a TLS-Header inside a UDP datagram which I've never seen before because TLS runs on top of TCP. I know DTLS (Datagram TLS) but this is rarely used. Btw, this discussion is a bit off topic. Not sure if the strongSwan people want to see that on this list. Also, please refrain from attaching Disclaimers to your e-mails as they make little sense when sent to a public mailing list. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] First suc6
j.witvl...@mindef.nl wrote: Mar 13 12:48:35 wt8510w pluto[7844]: client1: cannot initiate connection with ID wildcards Did you solve this problem already? If not, then try to get rid of ID wildcards and specify the complete DN in leftid or rightid. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Still no suitable connection, was: Start getting stronger...
I guess your missing a comma in /etc/ipsec.conf on wt8510w: rightid=C=nl, ST=zh, L=mld, O=ivent, OU=ric, CN=vpngateway E=* # id of gateway Insert , between CN=vpngateway and E=*. The correct line would be rightid=C=nl, ST=zh, L=mld, O=ivent, OU=ric, CN=vpngateway, E=* # id of gateway The problem is that the pattern 'C=nl, ST=zh, L=mld, O=ivent, OU=ric, CN=vpngateway E=*' does NOT match 'C=nl, ST=zh, L=mld, O=ivent, OU=ric, CN=vpngateway, E=:vpngate...@kc3057.kc.mindef.nl' I'm not an export when it comes to those Distinguished Names. But I guess that CN=vpngateway E=* is interpretet as that the common Name literally has to be vpngateway E=*. Or it might be interpretet as a multivalue RDN. I don't know for sure. You can also infer that from the following syslog output: Mar 11 10:03:27 wt8510w pluto[6505]: client1 #1: we require peer to have ID 'C=nl, ST=zh, L=mld, O=ivent, OU=ric, CN=vpngateway E=*', but peer declares 'C=nl, ST=zh, L=mld, O=ivent, OU=ric, CN=vpngateway, E=:vpngate...@kc3057.kc.mindef.nl' Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Error exporting PKCS12 file...
Richard Whittaker wrote: have Nortel Contivity Client installed, I was able to figure out this is Mar 10 16:13:18 enterprise pluto[5202]: packet from 207.189.243.42:500: af+type of ISAKMP Oakley attribute has an unknown value: 65535 Mar 10 16:13:18 enterprise pluto[5202]: packet from 207.189.243.42:500: sending notification BAD_PROPOSAL_SYNTAX to 207.189.243.42:500 Richard, this seems to be a protocol incompatibility between strongSwan and the Nortel VPN Client. I'm afraid that only the strongSwan developers can help with this problem or somebody else who is familiar with IKE and the strongSwan source code. I checked the website of this client and it says: Provides full user-side functionality for secure access to enterprise networks over IP networks that use Nortel IP access routers and VPN servers. also Supports both IPSec and SSL VPN protocols allowing users to connect to Nortel VPN Router and VPN Gateway systems with a single client version One could infer that this client is meant to interoperate with Nortel systems only. I can imagine that Nortel deliberately broke interoperability with other IPsec products because they want you to buy their VPN gateway. But that's only a guess. You could try randomly tweaking the configuration options of the Nortel client and see if that makes a difference. Btw, is the Nortel client freely available or do you have to purchase a license. Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ipsec up host-host
Please post the syslog entries and ipsec.conf from host sun. abhishek kumar wrote: hello.. thank for your valuable suggestion. i rectify my problem but still i am not able to establish Security Association following are the results of ipsec listall at both end. result of ipsec listall at moon: List of X.509 End Entity Certificates: altNames: 192.168.3.3 subject: C=AU, ST=QLD, O=Mincom Pty. Ltd., OU=rvce, CN=ishan, E= ishansharm...@gmail.com issuer: C=AU, ST=QLD, L=Newbury, O=Mincom Pty. Ltd., OU=rvce, CN=ishan, e=ishansharm...@gmail.com serial:10:00:06 validity: not before Mar 10 22:04:25 2009, ok not after Mar 10 22:04:25 2011, ok pubkey:RSA 1024 bits, has private key keyid: 7e:35:20:c0:96:1e:c7:53:77:c2:44:3a:98:0a:84:96:7b:ad:9b:ee subjkey: c4:84:38:1c:2b:22:c4:39:6a:c7:6e:5d:9a:5e:06:3c:98:a3:25:37 authkey: f5:78:61:94:0a:5c:a5:e6:4e:43:d0:3b:f6:51:8f:48:7e:5b:63:48 List of X.509 CA Certificates: subject: C=AU, ST=QLD, L=Newbury, O=Mincom Pty. Ltd., OU=rvce, CN=ishan, e=ishansharm...@gmail.com issuer: C=AU, ST=QLD, L=Newbury, O=Mincom Pty. Ltd., OU=rvce, CN=ishan, e=ishansharm...@gmail.com serial:00:d5:8c:82:99:da:6c:4e:99 validity: not before Mar 10 20:39:13 2009, ok not after Mar 09 20:39:13 2013, ok pubkey:RSA 2048 bits keyid: 6d:19:04:8c:44:f3:07:70:73:2d:04:d1:e9:b4:fa:93:0e:d0:8d:a6 subjkey: f5:78:61:94:0a:5c:a5:e6:4e:43:d0:3b:f6:51:8f:48:7e:5b:63:48 authkey: f5:78:61:94:0a:5c:a5:e6:4e:43:d0:3b:f6:51:8f:48:7e:5b:63:48 List of registered IKEv2 Algorithms: encryption: AES_CBC 3DES DES integrity: AES_XCBC_96 HMAC_SHA1_96 AUTH_HMAC_SHA1_128 AUTH_HMAC_SHA2_256_128 HMAC_MD5_96 AUTH_HMAC_SHA2_384_192 AUTH_HMAC_SHA2_512_256 hasher: HASH_SHA1 HASH_SHA256 HASH_SHA384 HASH_SHA512 HASH_MD5 prf:PRF_KEYED_SHA1 PRF_FIPS_SHA1_160 PRF_AES128_CBC PRF_HMAC_SHA2_256 PRF_HMAC_SHA1 PRF_HMAC_MD5 PRF_HMAC_SHA2_384 PRF_HMAC_SHA2_512 dh-group: MODP_2048_BIT MODP_1536_BIT MODP_3072_BIT MODP_4096_BIT MODP_6144_BIT MODP_8192_BIT MODP_1024_BIT MODP_768_BIT result of ipsec listall at sun : List of X.509 End Entity Certificates: altNames: 192.168.3.3 subject: C=AU, ST=QLD, O=Mincom Pty. Ltd., OU=rvce, CN=ishan, E= ishansharm...@gmail.com issuer: C=AU, ST=QLD, L=Newbury, O=Mincom Pty. Ltd., OU=rvce, CN=ishan, e=ishansharm...@gmail.com serial:10:00:06 validity: not before Mar 10 22:04:25 2009, ok not after Mar 10 22:04:25 2011, ok pubkey:RSA 1024 bits keyid: 7e:35:20:c0:96:1e:c7:53:77:c2:44:3a:98:0a:84:96:7b:ad:9b:ee subjkey: c4:84:38:1c:2b:22:c4:39:6a:c7:6e:5d:9a:5e:06:3c:98:a3:25:37 authkey: f5:78:61:94:0a:5c:a5:e6:4e:43:d0:3b:f6:51:8f:48:7e:5b:63:48 altNames: 192.168.3.4 subject: C=AU, ST=QLD, O=Mincom Pty. Ltd., OU=rvce, CN=abhishek, E= abhis...@gmail.com issuer: C=AU, ST=QLD, L=Newbury, O=Mincom Pty. Ltd., OU=rvce, CN=ishan, e=ishansharm...@gmail.com serial:10:00:07 validity: not before Mar 11 17:24:59 2009, ok not after Mar 11 17:24:59 2011, ok pubkey:RSA 1024 bits, has private key keyid: a1:ae:79:92:34:f8:71:ec:19:fa:94:a6:9d:3b:72:f6:a5:70:8a:7a subjkey: ea:b7:c7:50:e6:8d:5e:8e:d7:40:20:87:22:49:8f:d9:3e:36:99:cb authkey: f5:78:61:94:0a:5c:a5:e6:4e:43:d0:3b:f6:51:8f:48:7e:5b:63:48 List of X.509 CA Certificates: subject: C=AU, ST=QLD, L=Newbury, O=Mincom Pty. Ltd., OU=rvce, CN=ishan, e=ishansharm...@gmail.com issuer: C=AU, ST=QLD, L=Newbury, O=Mincom Pty. Ltd., OU=rvce, CN=ishan, e=ishansharm...@gmail.com serial:00:d5:8c:82:99:da:6c:4e:99 validity: not before Mar 10 20:39:13 2009, ok not after Mar 09 20:39:13 2013, ok pubkey:RSA 2048 bits keyid: 6d:19:04:8c:44:f3:07:70:73:2d:04:d1:e9:b4:fa:93:0e:d0:8d:a6 subjkey: f5:78:61:94:0a:5c:a5:e6:4e:43:d0:3b:f6:51:8f:48:7e:5b:63:48 authkey: f5:78:61:94:0a:5c:a5:e6:4e:43:d0:3b:f6:51:8f:48:7e:5b:63:48 List of registered IKEv2 Algorithms: encryption: AES_CBC 3DES DES integrity: HMAC_SHA1_96 AUTH_HMAC_SHA1_128 AUTH_HMAC_SHA2_256_128 HMAC_MD5_96 AUTH_HMAC_SHA2_384_192 AUTH_HMAC_SHA2_512_256 AES_XCBC_96 hasher: HASH_SHA1 HASH_SHA256 HASH_SHA384 HASH_SHA512 HASH_MD5 prf:PRF_KEYED_SHA1 PRF_HMAC_SHA2_256 PRF_HMAC_SHA1 PRF_HMAC_MD5 PRF_HMAC_SHA2_384 PRF_HMAC_SHA2_512 PRF_AES128_CBC dh-group: MODP_2048_BIT MODP_1536_BIT MODP_3072_BIT MODP_4096_BIT MODP_6144_BIT MODP_8192_BIT MODP_1024_BIT MODP_768_BIT result of ipsec up host-host at moon: [r...@ishan certs]# ipsec up host-host initiating IKE_SA host-host[1] to 192.168.3.4 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] sending packet: from 192.168.3.3[500] to 192.168.3.4[500] received packet: from 192.168.3.4[500] to 192.168.3.3[500] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP)
Re: [strongSwan] Progress... Lurching progress...
Richard Whittaker wrote: Mar 11 12:35:13 enterprise pluto[31388]: roadwarrior-l2tp-updatedwin[3] 207.189.243.42:1429 #6: NAT-Traversal: Transport mode disabled due to security concerns I know little about how to use L2TP/IPsec on Windows but I found the following piece of source code in src/pluto/spdb.c: #ifndef I_KNOW_TRANSPORT_MODE_HAS_SECURITY_CONCERN_BUT_I_WANT_IT loglog(RC_LOG_SERIOUS, NAT-Traversal: Transport mode disabled due to security concerns); return FALSE; #endif You could recompile strongSwan and add the switch -DI_KNOW_TRANSPORT_MODE_HAS_SECURITY_CONCERN_BUT_I_WANT_IT But I'm not sure if this is the right way to go. Maybe you should try to convince Windows to use tunnel mode instead of transport mode. Btw, why don't you install Linux in your VM and use it as a VPN gateway. You could route the traffic from your Windows host OS to the VM and forward it through an IPsec tunnel. If you succeed in making this whole thing work I suggest that you set up a web page to let the community know about what you did and all the pitfalls one might be facing. Regards, Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ipsec up host-host
abhishek kumar wrote: I did the same thing u told. but in that case it is showing same received AUTHENTICATION_FAILED notify error. Please post the logfiles and config files of the both peers like you did before. I need to know *why* the authentication failed. You'll find that information in syslog entries on the other peer. as shown in README (quick start- host-host) left should be i.e. left=%defaultroute. what does this mean. Is it default route (gateway)? if it is wrong plz tell me how to remove the error no default route - cannot cope with %defaultroute!!! at the time when i start ipsec i.e. ipsec start. actually i remove this error by setting up sun(abhishek) etho as 192.168.3.4/255.255.255.0 http://192.168.3.4/255.255.255.0 (default route: 192.168.3.4). and moon(ishan) eth0 as 192.168.3.3/255.255.255.0 http://192.168.3.3/255.255.255.0 (default route 192.168.3.3). is this a wrong setup? Do not set up a default route just for this purpose. %defaultroute means: Find out to which interface the default route points and use the IP address of that interface. I'm unsure if this explanation is 100% correct but I think you get an idea of what's %defaulroute for. I guess it's usually used for hosts thet get a different IP addresse every time they reconnect to their ISP. %defaultroute saves them from changing the config file everytime their IP address changes. Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Still no suitable connection, was: Start getting stronger...
I guess I know what the problem is: The client does not have the gateway's public key. Why? Because the client does not have the certificate of the gateway from which he can extract the public key. That is why the client sends a certificate request to the gateway. But the gateway ignores that certificate request because you set leftsendcert=never # self signed So the client ends up with no certificate of the gateway. :-( You now have two options: 1. You copy the certificate from the gateway to all of the clients. You find that certificate in /etc/ipsec.d/certs/gwCert.pem It has to be in the same location on all the clients. You also need to set rightcert=gwCert.pem on all clients. 2. You get rid of leftsendcert=never or set it to ifasked. This allows the gateway to send its certificate to the client during connection setup. But this option requires that the CA C=nl, ST=zh, L=mld, O=ivent, OU=ric, CN=kcbeheer, e=r...@kc3057.mindef.nl is loaded on the client. I think you configured that correctly, right? This is necessary for the client to verify the cert of the gateway. I recommend option 2 because you already installed the CA cert on all clients. Daniel j.witvl...@mindef.nl wrote: Getting there, though with small steps. The private key for the gateway was there, but under the wrong name. From one of the ssl-howto i used the convention to name: Req for client1 = client1Req.pem Cert for client1 = client1Cert.pem Key for client1 = client1Key.pem For this issue, a symlink was enough. Still not working though ;=( After starting up the gateway i get from charon: Mar 10 15:34:37 kc3057 charon: 09[LIB] loaded certificate file '/etc/ipsec.d/certs/gwCert.pem' Mar 10 15:34:37 kc3057 charon: 09[CFG] peerid 10.1.16.59 not confirmed by certificate, defaulting to subject DN While private key was loaded just before: Mar 10 15:34:36 kc3057 charon: 01[CFG] loaded private key file '/etc/ipsec.d/private/gwCert.pem' Furthermore, after the client is started up, i get from pluto: Mar 10 15:37:02 kc3057 pluto[4741]: client1a[1] 10.49.39.57 #1: ignoring informational payload, type INVALID_KEY_INFORMATION While on the client Mar 10 15:37:38 wt8510w pluto[8752]: client1 #1: Peer ID is ID_DER_ASN1_DN: 'C=nl, ST=zh, L=mld, O=ivent, OU=ric, CN=vpngateway, E=:vpngate...@kc3057.kc.mindef.nl' Mar 10 15:37:38 wt8510w pluto[8752]: client1 #1: no RSA public key known for 'C=nl, ST=zh, L=mld, O=ivent, OU=ric, CN=vpngateway, E=:vpngate...@kc3057.kc.mindef.nl' Mar 10 15:37:38 wt8510w pluto[8752]: client1 #1: sending encrypted notification INVALID_KEY_INFORMATION to 10.1.16.59:500 Eventhough the public-key file is present on the client in: /etc/ipsec.d/certs/gwCert.pem Tried to follow carol config from paragraph 2.6 Full config, syslog, ipsec-lists and ipsec-status for gw and client in attachement Hans -Original Message- From: users-boun...@lists.strongswan.org [mailto:users-boun...@lists.strongswan.org] On Behalf Of Daniel Mentz Sent: Tuesday, March 10, 2009 1:52 PM To: Witvliet, J, CDC/IVENT/OPS/IS/PLS/SMP/HRM/RP1 Cc: h...@a-domani.nl; users@lists.strongswan.org Subject: Re: [strongSwan] Still no suitable connection,was: Start getting stronger... Hi Hans, did you specify the location of the corresponding private key for gwCert.pem in /etc/ipsec.secrets? I can't find a message similar to the following one in your logfiles: loaded private key file '/etc/ipsec.d/private/privatekeyfile' (1675 bytes) Also, read Andreas Steffen's last e-mail with the subject Re: [strongSwan] ipsec up host-host I guess that this e-mail is related. Here's a quote Execute ipsec rereadsecrets and check for error messages in the log! Everything is ok if ipsec listcerts shows .., has private key in the listing of the end entity certificate. Please do what Andreas describes and get back with the results. Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users __ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. Bezoek onze vernieuwde website www.defensie.nl This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages
Re: [strongSwan] Error exporting PKCS12 file...
Richard Whittaker wrote: ad...@host:/var/sslca# openssl pkcs12 -export -in rw.pem -inkey rw.key -certfile demoCA/cacert.pem -out rw.p12 unable to load private key Is rw.key in PEM format? Take a look inside rw.key. It should be a text file and look something like -BEGIN RSA PRIVATE KEY- MIICXAIBAAKBgQC7wJi4OMVcvOBmv3I4VNH31IBxdsx7rF3aqOsTUBtI5ZS76WuN ... -END RSA PRIVATE KEY- Provide us with all the files involved. You can create a new private/public key pair just for this purpose. So you do not need to send us the original files. Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan and Juniper Interoperability
Adam French wrote: Does anyone have any success getting a LAN-to-LAN tunnel up and working with Juniper? The requirement has StrongSwan as the initiator and Juniper as the Responder. I can get it to work with PSK authetication and only when the initiator has a static IP. However, I have had no success with any configuration that has the Strongswan initiator with a dynamic IP address. I think it will only work with RSA certs authentication but I cant get the certs to work with Juniper. If you have had any success with cert authentication or dynamic IP address and Juniper, please let me know your test case information/configuration. The fact that dynamic IP addresses and PSK authentication can not be used at the same time is a known shortcoming of IKEv1 Main Mode (strongSwan only supports Main Mode b/c Aggresive Mode is insecure). Andreas Steffen told me once that they included some hack into strongSwan that supports PSKs in conjunction with dynamic IP addresses but I never tried that. I think you should go for RSA certs. Please provide us with your config files, certs and log files so that we can help you better. I personally do not know if strongSwan works with Juniper. But I guess it does because strongSwan proved to be very interoperable. Btw, are you using IKEv1 or IKEv2? Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Astaro does not send a certificate request
I discovered that the Astaro Security Gateway V7 which uses strongSwan behind the scene sets nocrsend=yes which implies that the Astaro Gateway never sends a certificate request even if it needs to obtain a certificate from the other end. This brakes interoperability and forces me to set leftsendcert (or rightsendcert depending on the situation) to yes or always if I use strongSwan on the other end. I'm not sure if there's a similar workaround for other IKE implementations. I suggest that we come up with a FAQ entry on the wiki that explains this situation. The error message that the user is going to experience is no RSA public key known for 'Distinguished Name' I can try to phrase this FAQ entry. Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Problem with ikev1 net2net-psk, both VPN servers are behind NAT
Walid Aweiwi wrote: but my problem is no route nor ping from RED server to BLUE. Hi Walid, could you please provide us with the output of the command ip route list It should contain something like 192.168.25.0/24 dev ppp0 scope link src 192.168.100.100 The outlook will look differently on your machine because you're probably using an ethernet link instead of PPP. The output of ipsec status looks very promising. What's the exact output of the ping command? Does it say no route to host or is it just not getting any reply (100% packet loss) ? Please run tcpdump on the external interfaces of RED and BLUE in order to see if those boxes transmit ESP packets or just unencrypted ICMP packets. For the sake of completeness you could also include the output of the two following commands: ip xfrm state ip xfrm policy Regards, Daniel ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
