I used to work at a place about 10 years ago where we had a cluster of six Android devices that we had used for our SMS gateway. At the time it worked fantastic, we eventually rolled off it to a different service. Somehow, we never ran into issues with carrier.

The proxy is part of our platform so the source isn't public, but the concept is straightforward and the blog post covers the core logic. Happy to answer questions about the approach if you're building something similar!

Yeah IPv6 would solve this because we wouldn't have to go through the proxy at all, since each VM could get their own. Unfortunately IPv6 isn't quite as supported as we'd like.

Ubiquity in general has had garbage support for IPv6 since the beginning.

They claimed most of their customers aren't asking for it when I pushed them on the issue years ago.

Yup, absolutely. I'm so annoyed by this. I haven't been able to get either my Comcast IPv6 address pool set up and usable throughout my home network (three switches and two Unifi Pro 6 WAPs, across a few VLANs), nor my HE.net tunnel.

So annoyed.

I use Ubnt for layer 1 and 2. Their switches are nice if your needs can be met by their spog. Same with their access points although I haven’t see a good one from then since WiFi 5. Their latest WiFi 7 ap is top dollar but used last generation chip and has a cooling fan :[

Dont use unit for routing, though.

Thank you! DNS-based adoption works well for this. You point the unifi hostname at the tenant's subdomain and the Host header handles routing from there. We also have a DHCP Option 43 generator for setups where DNS isn't practical.

It would definitely be simpler, however the routing issue still stands. You would need to have a public IP for every VM, which is getting less practical. The MAC-based proxy makes it so we only need one IP and we can worry about the routing within our platform instead.

but it is http! why can't you do virtual hosting on a reverse proxy?

You definitely can once the device has a hostname set in set-inform. The MAC proxy is just for initial adoption where a device may only know the IP. Such as when you use DHCP Option 43.

You can after the initial discovery step, the article mentions this. The MAC routing is for the first step where the device is reaching out to try and find a controller and signal it's available for adoption, which uses an IP address at least in the scheme that is relevant for hosted operators. After that initial channel is established, the controller uses it to tell the device what its hostname is, and you can switch to more normal HTTP proxy routing thereafter.

Yep, that's exactly right!

Now that would be interesting! Multi-vendor support is on the radar, but haven't started looking into it much yet.

Yep, once you set-inform the host header handles the routing. This in particular is most useful for things like DHCP Option 43, where devices only get an IP.

But if you only got that IP and a MAC-Address - how do you know which tenant is supposed to adopt the device?

We support two approaches, you can either pre-register MAC-Addresses or you can add source IP's to assist with that mapping. There is more information in our docs about this: https://tamarack.cloud/docs/migration

that's the key information to understand the whole thing.

it would be great if that could be in the article in the first place. (I'm assuming you are the author)

Good call, I should have made that more clear. Article updated!

Sorry about that, I typically use light mode, fixed and deployed!

A million times better, thanks =)

Thanks for calling it out!

You might be onto something there! But yes, good catch, I'll get that updated.

This is similar to how I approach things on my todo list as well. If the task is going to take less than five minutes just do it now and be done with it.