Project

General

Profile

Bug #9349

IPSec service start/stop/restart fails after settings change

Added by Markus Stockhausen 5 months ago. Updated 4 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Web Interface
Target version:
Start date:
02/23/2019
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.4_2
Affected Architecture:

Description

There seems to be some weird behaviour when changing things on the advance IPsec servie settings tab. As soon as you change a setting once and save it you can no longer control the IPsec service. Issue can be reproduced as follows:

  • Open dialogue VPN > IPsec > Advanced settings
  • Stop running IPsec/strongSwan service (small stop button on top right)
  • Service is stopped > page reloads > only start service button is displayed
  • Start running IPsec/strongSwan service (small stop button on top right)
  • Service is started > page reloads > stop & restart service button is displayed

No do some change. E.g. toogle make-before-break flag. Try to repeat the above procedure

  • Stop running IPsec/strongSwan service (small stop button on top right)
  • ERROR -> nothing will happen.
2019-02-23_9-13-29.jpg (25.6 KB) 2019-02-23_9-13-29.jpg Jim Pingle, 02/23/2019 08:14 AM

History

#1 Updated by Jim Pingle 5 months ago

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.

#2 Updated by Markus Stockhausen 5 months ago

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.

#3 Updated by Jim Pingle 5 months ago

The mode on that says "stop", not restart.

Try a different browser, you may see a more informative error message.

When I try the exact steps you mention in Firefox, it does exactly as I suspected. The browser refuses to reload the page because it would involve resubmitting the form.

#4 Updated by Markus Stockhausen 5 months ago

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.

#5 Updated by Jim Pingle 4 months ago

  • Target version changed from 48 to 2.5.0

Also available in: Atom PDF