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? Should I consider using better CPUs on the servers in order to gain better performance through a stronger algorithm?
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.
