Bug #8877: VTI P2 can trigger an endless loop trying to form a P2 ID - pfSense - pfSense bugtracker

Actions

Copy link

Bug #8877

closed

VTI P2 can trigger an endless loop trying to form a P2 ID

Added by Pi Ba about 6 years ago. Updated about 6 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Jim Pingle

Category:

IPsec

Target version:

2.4.4

Start date:

09/06/2018

Due date:

% Done:

100%

Estimated time:

Plus Target Version:

Release Notes:

Affected Version:

2.4.4

Affected Architecture:

All

Description

Enabling a vti OPT1 interface throws me the following errors after a minute while processing the 'apply' button.. likely a endless loop is causing it.?. possibly in combination with gateway groups..

PHP Errors:
[06-Sep-2018 20:58:35 CET] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /etc/inc/gwlb.inc on line 44
[06-Sep-2018 20:58:42 CET] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 8192 bytes) in /etc/inc/gwlb.inc on line 1122
[06-Sep-2018 20:58:43 CET] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32768 bytes) in /usr/local/share/pear/Net/Growl/Autoload.php on line 1

Files

2018-09-06 21_55_02-pfSense2.4alpha (Snapshot 11) [Draaiend] - Oracle VM VirtualBox.png (21.2 KB) 2018-09-06 21_55_02-pfSense2.4alpha (Snapshot 11) [Draaiend] - Oracle VM VirtualBox.png

Pi Ba, 09/06/2018 02:56 PM

Actions

Copy link

Updated by Jim Pingle about 6 years ago

Status changed from New to Not a Bug
Priority changed from High to Normal
Target version deleted (~~2.4.4~~)

That doesn't look like it would have anything to do with VTI. The lines you reference are quite different, one is a glob of dpinger PID files, one is parsing the routing table.

Probably some other feature on the box (pfBlocker or similar?) is causing PHP to use a ton of memory unrelated to this, and this was just the tipping point.

Actions

Copy link

Updated by Pi Ba about 6 years ago

agreed that the lines don't 'directly' point to vti.. however only when i enable 'that' interface its runs for a minute or more and eventually throws those errors.. ill get a stacktrace. there is some loop going round and round..

Actions

Copy link

Updated by Jim Pingle about 6 years ago

I suspect it would have done the same for any other additional interface you add there and VTI was a coincidence. Maybe it uses a slight bit more memory due to its type but not really that much going on in PHP for just VTI.

If you can get more info out of it, that would be great.

Actions

Copy link

Updated by Pi Ba about 6 years ago

File 2018-09-06 21_55_02-pfSense2.4alpha (Snapshot 11) [Draaiend] - Oracle VM VirtualBox.png 2018-09-06 21_55_02-pfSense2.4alpha (Snapshot 11) [Draaiend] - Oracle VM VirtualBox.png added

Actions

Copy link

Updated by Pi Ba about 6 years ago

Its about the vti and it looping around. see screenshot of a stacktrace.

Actions

Copy link

Updated by Jim Pingle about 6 years ago

Status changed from Not a Bug to Feedback

I can maybe see how some combination may lead to a loop here but I can't seem to make it happen on any of mine.

Somehow when trying to find the interface address to form the P2 local/remote network it's trying to treat it as a failover interface unnecessarily.

Can you attach the IPsec config for this tunnel (with any keys and such redacted)?

Actions

Copy link

Updated by Jim Pingle about 6 years ago

Subject changed from vti ipsec OPT1 interface cannot be enabled.. (out of memory) to VTI P2 can trigger an endless loop trying to form a P2 ID
Assignee set to Jim Pingle
Target version set to 2.4.4

I haven't tried setting one up this way but if someone were to have incorrectly selected something like "LAN Network" for the VTI P2 local network it could break. The local network needs to be a tunnel network address like for OpenVPN and not a network macro like people might have had on a tunnel style P2.

In commit:754b123384 I have added a check to prevent a user from picking anything other than network or address since it doesn't make sense for VTI.

I'm not sure if you did that, but I suspect maybe you did. The commit should prevent that from being picked in the future.

Actions

Copy link

Updated by Pi Ba about 6 years ago

Perhaps the issue was that i made my mobile-ipsec P2 use vti.. perhaps that does not actually make sense to do.?. it wouldn't have a defined 'remote network'.

Actions

Copy link

Updated by Pi Ba about 6 years ago

i could configure vti on a 'normal' site-to-site vpn so perhaps its just a 'user issue' :) if so then sorry for the noise.

Though would be nice if the gui could prevent the user / me from making such 'impossible' configurations ?

Actions

Copy link

#10

Updated by Jim Pingle about 6 years ago

Status changed from Feedback to In Progress

Yeah the mobile case is still a bit undefined. I can shut that down as well. I'm not sure that is feasible since VTI seems to operate strictly on a point-to-point basis so far.

I've been trying to setup input validation to remove bad combinations as I find things that don't work.

Actions

Copy link

#11

Updated by Jim Pingle about 6 years ago

Status changed from In Progress to Feedback

I just pushed another bit of input validation to prevent VTI from being selected on mobile IPsec. That should hopefully take care of any cases which can lead to this error now.

Actions

Copy link

#12