Patch for 8.3 IPsec to better scale up to large SPD / SADB

[dhatz]

I seem to remember that pfSense had a patch for IPsec to allow large number of tunnels, but I can't seem to find it under pfsense-tools/patches

Anyway, I just happened to notice this patch which was submitted to FreeBSD recently, coming from one of the maintainers of ipsec-tools (racoon):

http://www.freebsd.org/cgi/query-pr.cgi?pr=181699

From: Timo Teräs timo.teras@iki.fiDate: Sat, 31 Aug 2013 09:05:42 GMT
Subject: IPsec does scale to large SPD / SADB
Send-pr version: www-3.1
Number: 181699
Category: kern
Synopsis: [ipsec] [patch] IPsec does scale to large SPD / SADB
Severity: non-critical
Priority: low
Responsible: freebsd-net
State: open
Class: change-request
Arrival-Date: Sat Aug 31 09:10:00 UTC 2013
Closed-Date:
Last-Modified: Sun Sep 01 04:35:30 UTC 2013
Originator: Timo Teräs
Release: 8.3-RELEASE-i386

Description
The algorithms for IPsec SA lookup and SPD lookups are O(n), and things slow down to unusable state if number of SPD or SADB entries goes >100.

Fix
Attached are patches to convert linear list lookups to hash lookups (SADB), and implementing a simple SPD caching layer to speed up SPD lookups.

Patch attached with submission follows:/timo.teras@iki.fi

[dhatz]

I thought this feature would generate some interest, since there are quite a few pfSense user who run or wish to run 100s of IPsec tunnels.

Perhaps I should have posted it in the IPsec sub-forum …

[jimp]

Too late for a change like that on 2.1. Ermal looked at it yesterday also.

IIRC we already have some changes for that. We have people with 300+ tunnels already, if that still applied to pfSense, we would have heard about it by now.

Though it may still be worth looking at for 2.2 if it is a further improvement.

[dhatz]

I also e-mailed Seth (who I afaik has many IPsec tunnels) who might be interested to test it out and compare results.

Assuming the patch gets merged into FreeBSD-HEAD, I guess pfSense 2.2 based on FreeBSD10 would pick it up anyway.

[gerdesj]

I think O(n) means a gradual degradation (linear) so a statement that >100 items in one or other DB "causing" problems is a bit misleading - it depends on your horsepower and traffic.

A quick look at one of my pfSense VMs shows 136 odd items in the SAD.  Can't say things are unusable by any stretch of the imagination.

However a better algo is always a good idea in any area of IT - the bloody things are cut n paste out of many textbooks!  Amazing something as old as IPSEC has only just received this treatment.

Cheers
Jon