Project

General

Profile

Actions
Copy link

Regression #11523

closed

Incorrect upstream interface

Added by Viktor Gurov almost 4 years ago. Updated over 3 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
DHCP Relay
Target version:
-
Start date:
02/24/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.5.0
Affected Architecture:

Description

another issue with `guess_interface_from_ip()` (see also #11519):

`services_dhcrelay_configure()` uses `guess_interface_from_ip()` which returns only first (top-down) interface from the `route_get($ipaddress)` output (which is slow, see #11475)

How to reproduce:
1) LAN (vtnet0) - 192.168.88.41/24
2) Create OpenVPN p2p instance with remote network 192.168.0.0/16;
3) Configure DHCP Relay with 192.168.88.99 destination server

now `guess_interface_from_ip("192.168.88.99")` returns 'ovpns1', cause it first in the `netstat -rn` output:

# netstat -rn | grep 192.168.
192.168.0.0/16     10.78.78.2         UGS      ovpns2
192.168.88.0/24    link#1             U        vtnet0
192.168.88.41      link#1             UHS         lo0

Error:

Feb 24 17:02:42 pf41 php-fpm[27990]: /services_dhcp_relay.php: No suitable upstream interfaces found for running dhcrelay!

Actions
Copy link
 #2

Updated by Jim Pingle almost 4 years ago

  • Tracker changed from Bug to Regression
  • Target version set to CE-Next

Does the patch from #11519 also solve this? If so, this can be closed and combined with it. Seems like the same root cause to me.

Actions
Copy link
 #3

Updated by Viktor Gurov almost 4 years ago

Jim Pingle wrote:

Does the patch from #11519 also solve this? If so, this can be closed and combined with it. Seems like the same root cause to me.

no, but it can be fixed in #11475 (see gitlab comment)

Actions
Copy link
 #4

Updated by Jim Pingle almost 4 years ago

Feels to me like guess_interface_from_ip() if it keeps using the full routing table would need to be changed so it finds the longest match instead of the first match, but given the other behavior going back to using route -n get is going to be much faster than parsing the whole table in PHP.

Actions
Copy link
 #5

Updated by Viktor Gurov over 3 years ago

  • Status changed from New to Resolved

fixed in #11475

tested in 2.5.1/2.6

Actions
Copy link
 #6

Updated by Jim Pingle over 3 years ago

  • Status changed from Resolved to Duplicate
  • Target version deleted (CE-Next)
Actions
Copy link

Also available in: Atom PDF