Meraki DHCP and using it on prem

[InfraEngineer20]

Hi

Not sure if the right forum board, trying to do 802.1x set up wired for our Meraki switches, we have a RADIUS set up, and we are using the same key for 802.1x wired and 802.1x wireless, but the difference is on our network is our hidden wireless SSID gets an IP address from a DHCP scope we have set up on-prem DC, were our visible wireless SSID, uses the Meraki DHCP scope to provide IP addresses.

when we use our 802.1x wired currently it is getting an IP address from the on-prem DC DHCP scope for the hidden wireless SSID

My thinking is that the 802.1x wired and wireless should use different keys for each 802.1x

We either need our visible wireless SSID, needs to have its own on-prem DHCP scope to provide IP address so our visible wifi will instead of getting an IP address from Meraki DHCP would get it from on-prem and then we would point the 802.1x wired to the on-prem visiable wireless DHCP scope.

FYI (hidden wifi SSID gets access to internal resources, visible wifi SSID gets out to the internet and no access to internal resources)

Any one have any other ideas

[alemabrahao]

Your explanation is a bit confusing, but why don't you just create a new policy on your Radius server?

[InfraEngineer20]

Hi,

Sorry about the confusion, just trying to explain it by giving company information away.

[alemabrahao]

And if you want to get IP from DHCP server you need to configure your SSID to bridge mode.

[InfraEngineer20]

can we bridge Meraki DHCP to our own on prem 802.1x wired 

[alemabrahao]

Bridge Mode

In bridge mode, the Meraki APs act as bridges, allowing wireless clients to obtain their IP addresses from an upstream DHCP server.

Bridge mode should be enabled when any of the following is true:

• Wired and wireless clients in the network need to reach each other (e.g., a wireless laptop needs to discover the IP address of a network printer, or wired desktop needs to connect to a wireless surveillance camera)
• Layer 2 multicast and broadcast packets (e.g., ARP, Bonjour) need to propagate in a limited manner to both wired and wireless clients for device discovery, networking, etc.
• The wireless network needs to support legacy VPN clients (i.e., those that do not support NAT Traversal)
• Wired and wireless clients need to have IP addresses in the same subnet for monitoring and/or access control reasons (e.g., a web gateway in the network allows/denies internet access based on the client’s IP address)
• Wireless traffic needs to be VLAN-tagged between the Meraki AP and the upstream wired infrastructure 
• If IPv6 is used on the network; see the article on IPv6 bridging for more information

The implications of enabling bridge mode are as follows:

• An administrator cannot enable adult content filtering on the SSID; it is disabled by bridge mode using the DNS server(s) advertised by the network’s DHCP server because the feature is DNS-based

• Multiple DHCP servers are allowed, but they must assign IP addresses to wireless clients from the same subnet; this enables the IP addresses to be routed by the LAN, to which the Meraki APs are connected

Use Cases

Bridge mode works well in most circumstances, particularly for seamless roaming, and is the simplest option to put wireless clients on the LAN. Layer 3/7 firewall rules and traffic shaping can be used to restrict client traffic before it can reach the wired network, and VLAN tagging can be used to put wireless clients on a specific subnet upstream.

Bridge Mode
In bridge mode, the Meraki APs act as bridges, allowing wireless clients to obtain their IP addresses from an upstream DHCP server.

Bridge mode should be enabled when any of the following is true:

Wired and wireless clients in the network need to reach each other (e.g., a wireless laptop needs to discover the IP address of a network printer, or wired desktop needs to connect to a wireless surveillance camera)
Layer 2 multicast and broadcast packets (e.g., ARP, Bonjour) need to propagate in a limited manner to both wired and wireless clients for device discovery, networking, etc.
The wireless network needs to support legacy VPN clients (i.e., those that do not support NAT Traversal)
Wired and wireless clients need to have IP addresses in the same subnet for monitoring and/or access control reasons (e.g., a web gateway in the network allows/denies internet access based on the client’s IP address)
Wireless traffic needs to be VLAN-tagged between the Meraki AP and the upstream wired infrastructure
If IPv6 is used on the network; see the article on IPv6 bridging for more information

The implications of enabling bridge mode are as follows:

An administrator cannot enable adult content filtering on the SSID; it is disabled by bridge mode using the DNS server(s) advertised by the network’s DHCP server because the feature is DNS-based

Multiple DHCP servers are allowed, but they must assign IP addresses to wireless clients from the same subnet; this enables the IP addresses to be routed by the LAN, to which the Meraki APs are connected

Use Cases
Bridge mode works well in most circumstances, particularly for seamless roaming, and is the simplest option to put wireless clients on the LAN. Layer 3/7 firewall rules and traffic shaping can be used to restrict client traffic before it can reach the wired network, and VLAN tagging can be used to put wireless clients on a specific subnet upstream.

 Full doc: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Modes_for_Client_IP_Assignme...