pfSense

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.

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.

I moved the longer term issue over to #12335