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.
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
- 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.
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..
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.
Its about the vti and it looping around. see screenshot of a stacktrace.
- 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)?
- 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.
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'.
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 ?
- 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.
- 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.
Okay thanks. So wait for a RC build now or gitsync to test.? Seems snapshots don't get updated a.t.m. .
Should have something up on Monday to try with gitsync at least, hopefully an RC as well.
- % Done changed from 0 to 100
- Status changed from Feedback to Resolved
Invalid combinations mentioned here are rejected on current RC snap
Also available in: Atom
PDF
Updated by 
Updated by ![2018-09-06 21_55_02-pfSense2.4alpha (Snapshot 11) [Draaiend] - Oracle VM VirtualBox.png](/attachments/download/2568/2018-09-06%2021_55_02-pfSense2.4alpha%20(Snapshot%2011)%20%5BDraaiend%5D%20-%20Oracle%20VM%20VirtualBox.png){kind=link}