Bug #7778: DHCP relay not working correctly with bridges - pfSense - pfSense bugtracker

Actions

Copy link

Bug #7778

closed

DHCP relay not working correctly with bridges

Added by Sander Peterse over 6 years ago. Updated over 3 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Sander Peterse

Category:

DHCP Relay

Target version:

2.5.0

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

Copy link

Updated by Jim Pingle over 6 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

Copy link

Updated by Sander Peterse over 6 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:

/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.

/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

Copy link