Bug #12328: IPsec VTI interface remote endpoint is not resolved the correct way - pfSense - pfSense bugtracker

Custom queries

2.4.5-p1 - Resolved/Closed
2.5.0 - Resolved/Closed
2.5.1 - Resolved/Closed
2.5.2 - Resolved/Closed
2.6.0 - Resolved/Closed
2.7.0 - Resolved/Closed
2.7.1 - All Open Issues
2.7.1 - Resolved/Closed
2.7.2 - Resolved/Closed
2.8.0 - All Open Bugs
2.8.0 - All Open Features
2.8.0 - All Open Issues
2.8.0 - All Open Regressions
2.8.0 - Feedback
2.8.0 - Needs Attention
2.8.0 - New/Confirmed
2.8.0 - Pull Requests
2.8.0 - Regressions affecting 2.7.0
2.8.0 - Resolved/Closed
21.02.2/2.5.1 - Resolved/Closed
21.05 Plus - All Closed Issues
21.05.1 Plus Target - All Closed Issues
21.05.1 Target - All Closed Issues
22.01 Plus - All Closed Issues
22.01 Target - All Closed Issues
22.05 Plus - All Closed Issues
22.05 Target - All Closed Issues
23.01 Plus - All Closed Issues
23.01 Target - All Closed Issues
23.05 Plus - All Closed Issues
23.05 Target - All Closed Issues
23.05.1 Plus - All Closed Issues
23.05.1 Target - All Closed Issues
23.09 Plus - All Closed Issues
23.09 Target - All Closed Issues
23.09.1 Plus - All Closed Issues
23.09.1 Target - All Closed Issues
24.03 Plus - All Closed Issues
24.03 Target - All Closed Issues
24.11 Plus - All Closed Issues
24.11 Target - All Closed Issues
25.01 Plus - All Closed Issues
25.01 Plus - All Open Issues
25.01 Plus - Feedback Issues
25.01 Plus - Needs Attention/Work
25.01 Plus - New/Confirmed/In Progress Issues
25.01 Plus - Pull Request Review
25.01 Plus - Waiting on Merge
25.01 Target - All Closed Issues
25.01 Target - All Open Issues
All Open Issues assigned to Me
All Open Pull Requests
Any Target - All Open Regressions
Any Target - Feedback Issues
CE-Next - All Closed Issues (Move to specific target)
CE-Next - All Open Issues
CE-Next - Feedback (Likely needs target changed)
New Issues by Category - Future Target
New Issues by Category - No Target
New Issues by Category - No Target+Future
No Target - All Open Issues (Base Only)
No Target - New Issues (Base Only)
No Target - New Issues (Base and Packages)
Release Notes - Plus Target Version (DO NOT EDIT)
Release Notes - Target Version (DO NOT EDIT)

Actions

Copy link

Bug #12328

closed

IPsec VTI interface remote endpoint is not resolved the correct way

Added by Jim Pingle over 3 years ago. Updated almost 3 years ago.

Status:

Resolved

Priority:

High

Assignee:

Jim Pingle

Category:

IPsec

Target version:

2.6.0

Start date:

Due date:

% Done:

100%

Estimated time:

Plus Target Version:

22.01

Release Notes:

Default

Affected Version:

All

Affected Architecture:

Description

In interface_ipsec_vti_configure(), the remote end of an IPsec VTI interface is not resolved the correct way (e.g. The b.b.b.b part of ifconfig ipsecN tunnel a.a.a.a b.b.b.b).

The remote-gateway value of the IPsec P1 is passed directly to ifconfig which is fine for IP addresses but not with hostnames. Elsewhere in the IPsec code, ipsec_get_phase1_dst() is used which runs hostnames through resolve_retry() which is better than leaving it up to the OS resolver.

This could also be affecting the speed at which VTI interfaces are created or changed (e.g. NG 6586 or NG 6758).

To me, I'm working on a fix.

Related issues

Related to Bug #12335: IPsec DNS inefficiency

New

Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Jim Pingle over 3 years ago

Status changed from New to Pull Request Review

MR: https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/367

Actions

Copy link

Updated by Jim Pingle over 3 years ago

Status changed from Pull Request Review to Feedback

Merged.

Actions

Copy link

Updated by Jim Pingle over 3 years ago

% Done changed from 0 to 100

Applied in changeset 7f0d57f46cec27547b2745b87d24ebe0755ee16e.

Actions

Copy link

Updated by Jim Pingle over 3 years ago

The test config I used has a total of 20 tunnels, 5 of the 20 are VTI, and 1 of those 5 is using a hostname. Of the other non-VTI tunnels, 4 are using hostnames.

Before (Working DNS):

Configuring IPsec VTI interfaces...done.
DEBUG: Exec time: 13.512260913849 sec
Configuring IPsec VPN...done
DEBUG: Exec time: 28.750664949417 sec

After (Working DNS):

Configuring IPsec VTI interfaces...done.
DEBUG: Exec time: 5.2541391849518 sec
Configuring IPsec VPN...done
DEBUG: Exec time: 28.772891998291 sec

The IPsec configuration time was unchanged, as expected, but the VTI interface configuration was much faster (5s vs 13s), so about a 59% decrease.

Another test with a deliberately broken DNS configuration:

Before (Broken DNS):

Configuring IPsec VTI interfaces...done.
DEBUG: Exec time: 91.90074300766 sec
Configuring IPsec VPN...done
DEBUG: Exec time: 114.08590197563 sec

After (Broken DNS):

Configuring IPsec VTI interfaces...done.
DEBUG: Exec time: 5.2490708827972 sec
Configuring IPsec VPN...
DEBUG: Exec time: 113.86489200592 sec

Again the VPN configuration is about the same (slower, due to lack of DNS and there being 5 tunnels total using hostnames), but the VTI configuration is much faster, about a 94% decrease vs the old method.

Needs further testing with more VTI entries using hostnames as the remote gateway to see if the gain scales, but so far it looks good to me.

Part of the problem with the slowness due to lack of DNS at the first pass of "Configuring IPsec VTI interfaces" -- they do get configured later during the "Configuring IPsec VPN" but at least now the lack of DNS isn't holding the whole boot back during that first attempt. It's a bit of a chicken-and-egg scenario since the required DNS servers may not be available until well after the first step runs.

Actions

Copy link

Updated by Jim Pingle over 3 years ago

Status changed from Feedback to In Progress

Still a potential issue here.

At the end of rc.bootup another ipsec_configure() is run but the boot flag is cleared so it isn't printing to the console what is happening. However, if DNS is broken at that point it takes quite a long time. I suspect it's due to resolve_retry() using a default of 10 retries which is kind of pointless if DNS is completely down.

So we need to:

Make that last IPsec configure step print what it's doing on the console
Make resolve_retry() use an optional number of attempts instead of hardcoding 10
Find a way to make it only try once at this step but allow it to use more attempts on a regular in-GUI reconfigure for example

Actions

Copy link

Updated by Jim Pingle over 3 years ago

Need to think on this a little more since I'm seeing quite a bit of inefficiency, such as:

At the end of rc.bootup, it calls ipsec_configure() and then filter_configure(), but ipsec_configure() already calls filter_configure() at the start, so unless there is a difference before/after I'm not seeing why it should be called both places. Both ipsec_configure() and filter_configure() end up trying to resolve all the remote FQDNs in IPsec so at the end of the boot process it's trying at least 3x (maybe more) to resolve these FQDNs. If DNS is unavailable, that will lead to massive slowdown.

I'm going to move that to a separate Redmine issue since it is not VTI specific and this issue was focused on that aspect, which appears to be better, and that larger issue can wait for the next release where we have more time to consider options and test.

For now I will at least make that last IPsec configure step in the boot process print what it's doing.

Actions

Copy link