Project

General

Profile

Actions
Copy link

Bug #3132

open

Gateway events for IPv6 affect IPv4 services and vice versa

Added by Jim Pingle over 11 years ago. Updated about 1 month ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Gateway Monitoring
Target version:
CE-Next
Start date:
Due date:
% Done:

10%

Estimated time:
Plus Target Version:
25.01
Release Notes:
Default
Affected Version:
All
Affected Architecture:

Description

When a gateway of a specific type has an event, all services on the interface are restarted, rather than just those relevant to the type of gateway that had an event.

For example, if you have dual stack IPv4 and IPv6, and separate OpenVPN servers on IPv4 and IPv6, then the IPv6 gateway going down will restart both, not just the IPv6 instance. This is unnecessarily disruptive to the services that did not have an outage.

Ideally, a service should only be restarted if it is dual stack or if it's using the same IP type as the gateway that had an outage.

Related issues

Related to Bug #13061: Gateway events for IPv6 affect IPv4 OpenVPN instances and vice versaResolvedViktor Gurov

Actions
Actions
Copy link
 #1

Updated by Jim Thompson over 10 years ago

  • Assignee set to Ermal Luçi
Actions
Copy link
 #2

Updated by Ermal Luçi about 10 years ago

This will not be possible to be fixed in 2.2
Many things need to change for this to happen.

Actions
Copy link
 #3

Updated by Renato Botelho about 10 years ago

  • Target version changed from 2.2 to 2.3
Actions
Copy link
 #4

Updated by Jim Thompson about 9 years ago

  • Target version changed from 2.3 to Future
Actions
Copy link
 #5

Updated by Jim Thompson over 8 years ago

  • Assignee changed from Ermal Luçi to Anonymous

Ermal -> Steve Beaver

Actions
Copy link
 #6

Updated by Jim Thompson over 8 years ago

  • Target version changed from Future to 2.4.0
Actions
Copy link
 #7

Updated by Jim Pingle over 7 years ago

  • Target version changed from 2.4.0 to 2.4.1
Actions
Copy link
 #8

Updated by Jim Pingle about 7 years ago

  • Target version changed from 2.4.1 to 2.4.2
Actions
Copy link
 #9

Updated by Jim Pingle about 7 years ago

  • Target version changed from 2.4.2 to 2.4.3
Actions
Copy link
 #10

Updated by Jim Pingle almost 7 years ago

  • Target version changed from 2.4.3 to 2.4.4
Actions
Copy link
 #11

Updated by Anonymous over 6 years ago

  • Target version changed from 2.4.4 to Future
Actions
Copy link
 #12

Updated by Jim Pingle over 5 years ago

  • Category changed from Gateways to Gateway Monitoring
Actions
Copy link
 #13

Updated by Viktor Gurov over 3 years ago

Actions
Copy link
 #14

Updated by Viktor Gurov over 2 years ago

  • Assignee set to Viktor Gurov

IPsec service fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/718

it's better to have a separate commits for each service.

Actions
Copy link
 #15

Updated by Viktor Gurov over 2 years ago

  • Status changed from New to Feedback
  • Target version changed from Future to 2.7.0
  • % Done changed from 0 to 10
  • Plus Target Version set to 22.05
  • Affected Version changed from 2.1 to All
Actions
Copy link
 #16

Updated by Jim Pingle over 2 years ago

  • Status changed from Feedback to In Progress

I wouldn't mark the whole issue Feedback as it's only partially implemented. Would be better to make a separate Redmine for each service instead, with fixes going on each one as it happens referring back here.

Actions
Copy link
 #17

Updated by Viktor Gurov over 2 years ago

OpenVPN redmine issue: #13061

Actions
Copy link
 #18

Updated by Viktor Gurov over 2 years ago

  • Related to Bug #13061: Gateway events for IPv6 affect IPv4 OpenVPN instances and vice versa added
Actions
Copy link
 #19

Updated by Jim Pingle over 2 years ago

  • Plus Target Version changed from 22.05 to 22.09
Actions
Copy link
 #20

Updated by Jim Pingle over 2 years ago

  • Plus Target Version changed from 22.09 to 22.11
Actions
Copy link
 #21

Updated by Phil Lee about 2 years ago

Possible also related to this issue I found https://redmine.pfsense.org/issues/13552 where IPv4 signpost files in the /tmp folder get deleted regardless if the network causing that call is IPv6. In addition IPv6 signpost files never get deleted on a linkdown for IPv6.

Actions
Copy link
 #22

Updated by Jim Pingle about 2 years ago

  • Plus Target Version changed from 22.11 to 23.01
Actions
Copy link
 #23

Updated by Jim Pingle about 2 years ago

  • Assignee deleted (Viktor Gurov)
Actions
Copy link
 #24

Updated by Jim Pingle about 2 years ago

  • Start date deleted (08/06/2013)
  • Plus Target Version changed from 23.01 to 23.05

Moving ahead again, too many other more important things and this requires working on each affected service separately.

Actions
Copy link
 #25

Updated by Jim Pingle over 1 year ago

  • Plus Target Version changed from 23.05 to 23.09

Doesn't look likely that we'll have time to finish this for 23.05. Moving forward to the next release target.

Actions
Copy link
 #26

Updated by Jim Pingle over 1 year ago

  • Target version changed from 2.7.0 to CE-Next
Actions
Copy link
 #27

Updated by Jim Pingle about 1 year ago

  • Plus Target Version changed from 23.09 to 24.01
Actions
Copy link
 #28

Updated by Jim Pingle about 1 year ago

  • Plus Target Version changed from 24.01 to 24.03
Actions
Copy link
 #29

Updated by Jim Pingle 9 months ago

  • Plus Target Version changed from 24.03 to 24.07
Actions
Copy link
 #30

Updated by Jim Pingle 6 months ago

  • Plus Target Version changed from 24.07 to 24.08
Actions
Copy link
 #31

Updated by Jim Pingle about 1 month ago

  • Plus Target Version changed from 24.08 to 24.11
Actions
Copy link
 #32

Updated by Jim Pingle about 1 month ago

  • Plus Target Version changed from 24.11 to 25.01
Actions
Copy link

Also available in: Atom PDF