Non-Transparent Bridging Option

We recently picked up some Cambium gear (ePMP100, Force200) to start upgrading our network. Currently to manage our subs we have an authentication system that checks what MAC address traffic is coming from and shapes it accordingly. This system has worked very well for us across MikroTik, Ubiquiti, and even our old 900MHz Canopy equipment. However, something seems to be different with our new stuff. Hopefully I can explain this properly:

Our auth system is based on the MikroTik Hotspot system. We authorize/limit by the SM wireless MAC address at the customer's house, so our customers can have whatever end device they choose without needing to worry about logins or notifying us. By default, in bridge mode Ubiquiti and our Canopy 900MHz SM are non-transparent where they pass on the MAC address of their wireless (exit) interface as the traffic source MAC address. In MikroTik bridges the interface is set to 'station-pseudobridge' and the same MAC forwarding occurs. In Ubiquiti devices this bridging style can be changed to transparent by selecting "WDS (Transparent Bridge Mode)" in the configuration.

With our entire billing and authoization system as well as network infrastructure built around this functionality, it would be extremely difficult and time consuming to rework. Is it possible to enable this bridging mode on the SM, and if not would it be possible to add this as a feature?

Thanks!

Hello,

Currently Cambium's ePMP family of products does not support this feature. Your ePMP SMs would need to be configured in NAT mode for the SMs to use their MAC address for all traffic out of the SM. On the other hand, Cambium's PMP family of products (e.i. PMP 450, PMP450i, PMP450m, etc) do support a "Translation Bridging" mode that does what you have described, and it is described here: http://community.cambiumnetworks.com/t5/PMP-Getting-Started/Network-Address-Translation-NAT/td-p/39288

At the moment, I do not believe we have plans to implement something like this in the ePMP family of products.

Regards


Nathan A wrote:  We authorize/limit by the SM wireless MAC address at the customer's house

We do a similar kinda thing on our older non-Camium wireless stuff - and so with ePMP, we set the SM's up in NAT mode, which works fine for us.  All the trafic to/from the SM goes with the SM's wireless MAC and wireless IP, and our traffic graphs and our NetEqualizer is happy to see that MAC and IP as one device that it can authenticate and shape and count data totals for.

Thank you for letting me know about the PMP gear solution.  We will see if we can get something to work with the NAT feature or with additional hardware.


@ninedd wrote:

Nathan A wrote:  We authorize/limit by the SM wireless MAC address at the customer's house

We do a similar kinda thing on our older non-Camium wireless stuff - and so with ePMP, we set the SM's up in NAT mode, which works fine for us.  All the trafic to/from the SM goes with the SM's wireless MAC and wireless IP, and our traffic graphs and our NetEqualizer is happy to see that MAC and IP as one device that it can authenticate and shape and count data totals for.


With this method would you be double NATing to customer routers then? We would like to avoid that as much as possible.

The easiest solution is to set the radios up for NAT and direct the customers to use bridge mode on their device.  ALmost all newer routers have bridge mode available.  The alternative is to set a DMZ in the radio and direct customer to use static IP of the DMZ in their router and then they can control port forwards and such.  We no longer run any radios in bridge mode to residential.  Just to many issues brought on by customers that "know everything about networking"  But as far as a double NAT situation if they just plug it in and get DHCP address -- we have tested this over and over and in 99% of cases it causes Zero problems.

Yes, if we NAT at the SM, that’d be double NATing in most cases. We really don’t see problems doing that, and it’s what we’ve done with our older (non-Cambium) gear for years with no real issues. Far less issues than we saw with some bridge gear when someone plugs a router in backwards and DHCPs out 192 numbers to everyone. :slight_smile:

We're transitioning from 99.9% bridge on PMP and ePMP to hopefully 90% or better NAT+DMZ for all platforms.

We also do the double NAT thing, but it's really not an issue with DMZ on the SM.

Are you able to process option 82 with your DHCP server? If so EPMP does have support for option 82. With DHCP ISC I was able to succesfully limit leases based on option 82 fairly easily.

I know this was marked as 'solved', but I wanted to revisit this as there is a new configuration option out now that may help others searching for this answer. With firmware 3.3 there is an ARP-NAT option under the 'network' configuration on the client side when set to bridge mode. This option does excatally what we needed for a flawless cambium integration into our network. We did need to set our MikroTik DHCP server up with a relay setting of 255.255.255.255 to accept the client DHCP requests, but everything works great. Thank you Cambuim!

2 Likes

Nathan, can you expand on this a bit?  I am trying exactly this in our lab and not getting the results I expected...

Our SMs are in bridge mode to avoid a tripple NAT. Most of our residential customers are already served a private from our routers due to a lack of IPv4 public space. This works fine. We give public IPs to those that need them.

Anyway, I really want a way to track customer MAC addresses in our Mikrotik's better. When a customer replaces a home router, it messes up our queues for that customer and is becomming a headache to keep track of. 

I thought by reading this post and the description in the SM about ARP-NAT, I would leave the SM in bridge mode but all traffic behind it would show as coming from the Ethernet MAC address of the SM. That is not the case with my testing. 

If I do not create a 255.255.255.255 relay in our DHCP server, the devices behind the SM never pull an address. Once I add that, they pull an IP but the MAC associated with that IP is the MAC of the computer or router behind the SM, not the SM Ethernet MAC like I was expecting.

Am I missing the concept here of ARP-NAT?  I really want to avoid running the SM in router or NAT mode since that creates a tripple NAT and that seems to be asking for trouble down the road...