Project

General

Profile

Issue #3293

The VPN server stops routing traffic to new tunnels when the variable "reqid" reaches "16383"

Added by Geovane Gonçalves about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Category:
freebsd
Affected version:
5.7.1
Resolution:
Duplicate

Description

Hi,

Firstly, I would like to congratulate the initiative and competence of the project team because, with the exception of the reported problem, the service is very stable.

We have a IPSec/IKEV2 (FreeBSD strongSwan U5.7.1/K11.2-RELEASE-p10) Server running in PFSense 2.4.4-RELEASE-p3 (amd64) over FreeBSD 11.2-RELEASE-p10.

The VPN server serves an average of 40 concurrent mobile clients.
Each phase 1 tunnel created has three phase 2 tunnels.
When the "reqid" variable reaches the value "16384", the "trap not found" error logged in the logs below occurs and users can connect but cannot traffic over the VPN.
In my environment this value is reached approximately every 30 days.
To resolve the issue, I need to stop the VPN service and start it again for the variable to be reset.

Logs samples:

Aug 18 20:12:10 vpn2 charon: 02[KNL] creating acquire job for policy serverIP/32|/0 === clientIP/32|/0 with reqid {16384}
Aug 18 20:12:10 vpn2 charon: 13[CFG] trap not found, unable to acquire reqid 16384

Dec 11 11:34:34 vpn2 charon: 14[KNL] creating acquire job for policy serverIP/32|/0 === clientIP/32|/0 with reqid {16384}
Dec 11 11:34:34 vpn2 charon: 01[CFG] trap not found, unable to acquire reqid 16384

There is already a record of this problem, but apparently nothing has been done:

https://wiki.strongswan.org/issues/2315

Mr. Tobias answered:

"That because of IPSEC_MANUAL_REQID_MAX (0x3fff == 16383). Which is a strangely low limit (at least for keying daemons like strongSwan that manage reqids themselves) since reqids are 32-bit numbers.

reqids are currently allocated sequentially using a sttic counter (source:src/libcharon/kernel/kernel_interface.c#L328). The code that allocates them does not know anything about the limit above (it doesn't even know or care that it runs on a FreeBSD kernel)."

Based on this answer I reported the case to the FreeBSD kernel development team in this post:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242606

... and got the following suggestion:

FreeBSD already contains a suitable allocator in "sys/kern/subr_unit.c".

Thanks,

Geovane


Related issues

Is duplicate of Bug #2315: FreeBSD server stops routing new connections after 16k connects/disconnectsClosed

History

#1 Updated by Tobias Brunner about 1 year ago

  • Is duplicate of Bug #2315: FreeBSD server stops routing new connections after 16k connects/disconnects added

#2 Updated by Tobias Brunner about 1 year ago

  • Tracker changed from Bug to Issue
  • Category set to freebsd
  • Status changed from New to Closed
  • Assignee set to Tobias Brunner
  • Start date deleted (13.12.2019)
  • Resolution set to Duplicate

Based on this answer I reported the case to the FreeBSD kernel development team in this post:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242606

... and got the following suggestion:

FreeBSD already contains a suitable allocator in "sys/kern/subr_unit.c".

Which doesn't seem related to the issue. Probably someone replied to the wrong email thread.

Also available in: Atom PDF