Customer updating their own MAC in portal


#1

We need a way for customers to be able to update their own router MAC address in the portal.

As it stands, if they go buy a new router, they have to wait until we are in the office and then call to give us the new info. Usually they buy their new router on a weekend.

Until the MAC is updated, they do not have access. Having some kind of captive portal that tells them what’s going on and what they need to do, or something similar, would be most helpful.

Our client fiber modems are bridged and only known MACs get access. This is why the client’s ability to update their info would be great.


#2

Option 82 is your friend here. We recently switched over to using it on our bridged segments and it has been an absolute life saver. We are now testing it on switches in our MDUs.


#3

I haven’t used Option 82, and I can’t find anything in the UBNT OLT/ONU that supports it.

I’m also not sure how that would update the setting in the network section of Sonar. When we add a device, it gets added as Non-inventoried MAC address. In there, we have to enter the MAC address.

Not arguing, love the suggestion, just don’t see all of the pieces yet.


#4

UBNT gear may not support Option 82. The way Option 82 works is you add the bridge hardware to the customer’s inventory (the ONU, subscriber module, etc) and then any device the customer attaches to that is automatically added to Sonar for that customer (with some scripting in your Mikrotik or other router). Sonar walks you through it if you use Mikrotik but your hardware vendor needs to support Option 82…


#5

Which gets back to … We need a captive portal type solution where clients can update their non-inventoried MAC address.


#6

This is how it works.

https://sonar.software/casts/provisioning-school/sonar-dhcp-batcher-and-option-82

It’s absolutely the best approach, as nobody has to update anything (you, or the customer.) There aren’t any plans for a self updating portal on the roadmap right now, but you could easily have a 3rd party dev do this with the existing portal if you wanted to.


#7

Apparently UBNT fiber gear does support Option 82 at the ONU level. The option setting was in a place that I didn’t expect.

Will test that out.


#8

DHCP is a direction we are moving to (currently using pppoe).

I know this may sound like a dumb question, however if option-82 allows for the replacement of a router with no interaction of staff or credentials to be used (in a portal from the customer as steven is suggesting, then what is there to prevent unauthorized routers from hooking up (tapping) into a customer connection?


#9

@Micah_Wine
option 82 is just a different way of thinking, (and this is from my limited knowledge so someone please correct me if I’m wrong)
Option 82 simply adds the referring CPE mac address as the dhcp relay agent. This allows the dhcp request to know that the referring mac address in sonar inventory is related to a specific customer without having to know their actual router mac. It then assigns an IP and mac to that same customer in sonar automatically.

Basically, you have to be at the customers house and connecting to their CPE to “tap” into their connection.


#10

Thinking along Micah’s line, what is to stop the customer from putting on a switch and providing service to an entire MDU complex, or just giving all of their home devices a public IP?


#11

What stops them from doing that behind a pppoe router? @Steven_Sugg
This is why you have a TOS. Enforcement can be a chore but well worth it to fall back on when needed.


#12

A PPPoE router would prevent the customer from being assigned more than one IP. That would be the goal.

I believe you are referring to “Terms of Service” Correct?

Although this provides you a means of reaction to discovering the missue, my goal would be to prevent it.


#13

Sonar only allows one IP to be bound to one MAC. So if a customer plugged in a switch, only one device would ever be authorized an IP at a time.


#14

PPPoE routers do not prevent the customer from having more than one public IP, we do this all the time.


#15

@Michael_Ducharme1 you are correct that pppoe can be configured to allow multiple connections using the same authentication (user/password) but pppoe can also be configured to limit the amount of times that a user can authenticate. For example, you can set it so if the pppoe credentials are already in use it will not authenticate a second connection.

@simon my thinking on multiple sessions is regarding the use of multiple MACs. I may not fully understand option 82 which may be my problem. If two routers tried to connect behind a client’s cpe equipment would the dhcp server see them as the same mac?


#16

@Micah_Wine Yes, we limit sessions to one per username. You can always create a second username if you want to allow a second connection even with this limitation, that is the normal way that this limit is worked around.

The other way of working around this limit is to do a framed-route to the customer for a /29, then configure the CPE as a router instead of a bridge, have it connect via PPPoE instead of the customer router, and put the first usable IP in the /29 on the LAN interface and add a DHCP server on the SU. The customer ends up still going through the PPPoE tunnel, but it is transparent to them.

With IPv6 becoming more prevalent, the need for multiple public IPv4 addresses for customers will diminish over time.


#17

@Micah_Wine Alternatively you could have a RADIUS group to set Simultaneous-Use to 2 (overriding what you most likely have as a default of 1) and have this RADIUS group apply for any customers that have a “second public IP” service, then the second username/password is not needed.

It can be a lot of work to move away from PPPoE, and there may not be as much benefit as expected since it makes many other things more complex - for instance, it is complex to allow communication between customers on a subnet while also preventing customers from doing stupid things like assigning themselves a static IP that conflicts with the gateway or another customer or handing out IPs to other customers with a backwards-connected router. You end up needing to turn to a crazy combination of client isolation plus local-proxy-arp plus bridge filter rules to block the router from sending ARP requests to customers plus static-ARP-from-DHCP to really replace PPPoE in a meaningful way, and the back-end complexity is increased. Even with all the negative aspects, PPPoE can still be pretty compelling for the customer isolation it provides. I see many other small ISPs that do not run PPPoE having to deal with many issues that we don’t have to worry about, and it is enough to make me a bit wary of the alternative.


#18

Yes, that is the main purpose of Option 82. You’d see the CPE MAC (your CPE, the customer MAC is irrelevant.)


#19

We limit the number of MAC addresses behind the CPE to one with a 300 second reset. We still use Option82 in conjunction with this. This only allows a single router to be connected to the CPE but they can change it out without having to let us know.

On a related Option82 topic, anyone doing Option82 with switches (like in an MDU)? We have tried a couple vendors but can’t seem to make it work… Would love to see someone else’s config on this.