Page 1 of 1

CHR blocking DHCP offers on bridge ports

Posted: Sun Dec 23, 2018 8:30 pm
by axe50397
I'm trying to replicate my company's network on GNS3, using only CHR routers (for all our physical RB951), and I'm having an odd issue where CHR router with bridged port (so it should act as a switch) is forwarding DHCP Requests, but blocking DHCP Offers, and when setting a host IP address manually, the gateway (not the next hop) is unreachable.

Here is the topology:

- GW has 1 DHCP-server for each port (eth3, eth4, eth5), the range is written in the top left corner of the colored rectangle boxes.
- GW has NO firewall rules, in filter, NAT or mangle, except: src-nat / masquerade in NAT.
- VPCS in TRH and Office subnets can communicate with GW, with each other and outside.
- The problem is in the Wifi subnet. As you can see, there are 3 IPs on ether5 on GW (,,
-- Wifi-1 has default route set to: -> . It can be pinged, can ping GW and outside.
-- Wifi-1 has all its ports bridged together (ether1 [trusted] and ether2), DHCP-snooping enabled.
-- Wifi-1 only has 1 IP on ether1 (
-- PC-Wifi-1 sends DHCP-Requests to Wifi-1 which forwards them to GW. (Captured between Wifi-1 and GW)
-- GW sends back DHCP-Offers broadcasted (Captured between Wifi-1 and GW)
-- DHCP-Offers aren't forwarded back to PC-Wifi-1 (Only discovers are captured)

Something else odd, after setting manually an IP on PC-Wifi-1 (, gateway, and, 5.2 are all unreachable.

Did I miss anything? I thought bridging all ports would let everything passthrough Wifi-1, including L2 broadcast packets...

IRL, the Wifi-1 and Wifi-2 (and many others) are wireless routers (RB951) connected the same way but configured as CAPs to CAPSMAN on GW, and are currently perfectly working. IRL, Wifi-1 also has a ptp IP on a different subnet than what CAPSMAN is giving to wifi clients, gateway also being the GW IP and not the CAP's IP.

Thanks for your assistance