Project

General

Profile

Actions

Bug #12328

open

IPsec VTI interface remote endpoint is not resolved the correct way

Added by Jim Pingle about 2 months ago. Updated about 2 months ago.

Status:
Feedback
Priority:
High
Assignee:
Category:
IPsec
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
21.09
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 inefficiencyNewJim Pingle

Actions
Actions #1

Updated by Jim Pingle about 2 months ago

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

Updated by Jim Pingle about 2 months ago

  • Status changed from Pull Request Review to Feedback

Merged.

Actions #3

Updated by Jim Pingle about 2 months ago

  • % Done changed from 0 to 100
Actions #4

Updated by Jim Pingle about 2 months 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 #5

Updated by Jim Pingle about 2 months 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 #6

Updated by Jim Pingle about 2 months 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 #7

Updated by Jim Pingle about 2 months ago

  • Related to Bug #12335: IPsec DNS inefficiency added
Actions #8

Updated by Jim Pingle about 2 months ago

I moved the longer term issue over to #12335

Actions #9

Updated by Jim Pingle about 2 months ago

  • Status changed from In Progress to Feedback

This is OK as-is for the moment, could use more testing but the code I was going to add for this release is in the tree.

Actions

Also available in: Atom PDF