Project

General

Profile

Actions

Bug #12763

closed

VTI gateway status stuck as "pending" after reboot

Added by Marcos M about 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Viktor Gurov
Category:
IPsec
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:

Description

After rebooting the firewall, VTI gateways stay pending until a restart of dpinger.

Actions #1

Updated by Marcos M about 2 years ago

The icmp state does not exist indicating that dpinger failed in some way.

Actions #2

Updated by Jim Pingle about 2 years ago

  • Status changed from New to Feedback

I can't reproduce this here. My VTI gateways with monitoring enabled are up at boot on 22.01/2.6.0.

More information is required on exactly how to reproduce the problem or under which conditions it appears.

Actions #3

Updated by Marcos M about 2 years ago

  • Status changed from Feedback to New

Thanks for looking. I traced it down to using an FQDN (issue) vs IP (no issue) for the remote gateway. When using FQDN, I also notice the following in the system logs after reboot:

Feb 7 18:06:34     php     411     rc.bootup: Default gateway setting WAN1GW as default.
Feb 7 18:06:34     php     411     rc.bootup: Gateway, none 'available' for inet6, use the first one configured. ''
Feb 7 18:06:34     php     411     rc.bootup: route_add_or_change: Invalid gateway and/or network interface ipsec1
Feb 7 18:06:34     php     411     rc.bootup: route_add_or_change: Invalid gateway and/or network interface ipsec1
Feb 7 18:06:34     php     411     rc.bootup: route_add_or_change: Invalid gateway and/or network interface ipsec1 

Actions #4

Updated by Jim Pingle about 2 years ago

OK, that is likely because it doesn't have sufficient information to setup the interface at at that exact moment when the remote is an FQDN which requires DNS resolution.

That should narrow it down significantly, assuming there is a viable workaround.

Actions #5

Updated by Viktor Gurov almost 2 years ago

  • Assignee set to Viktor Gurov
  • Target version set to 2.7.0
  • Plus Target Version set to 22.05
  • Affected Version set to 2.6.0
Actions #6

Updated by Jim Pingle almost 2 years ago

  • Status changed from New to Pull Request Review
Actions #7

Updated by Viktor Gurov almost 2 years ago

  • Status changed from Pull Request Review to Feedback
Actions #8

Updated by Jim Pingle almost 2 years ago

  • Subject changed from VTI gateway status is pending after rebooting the firewall to VTI gateway status stuck as "pending" after reboot

Updating subject for release notes.

Actions #9

Updated by Danilo Zrenjanin almost 2 years ago

Tested the patch against the version below:

2.7.0-DEVELOPMENT (amd64)
built on Sat Apr 16 06:18:29 UTC 2022
FreeBSD 12.3-STABLE

The gateways still stay stuck in Pending after reboot. Please check again.

Actions #10

Updated by Marcos M almost 2 years ago

  • Status changed from Feedback to Confirmed

Tested on 22.05.a.20220417.0600. The FQDN VTI gateway remains pending after reboot.

Actions #11

Updated by Viktor Gurov almost 2 years ago

Marcos Mendoza wrote in #note-10:

Tested on 22.05.a.20220417.0600. The FQDN VTI gateway remains pending after reboot.

fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/727

Actions #12

Updated by Jim Pingle almost 2 years ago

  • Status changed from Confirmed to Pull Request Review
Actions #13

Updated by Viktor Gurov almost 2 years ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #14

Updated by Marcos M almost 2 years ago

  • Status changed from Feedback to Resolved

Tested on 22.01 with both patches applied and on 22.05.a.20220419.0600 with the second patch applied. The FQDN gateway shows online after reboot in both cases.

Actions

Also available in: Atom PDF