I am using the NFS defaults which means, according to the man page at least, that it should go over TCP. Regardless, I think I have a fair idea of what is what happening now. Or at least better than I had before. I will try to tweak things around a bit until I find the right balance between performance and security. Also, OpenBSD 5.2 is around the corner and you never know what that might bring.
Big thanks to everyone who put the time into answering my questions. Cheers! On Tue, Oct 23, 2012 at 5:26 PM, Mike Belopuhov <[email protected]> wrote: > On Tue, Oct 23, 2012 at 10:18 AM, Michael Sideris <[email protected]> wrote: >> 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. > > hmm, if you're using udp mounts for NFS you might want to try tcp > instead. > >> That being said, I am not sure how to >> check the re-keying frequency except watching `ipsecctl -m`. > > that depends on the isakmpd settings. right now you're probably > using default ones which are negotiated with your peer. this is > what isakmpd.conf(5) has to say about it: > > The Quick Mode lifetime defaults to 20 minutes (minimum 60 > seconds, maximum 1 day). > > this is rather a broad range, so you might want to shorten it. > look for the "Default-phase-2-lifetime" parameter in the man > page for the /etc/isakmpd/isakmpd.conf. > >> 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. >> > > it is, unless you disable it with the "group none" in the "quick" > configuration options. > >> 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. > > unfortunately it is expensive for any hardware that's why aes-gcm > was developed. > >> I really thought dual Xeons @ 2.8GHz would be up to the task. >> > > the "dual" part doesn't help as much as it could though. > > in any case, i suggest you play with nfs tcp mounts and mss fixups. > otherwise you might be loosing performance where you shouldn't. > > trying the snapshot out might also give an opportunity to learn if > some of the performance changes that were committed are helpful > in your setup. > >> 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.
