2000 IPsec tunnels??
-
Is it possible to have 2000 IPsec tunnels to computer endpoints using pfsense? Assuming the hardware can handle that many connections. Can the software support that many connections?
Thanks
Danny -
on pptp is afaik a limit of 16 connections but since you want to use ipsec i dont see a problem.
imo it's possible if your hardware can handle the load. -
Thanks I will try this out.
-
Some tweaks have been made recently to fix issues seen with 100+ tunnels. We don't yet know how far this will scale, one person is up to something like 150 and hasn't had issues after these fixes. 2000 may work, may not.
Make sure you use a snapshot from http://snapshots.pfsense.org/FreeBSD6/RELENG_1_2/
and let us know how it goes if you get 200+ active tunnels going.
-
I was wondering how this project was going. I have a large, very quickly growing customer currently using a Sonicwall 4060. They're looking at upgrading to a pair of E-class Sonicwalls right now. I'm thinking that pf on a pair of machines with dual quad cores and an hifn 8155 encryption accelerator each and the commercial support would be an excellent alternative if it will work well. This would have to be very stable or they would be quite upset.
-
At this time, I would not recommend running more than 100 IPsec tunnels with pfSense. Once you get up to 125-150, things get really ugly and unstable. We're trying to find a solution, but this is still an issue right now. It's a long standing FreeBSD issue that we can't seem to get much help on from the FreeBSD developers.
-
Is that with an encryption card? I've had much better results using the hifn cards than without.
-
Encryption cards work great for increasing throughput without hitting the CPU, but they don't do anything to change this FreeBSD bug related to large numbers of SPD and SAD entries.
-
How much is "a large numbers off SPD and SAD"?
Note that there also seems to be an issue with the hifn chipset (Soekris VPN 1411 MiniPC on a Wrap environment):
http://forum.pfsense.org/index.php/topic,3205.msg21703.html#msg21703
Against the background of these facts … with 2000 ipsec tunnels i would prefer something like the before discussed dual quad core and may be something like dual or quad intel gigabit server adapter.
-
I haven't had any problems at all with the vpn1411 or vpn1401 cards. I've done ipsec vpns with them on both wraps and soekris boards, and haven't had any problems going to other devices from them such as sonicwalls, or even some little pos netgears. I was thinking about something like the 8155, which is capable of around 2 gb/s 3des and aes performance. The 100 vpn limit wouldn't be a problem right now, but it definately would be within a year. Right now, their 4060 is actually overkill.
-
Rich: we should have this fixed within a year, so you shouldn't have anything to worry about. ;D
@EmL:
How much is "a large numbers off SPD and SAD"?
As I said above, I wouldn't recommend more than 100. Around 125-150 it will become very unstable or stop working completely.
-
I haven't had any problems at all with the vpn1411 or vpn1401 cards. I've done ipsec vpns with them on both wraps and soekris boards …
It works also between 2 pfsense (static-dynamic) after IP changes on the dynamic side or do you only have static endpoints?
-
@EmL:
I haven't had any problems at all with the vpn1411 or vpn1401 cards. I've done ipsec vpns with them on both wraps and soekris boards …
It works also between 2 pfsense (static-dynamic) after IP changes on the dynamic side or do you only have static endpoints?
Sorry, didn't notice the extra posts in this thread till now. All the VPNs I'm dealing with are static IPs.
-
We can currently sustain about 250 ipsec vpn tunnels and probably a lot more before falling apart entirely. There are however a few issues. Getting the spd policies loaded appears to be a problem when you have large numbers. In my case 400.
When you see messages in the logfiles about missing policy entries you have succesfully run into it.
-
From racoon2 recommandations:
1. Recommended system configuration
== ================================Both NetBSD and FreeBSD have the kernel state, "net.key.blockacq_count"
to setup the behavior how many packet the kernel will block until the
suitable SA will be installed. The state sometimes disturbs
retransmission of the key exchange message. We recommend you to set
it to zero.# sysctl -w net.key.blockacq_count=0
And FreeBSD also has the kernel state, "net.key.preferred_old" to use an
old SA preferred to a new SA. The state sometimes disturbs
interoperability. We recommend you to set it to zero.# sysctl -w net.key.preferred_oldsa=0
