While I am not required to comply with any particular crypto standards, I have NFS data passing through that link which I would classify as....fairly sensitive. That being said, I am not sure how to check the re-keying frequency except watching `ipsecctl -m`. I am not sure if PFS is enabled by default on a stock OpenBSD 5.1 installation so I would appreciate it if you could tell me how I can check that.
Performance wise I would be happy if I could squeeze ~100 out of the 150Mbit/s link. At the moment I am struggling to reach ~100Mbit/s and that is with hmac-md5. I would like to find a reasonable balance between performance and security but it seems that hmac-sha2-256 is too "expensive" for my hardware. I really thought dual Xeons @ 2.8GHz would be up to the task. On Mon, Oct 22, 2012 at 6:41 PM, Mike Belopuhov <[email protected]> wrote: > On Mon, Oct 22, 2012 at 4:10 PM, Michael Sideris <[email protected]> wrote: >> It seems that changing to hmac-md5 boosted network throughput from >> ~50Mbit/s to ~100Mbit/s which is decent and reasonable. I am going to >> experiment a bit further with `scrub` options in pf.conf to see if I >> can squeeze more performance out of the link. The question now >> is....how much is security affected by using hmac-md5 vs the default >> hmac-sha2-256? > > It's more a question of how often do you rekey? You also should not > disable Perfect Forward Secrecy that recomputes DH values every > time you renew your phase 2 key. And while there are no known > serious attacks on HMAC-MD5 it all depends on how important the > data that you're protecting is and if you have to be compliant with > any regulations that might mandate use of SHA2. > >> Should I consider using better CPUs on the servers in >> order to gain better performance through a stronger algorithm? >> > > You can get 600-750Mbps (depending on the CPU speed) in the > AES-NI enabled setup (using AES-GCM that is). > >> On Mon, Oct 22, 2012 at 2:58 PM, Mike Belopuhov <[email protected]> wrote: >>> On Tue, Oct 16, 2012 at 11:43 AM, Michael Sideris <[email protected]> wrote: >>>> Both endpoints run stock OpenBSD 5.1 (amd64). We use the VPN link to >>>> manage our platform remotely and perform daily backups. G-VPN runs on >>>> a 150Mbit/s link while L-VPN on a 1Gbit/s link. On one hand, our VPN >>>> setup runs really nicely. The connections are routed properly, pf is >>>> godsent and authpf works wonders. On the other hand, network >>>> throughput over the VPN tunnel never exceeds 3.4MB/s (ftp, scp, rsync, >>>> etc...) >>>> >>>> I welcome any suggestions. Keep in mind that this is our production >>>> VPN tunnel, so I cannot shut it down at will. Thanks in advance. >>>> >>>> --- >>>> Mike >>>> >>> >>> Hi, >>> >>> I suggest a couple of changes: >>> >>> 1) use cheaper hash function (md5 or at least sha1) >>> 2) use mss fixup so that your packets don't get fragmented >>> >>> The first point relates to your "ike" rules in ipsec.conf: >>> >>> ike esp from $local_net to $remote_net peer $remote_ip \ >>> quick auth hmac-md5 enc aes >>> >>> The second point relates to pf rules in pf.conf: >>> >>> match in scrub (max-mss 1440) >>> >>> You can experiment with the values in the 1400-1480 range. >>> >>> Also, please make sure that you don't run tcpbench or any >>> other benchmarking on the vpn gates themselves as it offsets >>> the measurements.
