Project

General

Profile

Actions

Bug #12335

open

IPsec DNS inefficiency

Added by Jim Pingle over 2 years ago. Updated 15 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
IPsec
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
24.07
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

Various aspects of configuring IPsec are inefficiently using DNS. There is a lot of room for improvement here.

For example: 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.

It may make sense to use a very limited DNS cache to consolidate this for short-term usage, for example, start a cache in ipsec_configure() which shares it with the filter_configure() it calls, so that it doesn't need to re-resolve the same hostnames multiple times in these contexts.

Additionally, look at all calls of ipsec_get_phase1_dst() such as when configuring VTI interfaces, configuring IPsec, on status_ipsec.php, in the widget, etc -- We should do a DNS availability check to avoid every call of that function being forced to wait on DNS to timeout over and over.

ipsec_get_phase1_dst() now calls resolve_retry() which defaults to 10x attempts, we should change this to a function parameter so that different timing (e.g. at boot) can use less retries vs later. It's more common for DNS to be unavailable at boot for various reasons.

Marking for the next version since this needs more research and planning than we have time for at the moment.


Related issues

Related to Bug #12328: IPsec VTI interface remote endpoint is not resolved the correct wayResolvedJim Pingle

Actions
Related to Bug #14893: Large number of IPsec tunnels causes long filter reload timesFeedbackMarcos M

Actions
Actions #1

Updated by Jim Pingle over 2 years ago

  • Related to Bug #12328: IPsec VTI interface remote endpoint is not resolved the correct way added
Actions #2

Updated by Viktor Gurov over 2 years ago

Jim Pingle wrote:

Additionally, look at all calls of ipsec_get_phase1_dst() such as when configuring VTI interfaces, configuring IPsec, on status_ipsec.php, in the widget, etc -- We should do a DNS availability check to avoid every call of that function being forced to wait on DNS to timeout over and over.

see check_dnsavailable(): https://github.com/pfsense/pfsense/blob/master/src/etc/inc/system.inc#L2732

Actions #3

Updated by Jim Pingle over 2 years ago

  • Plus Target Version changed from 22.01 to 22.05
Actions #4

Updated by Jim Pingle almost 2 years ago

  • Plus Target Version changed from 22.05 to 22.09
Actions #5

Updated by Jim Pingle over 1 year ago

  • Plus Target Version changed from 22.09 to 22.11
Actions #6

Updated by Jim Pingle over 1 year ago

  • Plus Target Version changed from 22.11 to 23.01
Actions #7

Updated by Jim Pingle over 1 year ago

  • Plus Target Version changed from 23.01 to 23.05

Bump this forward again, not enough spare cycles this release to dig into it.

Actions #8

Updated by Jim Pingle 11 months ago

  • Plus Target Version changed from 23.05 to 23.09
Actions #9

Updated by Jim Pingle 7 months ago

  • Plus Target Version changed from 23.09 to 24.01
Actions #10

Updated by Jim Pingle 6 months ago

  • Plus Target Version changed from 24.01 to 24.03
Actions #11

Updated by Jim Pingle 5 months ago

  • Related to Bug #14893: Large number of IPsec tunnels causes long filter reload times added
Actions #12

Updated by Jim Pingle 15 days ago

  • Plus Target Version changed from 24.03 to 24.07
Actions

Also available in: Atom PDF