Project

General

Profile

Actions

Bug #9349

open

IPSec service start/stop/restart fails after settings change

Added by Markus Stockhausen about 5 years ago. Updated over 3 years ago.

Status:
Confirmed
Priority:
Normal
Category:
IPsec
Target version:
Start date:
02/23/2019
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
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.

Files

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
Actions #1

Updated by Jim Pingle about 5 years 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.

Actions #2

Updated by Markus Stockhausen about 5 years 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.

Actions #3

Updated by Jim Pingle about 5 years 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.

Actions #4

Updated by Markus Stockhausen about 5 years 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.

Actions #5

Updated by Jim Pingle about 5 years ago

  • Target version changed from 48 to 2.5.0
Actions #6

Updated by Jim Pingle over 4 years ago

  • Category changed from Web Interface to IPsec
Actions #7

Updated by Viktor Gurov about 4 years ago

works fine on pfSense 2.5.0.a.20191220.0438

with Chromium 78.0.3904.108 and Firefox 68.2

Actions #8

Updated by Anonymous over 3 years ago

  • Status changed from New to Feedback
Actions #9

Updated by Anonymous over 3 years ago

  • Assignee set to Markus Stockhausen
Actions #10

Updated by Jim Pingle over 3 years ago

  • Status changed from Feedback to Confirmed
  • Target version changed from 2.5.0 to CE-Next
  • Affected Version changed from 2.4.4_2 to All

I can still reproduce this on 2.5.0.

  • Navigate to VPN > IPsec > Advanced
  • Make a change, click Save
  • Try to stop or start the IPsec service using the shortcut icon

The browser (Firefox in my case) shows a popup wanting to resubmit the form.

Actions

Also available in: Atom PDF