IPsec Apply changes time out

richi44

@stephenw10 I tried it on different hw setups but our main pfsense router runs on virtual machine (4cores of cpu-xeon e-2236@3,4Ghz, 12gb ram).

Error1:
Mar 17 20:24:04 nginx 2021/03/17 20:24:04 [error] 65880#100222: *1386 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.211.3, server: , request: "POST /status_services.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.211.1:8443", referrer: "https://192.168.211.1:8443/status_services.php"

Error2:
Mar 17 20:32:29 kernel module_register_init: MOD_LOAD (vesa, 0xffffffff8140c3e0, 0) error 19
Mar 17 20:32:29 kernel module_register_init: MOD_LOAD (iwi_monitor_fw, 0xffffffff80765790, 0) error 1
Mar 17 20:32:29 kernel module_register_init: MOD_LOAD (iwi_ibss_fw, 0xffffffff807656e0, 0) error 1
Mar 17 20:32:29 kernel module_register_init: MOD_LOAD (iwi_bss_fw, 0xffffffff80765630, 0) error 1
Mar 17 20:32:29 kernel module_register_init: MOD_LOAD (ipw_monitor_fw, 0xffffffff8073dda0, 0) error 1
Mar 17 20:32:29 kernel module_register_init: MOD_LOAD (ipw_ibss_fw, 0xffffffff8073dcf0, 0) error 1
Mar 17 20:32:29 kernel module_register_init: MOD_LOAD (ipw_bss_fw, 0xffffffff8073dc40, 0) error 1

stephenw10

Those kernel module errors are unrelated and not a cause for concern.

Unclear why that timeout happens yet.

richi44

@stephenw10
Kernel erros could relate to virtualisation on Proxmox.

I tried to setup new router and time out problem does not occur if there were only few tunnels. After clean installation I was able to continually setup up to 50 P1 with 50 P2 but after reboot and apply changes the time out problem occurred.

Could it be related to nginx memory isssue?

stephenw10

It seems more likely it's failing to pull the data from vici/strongswan for some reason. nginx shows it is timing out waiting for that data as far as I can see.

Is there a specific number of tunnels that seems to trigger the issue?

Or is it perhaps hitting a connection number that is failing to parse?

The way connections are numbered was changed significantly in 2.5 to allow for VTI tunnels when a large number exists. https://redmine.pfsense.org/issues/9592

Steve

vergilis

@stephenw10 I currently have 46 tunnels on the failing system.

stephenw10

Try running ipsec statusall if you can. If that fails it would be interesting. If it doesn't look for a connection number that might be hitting a limit, con100000 maybe.

Does it fail with 45 tunnels?

Steve

vergilis

@stephenw10 Yes. It fails to Apply with 45 tunnels all the time. ipsec statusall returns results.

jimp

Can you try a 2.5.1 RC snapshot and see if it's better there?

stephenw10

Sorry, I mean is there a specific number where it doesn't fail? Is it something that clear cut?

Steve

vergilis

@jimp The following release is still exhibiting the issue:

21.05-DEVELOPMENT (amd64)
built on Sat Mar 20 01:04:33 EDT 2021
FreeBSD 12.2-STABLE

richi44

@stephenw10

The firs time it showed was when I added 33th tunnel.

richi44

@richi44 I setup 51 tunnels on Netgate XG-7100 but the problem remains. After Apply changes, which takes more than 4 min Time Out 504 error shows.

Could you help me to solve this problem? This is really bad if I want to make quick changes to my tunnels.

Thank you.