Public IP Addresses on WISP Network

RouterOS General
1

I know that this topic has come up before in these forums and I have found some posts regarding it. But, I know that certain specific things in a network may have a bearing on how using public IP addresses for clients is done.

I have a lot of experience with RF (over 40 years), but some experience with networking, but not a lot. And my experience with building a wireless network on which to sell service is less. So, don’t laugh when you see what I’ve done so far. :slight_smile:

All routers and switches are MikroTik. The radio equipment is Mimosa. The Mimosa equipment operates in a bridge mode.

Here’s how I currently have the network set up:

Internet → Main Router/Firewall → Backhaul Network (Mimosa PtP network).

Off of the PtP Backhaul Network, I have routers at each tower location like this:

Backhaul Network → Site Router → Access Point

So the WAN port of each Site Router is connected to the Backhaul Network and the LAN port of each Site Router is connected to one or more Access Points.

I am using static IP addresses on everything.

The problem that I see with how my network is currently configured is that I’m actually using NAT three times.

Internet → Main Router → Site Router → Client Router

I want to continue to use static IP addresses for all local IPs.

Currently, I’m using the Site Routers to set bandwidth limiting for customers and I’d like to maintain this, if possible.

Have I explained this configuration well enough? Or do I need to upload a diagram of what I’ve done so far?

I’ve thought about using VLANS or even VPN tunnels to get public IP addresses ‘attached’ to some of my clients routers. But I’m not sure that either one of those is a good idea.

So, please educate me on this subject.

John

2

Why so many NATs? The last one on client router is clear. Another could possibly be on your router if you’d be using NAT 1:1 for public addresses. But third one?

3

My idea was to have three ‘private’ networks: Backhaul, Tower/AP, Client.

John

4

If “private” means “isolated” or “protected”, it’s what firewall is for, not NAT. I’m actually starting to doubt that I understand your current setup. Based on original description I thought that you have NAT on main router, after that are site routers, all with NAT again, and finally client routers. But if you did anything with public addresses for individual clients, even if it was only 1:1 NAT, you’d already have distinct private subnets behind site routers, wouldn’t you? And extra NAT wouldn’t make sense.

5

You were correct. There is one main router/firewall (with NAT), multiple site routers/firewalls (with NAT), and then client routers/firewalls (with NAT).

I can see now that this was a bad idea, at least for this type of network.

As I’ve been thinking about this, I can see that I don’t need the main router/firewall at all. This reduces the network to site routers/firewalls and client routers/firewalls.

My backhaul network can feed multiple public IP addresses to the site routers since the backhaul network is bridged.

I can then set up the site routers with multiple public IP addresses on their WAN ports and then with proper configuration in the site routers, each client can have their own public IP address.

Does this sound like it might work?

John

6

Well… many WISPs have found out over time that just a few end customers want public IPv4 addresses while most don’t care. As public IP addresses are a scarce resource, using a /30 subnet to deliver a single public IP address to a client costs you 4 public IP addresses in total which is a bad deal. Even use of /31 subnets (which Mikrotik only supports in their specific way) is still a bad deal. So the most popular solution is to use PPPoE between the client and your core routers, as for PPP links it doesn’t matter whether IP addresses of the link ends are from the same subnet (or whether they have any IP address assigned at all) and as PPPoE provides authentication of the client by means independent of their MAC address. So using PPP links, you can assign each client a private or public address individually, and if they need a range of either, you can use the PPPoE link as transport and route the range through it.

7

Hey, I was already writing! :slight_smile: But since I already finished it:

If you now have all public addresses on main router (I’m guessing), moving them to site routers would be going only half way and nothing would change from client’s perspective. As a client, I want to have public address directly on my router, because it makes a difference for some applications (IPSec from top of my head).

You can route public addresses directly to clients, the only question is how to make the last link. You could route them to their existing private addresses, but it’s not something that could be easily configured with every simple router. Or you could add smaller public subnets to site routers and let clients with public addresses connect to those. But that would inevitably waste some addresses, at least three on your side for network, gateway and broadcast. And who has IPv4 addresses today to waste, right? Or you could use PPPoE, it’s standard supported by pretty much everything and needs only individual addresses, so none are wasted.

8

Pretty obvious that I need to be using PPPoe.

I’ve found a good article on setting up PPPoe, both server side and client. It actually looks pretty simple to set up.

What the article doesn’t address is how this can work (or not) where there are multiple NATs involved.

So, if I have the client router, then a tower router, and then a main router, would that work where the main router was the PPPoe server?
Or, would I set up the tower routers as PPPoe servers?

Or is there a better way to set up the network itself, maybe not even using the tower routers?

To me, right now, it sounds like the PPPoe part is the easy part to set up (or at least, the easy part to understand) and how to configure the actual network is the part that I don’t have enough knowledge of, in order to set it up for the most ‘efficiency’, etc.

John

9

I hope I gave @Sob enough time to react this time :slight_smile:

PPPoE needs L2 transparency between the client and the server, so the very notion of NAT doesn’t exist there - it’s PPPoEthernet, not the basic PPP(oIP). So you cannot have routing between PPPoE client and server, only switching/bridging.

10

It depends on where PPPoE server would be, if on site routers (from where there’s direct link to clients), it would be ok. You’d only need to exclude public addresses from srcnat. But I don’t know what you use for management, if you configure stuff manually, or if you have some system that would need to support this topology.

11

This is the kind of help that I was hoping to get. Thanks to both of you.

No management system at this point. Everything is done manually, which can continue for a little while. We’re not building out fast (yet).

So,it sounds like setting up each site router as a PPPoe server would work. And if I eliminated the ‘main router’, then everything would be bridged/switched between my fiber feed and the site routers.

I’ve noticed that information regarding PPPoe that I’ve found so far tends to indicate that IP addresses would be handed out dynamically. But, I want everything static. Can I assume (corretly) that this is possible?

John

12

There is still the same caveat of routing which uses prefixes. Imagine two “site routers”. If the PPPoE server is at each router, either all the clients with public IPs will have to get addresses from a single subnet (with the same prefix) and your routing tables will be more or less brief (one route to a public prefix and one route to a private prefix per each site router), or you’ll have to tell each router connecting you to your own internet provider(s) how to contact every single public IP in your network, so the routing tables will explode as you will have one route per each address assigned to a client.

Also, I’m not sure how you’re going to squeeze out a “main” router completely, as your uplink(s) to ISP(s) must be somewhere, unless you’ll have one uplink to other ISP per each site router (which doesn’t seem to be the case as you talk about L2 network interconnecting them). So I assume some of your site routers may simultaneuosly play the rule of providing internet access for the rest of your network.

Also, public IPs in your network and having multiple ISPs usually requires that the block of public IP addresses you use is yours, not one of your ISPs’, and that you run your own AS to inform the world dynamically about how to reach those IPs.


Assuming we talk about Mikrotik as PPPoE server, when you define the username and login under /ppp secret, you can specify the client’s address statically, or refer to an /ip pool from which it will be chosen dynamically, or just refer to a /ppp profile which refers to an /ip pool. It’s quite a complex hierarchy of defaults on one level which can be overridden by settings of the same parameter at a deeper (closer to individual client) level, but if you want everything static, you don’t need to dive deep into it. And you can also use RADIUS to let your PPPoE server authenticate users and get the IP addresses for them using an external server.

Or, from another perspective - the address can be administratively assigned and delivered to the client device’s configuration using offline means, or it can be administratively assigned and configured at server side and delivered from there to the client online, by some means of dynamic host configuration (in your case, PPPoE, in other cases DHCP). I assume you won’t protest against the latter approach.