DHCP requests not getting passed through BRIDGED interface

As I understand correctly the bridge connects the DHCP server directly with the client each on one leg of the bridge?

If that is the case, then I think you don't need a DHCP relay because a relay is needed for routing a DHCP request to another subnet.

Also, why don't you have an IP-address configured on the Brdige interface? I think you need to give the bridge an IP in the same segment as the DHCP server.

As I understand correctly the bridge connects the DHCP server directly with the client each on one leg of the bridge?

If that is the case, then I think you don't need a DHCP relay because a relay is needed for routing a DHCP request to another subnet.

Also, why don't you have an IP-address configured on the Brdige interface? I think you need to give the bridge an IP in the same segment as the DHCP server.

As stated by apijnappels ... dhcp relay should not work for a Layer2 connection.

Possible your DHCP-request is blocked by firewall. Would check firewall-live-log.

That was my understanding too, but until I enabled the relay option I wasn't getting any requests at the dhcp server.

No ip is because I want utm to strictly bridge the two connections and pass everything through with no filtering - transparent firewall.

At some crazy hour during the night the problem was resolved.  This whole set up is under esxi.  I had to enable promiscuous mode for both legs of the interfaces in the bridge. Dhcp offer and ack then passed through.

Ultimately, this doesn't solve my main issue, which is ISP related.  Specifically isp uses 802.1x to authenticate the fiber connection. This is achievable using either their gateway box or with wpa_supplicant using extracted certs from said gateway box.   Before implementing the 802.1x, I tested using another dhcp client downstream of the utm to make sure an upstream dhcp server's offer and ack was able to pass through properly.  While i'm able to get utm to 802.1x authenticate, att's dhcp offering is glitchy unless made directly to the client on the same device as the 802.1x auth. I think this has something to do with mac addresses.  Anyway, that's outside the scope of this thread and a headache for att customers who do not wish to use att provided equipment.

Perhaps I need to implement something similar to what the att gateway does.  It allows you to define one mac address as a pass through device. This device received the public ip of the connection. Sort of like a DMZ client.  However, there is still double nat going on (gateway is the first hope in a tracert to anywhere).  It was my understanding natted devices cannot have public ip's, especially identical to the IP on the wan facing side of NAT?

The need for promiscuous mode actually makes sense for your configuration.

I would talk to your ISP some more.   There should be a way to implement one of these two configurations to eliminate the double NAT:

1. Gateway in bridge mode - Gateway handles the network authentication, but does not implement firewall and NAT functions.
2. Network using MAC authentication - Gateway not present, but network authenticates based on the MAC address of customer-provided (fiber-enabled) equipment.
3. Gateway NATs to a subnet that you do not need.   For example, if your internal network uses 192.168.x.x, configure their firewall for 10.10.x.x.   Then configure all of your NAT rules in the ISP Gateway, as well as an route to send traffic for 192.168.x.x to the UTM address in 10.10.x.x..   Then you configure UTM as a router without NAT.   You should be able to configure all of your desired security options this way, without double NAT.

For completeness, here are two reminders about the way that UTM implements bridge mode:

• By default, only IPV4 traffic is passed.  You must specify any other Ethertypes that you want to flow across the bridge.   The complete IANA Ethertype list is available here:
  https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml
  
• For web filtering, you should (must?) check the box for "Use Full Transparent Mode" for any Filter Profiles that will be accepting traffic from the bridge interface.   (Note: The box is only visible when a bridge interface has been configured.)   I suppose this means if you have traffic arriving on a mix of bridge and non-bridge interfaces, you should split them onto separate filter profiles using the Allowed Networks list.

Douglas, thank you for your response.  I'll try to address each of your points.

1) Bridge mode is not an option.  They offer a pseudo passthrough mode which uses some means to pass the public ip to a single device (mac) behind the gateway.  However, traffic is still double natted.  All traceroutes to any host on the internet indicate hop 1 as the gateway. This gives the appearance of bridge mode, but not true functionality.

2) This would be ideal, albeit redundant.  Their main authentication revolves around the ONT (Optical Network Terminal).  It's a small cpe device which converts fiber to ethernet. Upstream systems use the ont's mac and serial to authenticate on the network.  HOWEVER, it will not actually pass any client traffic until the 802.1x authentication has successfully completed.  Normally the isp gateway performs this, but as I prefer the gateway in the trash, other options are used.  I don't know why att uses this system, other fiber providers (fios, google), are much simpler.  It is att we're talking about here - resistance is futile... prepare to be assimilated is their motto.

3) This approach is worth trying. Can you clarify "Then configure all of your NAT rules in the ISP Gateway"?  An example perhaps?  What I'm thinking of is using an x86 openwrt vm instead of the physical isp gateway.  I can do the necessary 802.1x auth in openwrt successfully.

Edit: Utm as a router without nat meaning no masquerade rules?

Edit2:  Re the nat rules in #3, you mean configure the gateway to allow inbound traffic (pinholes, port forwards) as needed?  Why not just nat everything inbound 1:1 to the utm ip?

Edit3: I'm trying to visual how to implement this practically.  Using your example above, the ip part is simple enough to figure out, but what about a gateway ip on the utm's wan interface?

Not sure how to elaborate, but it is actually the configuration that I am using.  Your special box needs to play the role of the firewall.

Internet --- Firewall --- UTM (bridged interface) --- switch/router --- rest of internal network

• Firewall handles all NAT and Masquerading.
• Firewall ACLs permit normal allow/block rules (no use of DNAT-to-DeadEnd)
• Firewall interface and UTM bridged interface have addresses on the datacenter subnet, so data center traffic does not need routing.
• UTM is on path to internet, so it can enforce both Transparent mode and Standard Mode proxies.
• Firewall needs routing rules to send private-ip traffic toward the internal switch/router, default traffic flows toward the internet
• UTM has also has routing rules to send private-ip traffic toard the internal switch/router, default address flows toward the firewall.

Douglas, I guess a dumbed down explanation is what i was looking for, with specifics of what gets entered where in terms of IP's, firewall and nat rules.  IE, I need it explained like i'm a 5 yr old :)

I searched high and lo to try to find a tutorial or guide for a similar implementation but fell short.  Thanks for your efforts.

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.