Re: [strongSwan] Connecting to Amazon VPC by a Linux-based VPN gateway.
On Thursday 14 January 2016 10:56:11 pm Josh wrote: > This http://bleikertz.com/blog/amazon_vpc_with_linux.html guide uses > racoon. Does anyone know how to use strongswan for the same task? > > Josh. We have done this successfully with StrongSWAN. Unfortunately, I do not have my documentation handy but I recall that, even though we wanted to use transport mode (since we were doing GRE / IPSec), we needed to use tunnel mode. I do not recall if we had to use the internal address as the rightnetwork address. I have wall to wall meeting tomorrow but I'll see if I can dig out the setup - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Contracted StrongSWAN Support
Hello, all. I recently sent emails from both my corporate and opensourcedevel.com addresses to Andreas and to info inquiring about contracted support but received no response. I am guessing the emails were lost somewhere along the way. Does the StrongSWAN team still offer contracted support? How does one go about engaging them? Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Throughput on high BDP networks
On Tue, 2015-06-02 at 22:23 -0400, jsulli...@opensourcedevel.com wrote: On June 1, 2015 at 11:48 AM Martin Willi mar...@strongswan.org wrote: Even at these rates, the CPU did not appear to be very busy. We had one at 85% occupied but that was the one running nuttcp. On the outgoing path, the Linux kernel usually accounts ESP encryption under the process that sends traffic using a socket send() call. So these 85% probably include AES-GCM. On the receiving or forwarding path, you'll have to look at the software interrupt usage (si in top). We have seen these boxes pass almost 20 Gbps with single digit utilization so they have plenty of horsepower. That does not have to mean much. Its all about encryption, and that is rather expensive. If you have specialized hardware, this most likely means it is good at shuffling data over the network, but might be underpowered when it has to do encryption in software. We are also running haveged on them to prevent entropy starvation for the encryption. Only the key exchange needs entropy, raw AES-GCM does not. Regards Martin Hello, all. Still battling this problem. The system is a SuperMicro server and not a specialized device. It looks like the problem may be software interrupts but on the sending side so I am very curious about the recommendation to check the receiving side. In sending only 100 Mbps or so, I see a single CPU pegged at 100% for si. I wondered if it might be the number of ACK packets being returned from the other side. We have a large window size so we get a flood of ACK packets in reply send but that really doesn't seem to make sense. But it would explain why we see this more in TCP than UDP . . . . or so we thought. I then sent 200 Mbps of UDP traffic so virtually no reply traffic and the sender was still at 100% si. What might be generating such a huge number of software interrupts and how can we reduce them or spread them across multiple processors? snip We appear to be chasing a compound problem perhaps also involving problems with GRE. As we try to isolate components, one issue we see is TCP Window size. For some reason, even though the w/rmem_max and tcp have maximum values over 16M, we are not achieving a TCP Window size much larger than 4M when we add IPSec to the mix. Not only does this seem to be the case when we are using IPSec only but, if we add a GRE tunnel (to make it a little easier to do a packet trace), with GRE only, we see the TCP window size go to the full 16M (but we have a problem with packet drops). When we add IPSec (GRE/IPSec), the packet drops magically go away (perhaps due to the lower throughput) but the TCP Window size stays stuck at that 4M level. What would cause this and how do we get the full sized TCP Window inside an IPSec transport stream? Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Throughput on high BDP networks
On Wed, 2015-06-03 at 15:51 -0400, John A. Sullivan III wrote: On Tue, 2015-06-02 at 22:23 -0400, jsulli...@opensourcedevel.com wrote: On June 1, 2015 at 11:48 AM Martin Willi mar...@strongswan.org wrote: Even at these rates, the CPU did not appear to be very busy. We had one at 85% occupied but that was the one running nuttcp. On the outgoing path, the Linux kernel usually accounts ESP encryption under the process that sends traffic using a socket send() call. So these 85% probably include AES-GCM. On the receiving or forwarding path, you'll have to look at the software interrupt usage (si in top). We have seen these boxes pass almost 20 Gbps with single digit utilization so they have plenty of horsepower. That does not have to mean much. Its all about encryption, and that is rather expensive. If you have specialized hardware, this most likely means it is good at shuffling data over the network, but might be underpowered when it has to do encryption in software. We are also running haveged on them to prevent entropy starvation for the encryption. Only the key exchange needs entropy, raw AES-GCM does not. Regards Martin Hello, all. Still battling this problem. The system is a SuperMicro server and not a specialized device. It looks like the problem may be software interrupts but on the sending side so I am very curious about the recommendation to check the receiving side. In sending only 100 Mbps or so, I see a single CPU pegged at 100% for si. I wondered if it might be the number of ACK packets being returned from the other side. We have a large window size so we get a flood of ACK packets in reply send but that really doesn't seem to make sense. But it would explain why we see this more in TCP than UDP . . . . or so we thought. I then sent 200 Mbps of UDP traffic so virtually no reply traffic and the sender was still at 100% si. What might be generating such a huge number of software interrupts and how can we reduce them or spread them across multiple processors? snip We appear to be chasing a compound problem perhaps also involving problems with GRE. As we try to isolate components, one issue we see is TCP Window size. For some reason, even though the w/rmem_max and tcp have maximum values over 16M, we are not achieving a TCP Window size much larger than 4M when we add IPSec to the mix. Not only does this seem to be the case when we are using IPSec only but, if we add a GRE tunnel (to make it a little easier to do a packet trace), with GRE only, we see the TCP window size go to the full 16M (but we have a problem with packet drops). When we add IPSec (GRE/IPSec), the packet drops magically go away (perhaps due to the lower throughput) but the TCP Window size stays stuck at that 4M level. What would cause this and how do we get the full sized TCP Window inside an IPSec transport stream? Thanks - John snip The second part of the compound problem appears to be caused by increasing the number of individual flows in the ESP transport stream. If I run a nuttcp at 400 Mbps on the above test link, I sustain that throughput with a single stream and there is virtually no packet loss. If I then run the same test with 9 flows, Performance drops to around 250 Mbps and the transmitted segment count is over 11,000 on our 120s test. CPU is near nil and the si is in single digits on any one processor. Any idea why performance would degrade with the same requested throughput spread across multiple flows and how we fix it? Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Selector problems with tunnel mode and VRRP addresses and GRE/IPSec
Hello, all. I'm working on a fairly complex setup where we are doing ingress traffic shaping with an IFB interface including traffic transported via GRE/IPSec on gateways using keepalived for VRRP. We would normally use IPSec in transport mode for GRE/IPSec but that seems to prevent the tc filters from seeing the contents of the IPSec packets after decrypted. In tunnel mode, the packet seems to take that second path through the interface and the tc filters work as expected . . . until it breaks. The StrongSWAN gateways use VRRP on their public interfaces. We only run StrongSWAN on the active gateway and the tunnel end points are the VIPs, i.e., the virtual IP addresses assigned by keepalived when the gateway is operating as MASTER. When a gateway fails, it tears down the GRE and IPSec tunnels if it can, and the new MASTER establishes them using the local VIP and terminating on the remote VIP. This worked fine in transport mode but, in tunnel mode, it complains, no local address found in traffic select VIP/32. I've tried playing with left/rightsourceip but this does not seem applicable to what we are doing and breaks. I've tried specifying leftsubnet even though it is the same as left but that does not work. How does one use tunnel mode to a VRRP VIP? Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ID cert validation required in PSK connections
Bump. Thanks - John On Sat, 2013-07-27 at 23:49 -0400, John A. Sullivan III wrote: Hello, all. I'm finding some difficulty transitioning from OpenSWAN to StrongSWAN. Most of my connections are internal and so use certs but I occasionally must establish an outside connection via PSK. With OSWAN, I typically create a default connection which specifies authby=rsasig leftrsasigkey=%cert leftcert=cert name leftid=DN and so forth. For the PSK, I simply specify in the specific config section: authby=secret leftid=IP Address and it seems to work. In SSWAN, I get complaints that the ID is not validated by the cert. I don't want to put the IP in the subjAltName as they may change. More importantly, if I have specified authby=secret why is it even looking at the cert? I've tried disabling this cert lookup by adding leftrsasigkey=%none and even leftcert= but none of that seems to work. How does one get SSWAN to ignore the default cert when using PSK? Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] How to dynamically add and delete tunnels?
On Tue, 2011-10-18 at 20:03 +0200, dr. ir. Kees van Reeuwijk wrote: Hi, I need to add and delete StrongSwan tunnels to a machine without user intervention. The solution I have come up with is to create a special directory, let's call it /strongswan, and then put a separate configuration file into /strongswan for each tunnel. To do this I added an entry include /strongswan/*.conf to /etc/ipsec.conf Adding a tunnel then consists of writing a new file to /strongswan, and saying ipsec update Removing a tunnel consists of removing its configuration file from /strongswan, and saying ipsec update update. Sadly, this does not work. A minor inconvenience is that strongSwan does not like it if the directory is empty, but that is easily solved with an empty dummy file. However, it seems that only the first `real' configuration file is read, and anything beyond that does not work. Also, I had expected that if I remove a configuration file, its tunnel goes away, but that doesn't seem to be the case. In fact, some of these tunnels do not go away, no matter what I do, and only a complete restart of the system helps. It is quite possible that I'm doing something wrong, but before I start debugging I would like to ask a few questions: Is this a reasonable way to accomplish my goal? Is there a better way? Is there perhaps a limitation on the length of a connection name (so that what I think are two different names is treated as the same)? Any help with this would be great. We, likewise, store our configurations in a separate directory and have a dummy.conf for when it is empty. However, to do start and stop, e.g., for restarting tunnels in response to monitoring alerts that the tunnel has dropped, we use the ipsec auto commands and pass the conn name to it, e.g., ipsec auto --delete conn ipsec auto --add conn ipsec auto --up conn I do not know if that would work for you - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] how to create a ACL-like system based on certificates?
On Thu, 2010-05-13 at 01:02 +0200, Andreas Schuldei wrote: In order to have fine grained control over the IPsec traffic in our distributed network of host-to-host ipsec connections we would like to create a ACLs-like system. For example all servers should be able to talk to infrastructure hosts (like DNS or backup servers). Only the other storage servers and the few specialized servers accessing the storage system should be able to initiate connections to storage servers. Only the server distributing the search index and the few servers quering the search system should be able to initiate connections to search servers. The monitoring servers should be able to initiate connections to all servers. How could i represent such a system with different types of server certificates (one type per server class) and strongswan configuration? I'll toss my two cents in as I see no one else has responded yet. We've never done this at the IPSec level. We have done something similar by combining either IPSec or OpenVPN and iptables via the ISCS project (http://iscs.sourceforge.net). I've not had the time to build a community around ISCS so it is not as well maintained as I would like but it does give exactly this kind of control and that control can be based upon X.509 fields and those credentials can be used throughout the entire WAN without resorting to virtual IP addresses for security (although sometimes they are handy for routing and troubleshooting issues). There are several important fixes in the CVS awaiting to be rolled into a new release - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
