Project

General

Profile

Actions

Bug #7778

closed

DHCP relay not working correctly with bridges

Added by Sander Peterse about 7 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Category:
DHCP Relay
Target version:
Start date:
08/16/2017
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.3.3
Affected Architecture:

Description

I have running a DHCP relay (IPv4) on 4 network interfaces, but it failed to work on 2 of them.

After looking into the source code (https://github.com/pfsense/pfsense/blob/782453b4dbb77e5bc97a43f56b95a006c5434d65/src/etc/inc/services.inc#L1696) is saw a few lines related to bridges. So I removed the 2 bridges and it also started working on these 2 interfaces. Removing the bridges on these interfaces is temporary fix (as I need it for 2 OpenVPN tap servers).

You can also see this issue on the command line (by calling 'ps uax | grep relay').

The output with the bridges (on interfaces lagg0_vlan2103 and lagg0_vlan2104):
/usr/local/sbin/dhcrelay -i lagg0_vlan2101 -i lagg0_vlan2102 -i lagg0_vlan900 192.168.1.33 192.168.1.34

The output without the bridges (temporary removed):
/usr/local/sbin/dhcrelay -i lagg0_vlan2101 -i lagg0_vlan2102 -i lagg0_vlan2103 -i lagg0_vlan2104 -i lagg0_vlan900 192.168.1.33 192.168.1.34

Some details about my config:
- lagg0_vlan2101 - Regular LAN 1
- lagg0_vlan2102 - Regular LAN 2
- lagg0_vlan2103 - Regular LAN 3 with bridge0 to a tap OpenVPN server.
- lagg0_vlan2104 - Regular LAN 4 with bridge1 to a tap OpenVPN server.
- lagg0_vlan900 - The network to which the DHCP requests are relayed to the DHCP servers 192.168.1.33 and 192.168.1.34.

I think this is a bug. Or is there a good reason not to run the DHCP relay server when the interface is member of a bridge?

Actions #1

Updated by Jim Pingle about 7 years ago

  • Status changed from New to Feedback

DHCP Relay has been prevented from running on bridges since it was first added to the GUI over 10 years ago. I don't see any notes in the code about why, but presumably the daemon didn't like attaching to bridges or had some other similar problem.

Two things to check:

1. Does that longer command run if you manually kill off dhcrelay and execute it with the bridges in place?
2. If you assign the bridge interface itself and put the IP address for the bridge there, and NOT on a bridge member interface, does it work?

Searching around a bit I don't see any concrete evidence that allowing it to run on bridges would be stable/desirable though.

If you have a manged switch, which you presumably do since you're using VLANs, you're better off setting the DHCP relay/IP helper server on it instead of the firewall.

Actions #2

Updated by Sander Peterse about 7 years ago

I have done some testing as requested. The results:

1. Added bridge0 again between the VPN tap interface and lagg0_2104.

2. Killed the dhcrelay process.

3. Tried to execute:
  1. /usr/local/sbin/dhcrelay -i lagg0_vlan2101 -i lagg0_vlan2102 -i lagg0_vlan2103 -i lagg0_vlan2104 -i lagg0_vlan900 192.168.1.33 192.168.1.34
    Starts fine (no errors).

4. Killed the dhcrelay process again.

5. Started the dhcrelay process again using the web-interface, the interface (lagg0_vlan2104) has been removed again from the proces arguments. Output of 'ps aux | grep relay':
/usr/local/sbin/dhcrelay -i lagg0_vlan2101 -i lagg0_vlan2102 -i lagg0_vlan2103 -i lagg0_vlan900 192.168.1.33 192.168.1.34

6. Killed the dhcrelay process again.

7. Started with the bridge interface instead of the lagg0_vlan2104.
  1. /usr/local/sbin/dhcrelay -i lagg0_vlan2101 -i lagg0_vlan2102 -i lagg0_vlan2103 -i bridge0 -i lagg0_vlan900 192.168.1.33 192.168.1.34
    Starts fine (no errors).
Actions #3

Updated by Jim Pingle about 7 years ago

It started OK, but did it actually function as intended?

Actions #4

Updated by Sander Peterse about 7 years ago

When adding interface that's member of the bridge: yes

When adding the bridge (without it's interfaces): no

Actions #5

Updated by Sander Peterse about 7 years ago

Any updates on this issue? Do you agree this is a bug or is there a good reason why the bridge interface isn't added to the DHCP relay?

Actions #6

Updated by Jim Pingle about 5 years ago

Can you test this again on a 2.5.0 snapshot? There have been other DHCP Relay changes and it may be solved.

Actions #7

Updated by Jim Pingle over 4 years ago

  • Status changed from Feedback to Pull Request Review
  • Target version set to 2.5.0
Actions #8

Updated by Renato Botelho almost 4 years ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Renato Botelho
  • % Done changed from 0 to 100

PR merged months ago

Actions #9

Updated by Anonymous almost 4 years ago

  • Assignee changed from Renato Botelho to Sander Peterse
Actions #10

Updated by Viktor Gurov almost 4 years ago

  • Status changed from Feedback to Resolved

works as expected on 2.5.0.a.20201130.0650 -
bridges or bridge members can be upstream/downstream dhcp relay interfaces

Actions

Also available in: Atom PDF