Project

General

Profile

Actions

Bug #12335

open

IPsec DNS inefficiency

Added by Jim Pingle over 2 years ago. Updated about 2 months 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 timesResolvedMarcos M

Actions
Actions

Also available in: Atom PDF