pfSense

This is most likely because your browser is refusing to refresh the page to update the controls because it would involve resubmitting the form on that page since after saving the page loaded by POST.

There is likely a way around it, but as a simple workaround you can click over to any other tab and then go back and it should work.

Hi Jim,

I do not think so. I captured the network traffic in the browser and can see the following request being sent to the web interface (before and after doing changes):

Request URL: http://192.168.11.100/status_services.php
Request Method: POST
Status Code: 200 OK
Remote Address: 192.168.11.100:80
Referrer Policy: no-referrer-when-downgrade
Cache-Control: no-store, no-cache, must-revalidate
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Sat, 23 Feb 2019 13:55:04 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Last-Modified: Sat, 23 Feb 2019 13:54:58 GMT
Pragma: no-cache
Server: nginx
Set-Cookie: PHPSESSID=2471cc76e067e7304a634efd90f65751; path=/; HttpOnly
Transfer-Encoding: chunked
X-Frame-Options: SAMEORIGIN
X-Frame-Options: SAMEORIGIN
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en,de-DE;q=0.9,de;q=0.8,en-US;q=0.7
Connection: keep-alive
Content-Length: 109
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: PHPSESSID=2471cc76e067e7304a634efd90f65751
Host: 192.168.11.100
Origin: http://192.168.11.100
Referer: http://192.168.11.100/vpn_ipsec_settings.php
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
X-Requested-With: XMLHttpRequest
__csrf_magic: sid:f25a61369bccc9c680fe0cd443de2f00c65e6d0f,1550929957
ajax: ajax
mode: stopservice
service: ipsec

The URL and the mode/service fields indicate that the firewall should issue a service restart.

Hi.

I mixed the logs (stop/restart) but the problem is the same and I understand your explanation. Nevertheless the start/stop/restart logic from strongSwan is quite inconsistent and this is just one case of the erratic behaviour. To simplify the bug we need to get to the real point.

• The web interface calls vpn_ipsec_configure() when doing changes on the advanced tab
• If the changed options require a service restart it will pass restart=true to this function
• In case the service is NOT running the function will unconditionally start the service.

As a side effect we se my initial bug description. If my Chrome browser allows me to do a post on the start/stop buttons after I changed some settings the following events are fired.

• ipsec Service is stopped via status_services.php mode:stopservice & service:ipsec
• reconfiguration logic afterwards just starts the service again

I guess a correct solution would be to enhance function vpn_ipsec_configure with a start flag.

function vpn_ipsec_configure($restart = false, $start = true)

Set start false and the service will not start unconditionally. If you are okay with that, I will post a fix.

works fine on pfSense 2.5.0.a.20191220.0438

with Chromium 78.0.3904.108 and Firefox 68.2