DHCP requests not getting passed through BRIDGED interface

Question

Ref: https://community.sophos.com/products/unified-threat-management/f/management-networking-logging-and-reporting/33877/dhcp-not-getting-through-in-bridge-mode 
 
 I'm trying to get utm to pass a dhcp offer and ack through a bridge consisting of 2 interfaces. 
 
 eth0 - leg 1 of bridge eth1 - leg 2 of bridge eth2 - management interface to for webadmin eth0/eth1 interfaces are bridged with no ip defined (0.0.0.0/0) 
 eth0 connects to an upstream dhcp server eth1 connects to a downstream client configured for dhcp 
 
 tcpdump -i br0 port 67 or port 68 -e -n -vv Executing on dhcp server indicates the following repeating pattern:

21:44:43.720005 00:0c:29:2f:65:22 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0. 68 > 255.255.255.255. 67 : [udp sum ok] BOOTP/DHCP, Request from 00:0c:29:2f:65:22 , length 300, xid 0xd686f22e, secs 792, Flags [none] (0x0000) Client-Ethernet-Address 00:0c:29:2f:65:22 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 8: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP, Classless-Static-Route Vendor-Class Option 60, length 12: "udhcp 1.30.1" Hostname Option 12, length 7: "OpenWrt" 21:44:44.721223 00:50:56:2e:33:01 > 00:0c:29:2f:65:22, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 10.10.1.1.67 > 10.10.1.144.68 : [udp sum ok] BOOTP/DHCP, Reply , length 300, xid 0xd686f22e, secs 792, Flags [none] (0x0000) Your-IP 10.10.1.144 Client-Ethernet-Address 00:0c:29:2f:65:22 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 10.10.1.1 Lease-Time Option 51, length 4: 21600 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 10.10.1.1 Domain-Name-Server Option 6, length 4: 10.10.1.1 Domain-Name Option 15, length 12: "local.domain" BR Option 28, length 4: 10.10.1.255

From this I understand the dhcp server is receiving the request and making an offer. However, the offer is not getting passed through to the client. Dhcp relay is configured as follows; 10.10.1.1 is the upstream dhcp server. Bridge interface is the bridge of eth0 & eth1. 
 Firewall rule bridge (network) -> any -> bridge (network). Is enabled w/logging. Nothing shows up in the firewall log about blocking the dhcp server reply. 
 How do get the dhcp server reply traffic to traverse the bridge?

Jay Jay · Answer

I wanted to offer an update. This working solution is not related to UTM, but ultimately solved the issue of using a firewall without wpa_supplicant support (like XG!). This accomplishes two things - ONT authentication and no double nat for the firewall. 
 An x86 openwrt vm instance was created with 2 interfaces. One int for management, other to connect to the ONT. 
 Defined a vswitch/portgroup that is common to openwrt and the firewall vm. Vswitch uplinks to a physical nic that the ONT is connected to. 
 While this works well, there's one big problem. Both the openwrt ONT facing interface and firewall wan interface have the same mac. The first to handle the 802.1x authentication, the 2nd to obtain ip via dhcp, respectively. Both require the interface mac to match the mac embedded in the 802.1x certificates. Practically, all inbound traffic is hitting both VM's. Although openwrt has no ip defined, the interface still sees this traffic. And ( I believe?) because the macs are identical, openwrt does not reject this traffic. This results in more cpu usage/electrical consumption (~10 watt delta according to the UPS with openwrt running vs off). Still, I think this is a small price to get this actually working. 
 If anyone on att/fiber wants details, see this thread https://www.dslreports.com/forum/r32728401-AT-T-Fiber-Openwrt-Gateway-Bypass-to-allow-firewall-router-of-your-choice . Specifically this post https://www.dslreports.com/forum/r32741009- . Note, it does build on earlier information so really read the whole thing. 
 I do want to add, this was more a proof of concept than anything else. The right way to do is have a single device handle both 802.1x authentication and nat/firewall duties. This can be done with UTM, but not XG. 
 I'll reserve my opinions of XG for after I've spent more time with it. Thus far the color scheme is really killing the whole UI.