DHCP Relay over speedfusion tunnel Not Forwarding Offers Back to Client

Everything Else
1

Device: BR2 (latest firmware) Setup: SpeedFusion tunnel to FusionHub on Azure

Overview: Here is what we are trying to do. I have 10 BR2s out in the wild connected to a Remote FusionHub in Azure. Each of these create a speedfusion tunnel to my Azure private network. Currently have 2 machines in Azure, the fusionhub and an Ubuntu VM running a DHCP server. We want any clients who connect to any of the BR2s to get an ip address from the DHCP server in Azure and be able to send and receive traffic to other daemons on that Ubuntu DHCP server via DHCP relay on the BR2.

Im testing with a single device right now. I have a BR2 connected to a FusionHub running on Azure via SpeedFusion. I have a VLAN interface (VLAN 10, 192.168.68.1/22) on the BR2 called “Conference WiFi” with DHCP Relay enabled pointing to a DHCP server (10.3.0.5) running on an Ubuntu VM in Azure on the same VNet as FusionHub.

What’s Working:

  • SpeedFusion tunnel is up and routing correctly
  • BR2 can ping 10.3.0.5 through the tunnel
  • DHCP relay is forwarding DISCOVER packets from clients to the DHCP server
  • DHCP server is receiving the DISCOVER and sending back an OFFER to 192.168.68.1:67 (the relay agent)
  • Confirmed via tcpdump on the DHCP server — offers are being sent with broadcast flag set

What’s Not Working: The BR2 relay agent receives the DHCP OFFER from the server but does not forward it back to the client on VLAN 10. The client never receives the offer and keeps sending DISCOVER packets indefinitely.

Confirmed via tcpdump on DHCP server:

10.3.0.4.67 > 10.3.0.5.67: BOOTP/DHCP, Request from [client-mac] via 192.168.68.1 (DISCOVER)
10.3.0.5.67 > 192.168.68.1.67: BOOTP/DHCP, Reply [Broadcast] Your-IP 192.168.68.10 (OFFER)

The offer arrives at the relay (192.168.68.1) but the client never sees it. Confirmed via tcpdump on the client — no OFFER packets arrive.

Things I’ve Tried:

  • DHCP Option 82 enabled and disabled
  • always-broadcast on in ISC DHCP server config
  • Inter-VLAN routing enabled on the VLAN interface
  • IP Forwarding mode on FusionHub
  • Verified correct static routes on FusionHub for return path

Question: Is DHCP relay on a VLAN interface supported on the BR2? Is there a known issue with relay responses not being forwarded back to clients on VLAN interfaces? Is there a workaround?

2

Update - Additional Troubleshooting:

We have done extensive packet capture troubleshooting and can now pinpoint the exact failure:

Confirmed working:

  • BR2 receives DHCP DISCOVER from client on VLAN interface
  • BR2 relay correctly forwards DISCOVER to DHCP server as unicast
  • DHCP server receives DISCOVER and sends OFFER back to relay agent (192.168.68.1:67)
  • Confirmed via tcpdump on DHCP server — offer is sent with broadcast flag set (always-broadcast on in ISC DHCP config)
  • FusionHub static route correctly forwards return traffic through SpeedFusion tunnel
  • FusionHub can ping 192.168.68.1 directly

Confirmed NOT working:

  • Client never receives the DHCP OFFER
  • Confirmed via tcpdump on client — no inbound DHCP packets arrive at all
  • BR2 DHCP Event Log shows empty — no relay activity logged despite relay logging being enabled
  • Tested with multiple clients (Mac, Windows)
  • Tested with VLAN 10 and VLAN 2
  • Tested with both unicast and broadcast flag on client DISCOVER

Conclusion: The BR2 relay agent is receiving the DHCP offer back from the server but is not forwarding it to the client on the VLAN interface. The forward path (client → server) works perfectly. Only the return path (server → client) is broken.

Additional environment details:

  • DHCP relay is on a VLAN interface (tested VLAN 2 and VLAN 10)
  • SpeedFusion tunnel is L3 (not L2 bridge)
  • DHCP server is remote, reachable via SpeedFusion tunnel through FusionHub on Azure
  • Tested with FusionHub built-in DHCP and ISC DHCP on separate VM
3

Sounds like logging a ticket with engineering will get you a definitive answer on this (and i expect a special build firmware that fixes it pretty quickly).

1 Like
4

Have you double-checked the ‘Internal Network Firewall’ rules on the BR2? I have seen cases where return traffic for local services like DHCP relay gets dropped if the remote server’s IP isn’t explicitly permitted to talk back to the VLAN gateway, even if general routing is functional. It might also be worth verifying if the ‘Access Service’ settings for the PepVPN allow the remote subnet to initiate these specific UDP responses.

6

I didn’t know there was a relay server.

I’m using a layer 2 tunnel for one SpeedFusion link for other reasons, and DHCP works over that.