Community discussions

MikroTik App
 
marklodge
Member Candidate
Member Candidate
Topic Author
Posts: 250
Joined: Sun Jun 21, 2009 6:15 pm

'Correct' Method of Public IP assignment

Fri Nov 15, 2019 12:30 pm

I have searched through this forum and read the threads regarding public IP assignment, alot of which was replied to by 'Sob'
Even though this has given me a an idea about how to go bout doing it, I still want to know the "industry standard" (if there is) or the most common ways this is usually accomplished.
I have tried a few methods and none really worked very well for me (there was always an obstacle to dual WAN failover etc)

Here is a diagram of what I currently have assigned to me and my routers.

Fig.1 shows my current setup.
Now I requested another IP block and they assigned it to me, they routed it to one of my ips. Please check fig.2 the changes are in red. I have set the IP as shown, but traffic does not go via the new IP. I understand this is because of the Masquerade rule on my router1, am i correct?

What is the 'best' way to distribute the WAN IPs to my clients connected to each of these routers.
And on which interfaces should the WAN IPs be assigned to?
Hopefully this will also clear it up for others in future.
f1.png
f2.png
You do not have the required permissions to view the files attached to this post.
 
Sob
Forum Guru
Forum Guru
Posts: 9121
Joined: Mon Apr 20, 2009 9:11 pm

Re: 'Correct' Method of Public IP assignment

Fri Nov 15, 2019 1:43 pm

The correct (or let's say most usual and compatible) way is to *not* use some of "my" configs. But in a desperate world where IPv4 addresses are scarse, desperate measures are sometimes required. :)

Basic scheme is that you have some connecting subnet between you and ISP and another subnet routed to you (/ip route add dst-address=<routed subnet> gateway=<your address> on ISP's side). You then take one address from routed subnet, assign it to some internal interface, where it will serve as gateway for clients, and you give the rest of addresses to clients connected to this interface. And that's it.

Or you can route it further, e.g. split it in two and route one half to one internal router and second to another. It's still fine, only when you're going to do further routing over private addresses, there will be "holes" in traceroute, and it can have bad effects on icmp messages sent by router, because if they come from private address, they won't reach devices on internet.

Regarding your new subnet, yes, what's currently breaking it is masquerade. You need to limit the traffic to which it applies. Either add some condition to existing rule (e.g. src-address=<internal subnet>) or you can add another rule with action=accept before it and use it to exclude some addresses. And you shouldn't use masquerade at all, better way is srcnat with static address (there's presentation from MikroTik why masquerade is bad, but I can't find the link now).

What's the best config for you depends on what exact requirements you have, how is everything going to be connected. How far (in terms of intermediate routers) from main router will the clients be. If they should have addresses directly, or if you plan to use 1:1 NAT. If they are going to be connected using ethernet/wifi directly, or if you perhaps want to use PPPoE. Etc...
 
marklodge
Member Candidate
Member Candidate
Topic Author
Posts: 250
Joined: Sun Jun 21, 2009 6:15 pm

Re: 'Correct' Method of Public IP assignment

Sun Nov 17, 2019 7:00 am

The correct (or let's say most usual and compatible) way is to *not* use some of "my" configs. But in a desperate world where IPv4 addresses are scarse, desperate measures are sometimes required. :)

Basic scheme is that you have some connecting subnet between you and ISP and another subnet routed to you (/ip route add dst-address=<routed subnet> gateway=<your address> on ISP's side). You then take one address from routed subnet, assign it to some internal interface, where it will serve as gateway for clients, and you give the rest of addresses to clients connected to this interface. And that's it.

Or you can route it further, e.g. split it in two and route one half to one internal router and second to another. It's still fine, only when you're going to do further routing over private addresses, there will be "holes" in traceroute, and it can have bad effects on icmp messages sent by router, because if they come from private address, they won't reach devices on internet.

Regarding your new subnet, yes, what's currently breaking it is masquerade. You need to limit the traffic to which it applies. Either add some condition to existing rule (e.g. src-address=<internal subnet>) or you can add another rule with action=accept before it and use it to exclude some addresses. And you shouldn't use masquerade at all, better way is srcnat with static address (there's presentation from MikroTik why masquerade is bad, but I can't find the link now).

What's the best config for you depends on what exact requirements you have, how is everything going to be connected. How far (in terms of intermediate routers) from main router will the clients be. If they should have addresses directly, or if you plan to use 1:1 NAT. If they are going to be connected using ethernet/wifi directly, or if you perhaps want to use PPPoE. Etc...
1. Thank you for the information. I have implemented src-nat now instead of masq. Do I need to do dst-nat too?
2. Did you mean this presentation: https://mum.mikrotik.com/presentations/ ... 948376.pdf
3. Regarding this:
Basic scheme is that you have some connecting subnet between you and ISP and another subnet routed to you (/ip route add dst-address=<routed subnet> gateway=<your address> on ISP's side). You then take one address from routed subnet, assign it to some internal interface, where it will serve as gateway for clients, and you give the rest of addresses to clients connected to this interface. And that's it.
Can both the IP addresses be on the same interface, as you can see in my diagram, ether1 has been assigned the IP from the routed subnet, and its also the interface which has the IP that the subnet is routed to. Is this fine? Because as you can see, its not going in to the router and coming out from another interface, its going in and out on the same interface.
4. All my clients are connected via PPPOE. I want some of my clients to have a WAN public IP assigned to their CPE (Like when you have a ADSL connection, your public IP is on your adsl modem) How can i do this?
5. I have tried this:
- Router 1 config:
Added IP 109.109.109.33/27 to ether1 (109.109.109.32/27 is routed to 45.45.45.2, also assigned to ether1)
- Router 2 config:
Added IP 109.109.109.34/27 to ether1 (ether 1 of Router 1 and Router 2 are directly connected to each other via Switch) 
ip firewall mangle
add action=mark-routing chain=prerouting new-routing-mark=test passthrough=yes src-address=10.11.1.2 [i](10.11.1.2 is my test pppoe client)[/i]
/ip route
add check-gateway=ping distance=1 gateway=109.109.109.33 routing-mark=test
/ip firewall nat
add action=src-nat chain=srcnat comment=SrcNAT out-interface=ether1 to-addresses=109.109.109.34
But there is something wrong with my config/understanding. Because it does not work, this test client cannot access internet
 
User avatar
jvanhambelgium
Forum Veteran
Forum Veteran
Posts: 991
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: 'Correct' Method of Public IP assignment

Sun Nov 17, 2019 9:28 am

Add this : (see Wikie examples below)
The masquerading will change the source IP address and port of the packets originated from the network automagically. No need to set "src-address"
(masq = special form of src-nat)

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 action=src-nat to-addresses=1.1.1.1 out-interface=Public
add chain=srcnat src-address=192.168.2.0/24 action=src-nat to-addresses=1.1.1.2 out-interface=Public



So add in you rule :

/ip firewall nat
add action=src-nat src-address=10.11.1.0/24 (this is your internal LAN range?) chain=srcnat comment=SrcNAT out-interface=ether1 to-addresses=109.109.109.34

see if this work...
 
Sob
Forum Guru
Forum Guru
Posts: 9121
Joined: Mon Apr 20, 2009 9:11 pm

Re: 'Correct' Method of Public IP assignment  [SOLVED]

Mon Nov 18, 2019 3:17 am

1) If you didn't need dstnat with masquerade, you don't need it with srcnat either. Those things are not really related, each one serves different purpose.
2) That's the one.
3) Yes, two subnets on same interface and routing between them is possible, router doesn't mind. Although in your case you may not want to do it like this, meaning with the /27 mask. If you do that, router now assumes that all other addresses are reachable on that interface, which may not be true.
4) First step is easy, select an address and set it as remote address (i.e. what client gets). And then you just need correct routes, that's what the previous point was about, because if PPPoE client has this address, it's not reachable in router's ether1. You'd have to add proxy ARP for that.
5) It the client should get the address directly, you don't need any NAT. If the second router still has original 45.45.45.3, you need to route the address there (/ip route add dst-address=109.109.109.34 gateway=45.45.45.3). PPPoE server on second router will assign 109.109.109.34 to client.
So packet from internet to 109.109.109.34 will first go to your ISP, it will route it to your first router, from there it will be routed to second router and it will route it to client. Packet from 109.109.109.34 (from client's device) to internet will go to PPPoE server on second router and it will send it directly to ISP, which I assume will work. If not, you'd have to route it through first router, but it probably won't be necessary.
If you'd want to use 109.109.109.x address with NAT, you again need to route it from first router to another, and there you can assign it to either some loopback interface (in RouterOS usually done with empty bridge) or to ether1, it doesn't really matter. But you'd use /32 mask for the same reason given in 3).

What you may not like about this is that other routers still depend on first one. But if ISP routes this subnet to first one, it will simply go there. You could intead ask ISP to split /27 into four /29s and route each to different router. But it depends on what exactly you want to do with those addresses, if having /29 for each router would suit you. Another way would be to give 45.45.45.6 to RB3011 (if you really have four routers in /29, it should be free) and tell ISP to route the /27 there. And you could then route individual addresses to whatever router you'd need.
 
marklodge
Member Candidate
Member Candidate
Topic Author
Posts: 250
Joined: Sun Jun 21, 2009 6:15 pm

Re: 'Correct' Method of Public IP assignment

Sun Nov 24, 2019 1:50 am

1) If you didn't need dstnat with masquerade, you don't need it with srcnat either. Those things are not really related, each one serves different purpose.
2) That's the one.
3) Yes, two subnets on same interface and routing between them is possible, router doesn't mind. Although in your case you may not want to do it like this, meaning with the /27 mask. If you do that, router now assumes that all other addresses are reachable on that interface, which may not be true.
4) First step is easy, select an address and set it as remote address (i.e. what client gets). And then you just need correct routes, that's what the previous point was about, because if PPPoE client has this address, it's not reachable in router's ether1. You'd have to add proxy ARP for that.
5) It the client should get the address directly, you don't need any NAT. If the second router still has original 45.45.45.3, you need to route the address there (/ip route add dst-address=109.109.109.34 gateway=45.45.45.3). PPPoE server on second router will assign 109.109.109.34 to client.
So packet from internet to 109.109.109.34 will first go to your ISP, it will route it to your first router, from there it will be routed to second router and it will route it to client. Packet from 109.109.109.34 (from client's device) to internet will go to PPPoE server on second router and it will send it directly to ISP, which I assume will work. If not, you'd have to route it through first router, but it probably won't be necessary.
If you'd want to use 109.109.109.x address with NAT, you again need to route it from first router to another, and there you can assign it to either some loopback interface (in RouterOS usually done with empty bridge) or to ether1, it doesn't really matter. But you'd use /32 mask for the same reason given in 3).

What you may not like about this is that other routers still depend on first one. But if ISP routes this subnet to first one, it will simply go there. You could intead ask ISP to split /27 into four /29s and route each to different router. But it depends on what exactly you want to do with those addresses, if having /29 for each router would suit you. Another way would be to give 45.45.45.6 to RB3011 (if you really have four routers in /29, it should be free) and tell ISP to route the /27 there. And you could then route individual addresses to whatever router you'd need.
Firstly, a huge thank you for the detailed reply and clarification on the points.

Regarding point 5:

I did the following:
Router1:
/ip route
add distance=1 dst-address=109.109.109.34/32 gateway=45.45.45.3
Router2:
Added address to PPP Secret 109.109.109.34
/ppp secret
add name=test password=test profile=PPPoE-Profile remote-address=109.109.109.34
At this stage, IP 109.109.109.34 is reachable from the Internet, so if I go to https://www.ipaddressguide.com/ping and ping it responds.


The ip 109.109.109.34 is active on the pppoe connection.
/ppp active print
60   test           pppoe   00:04:00:00:00:85 109.109.109.34   21m36s 
The problem is this:


Scenario 1

On Router2;
if I make the route this:
/ip route
add check-gateway=ping distance=1 gateway=45.45.45.1
Then, when browsing from the test PPPOE connection I check my IP via www.whatismyip.com it shows my IP as 45.45.45.3


Scenario 2

On Router2;
if I make the route this:
/ip route
add check-gateway=ping distance=1 gateway=45.45.45.2
Then, when browsing from the test PPPOE connection I check my IP via www.whatismyip.com it shows my IP as 45.45.45.2

There are no NAT rules active.
So, what should be the default route?
 
Sob
Forum Guru
Forum Guru
Posts: 9121
Joined: Mon Apr 20, 2009 9:11 pm

Re: 'Correct' Method of Public IP assignment

Sun Nov 24, 2019 5:56 pm

Default gateway on your CCRs should be 45.45.45.1. And PPPoE client will have whatever is PPPoE server's local address (this part clearly works, if it can access internet).

But I'm not sure if I believe you about no NAT rules. Maybe you didn't add no new NAT rules, but what about original masquerades? Because if client sends packets from own public address and something on the way changes source to another public address, it sure does look like work of NAT.
 
marklodge
Member Candidate
Member Candidate
Topic Author
Posts: 250
Joined: Sun Jun 21, 2009 6:15 pm

Re: 'Correct' Method of Public IP assignment

Tue Nov 26, 2019 1:13 am

Default gateway on your CCRs should be 45.45.45.1. And PPPoE client will have whatever is PPPoE server's local address (this part clearly works, if it can access internet).

But I'm not sure if I believe you about no NAT rules. Maybe you didn't add no new NAT rules, but what about original masquerades? Because if client sends packets from own public address and something on the way changes source to another public address, it sure does look like work of NAT.
I will export configs and post.
Beginner question: Is NAT required at all for my setup?
I first moved from masquarade nat to src nat, that works
Now I disabled the NAT rules completely, and it still works. is this how it supposed to be?
 
Sob
Forum Guru
Forum Guru
Posts: 9121
Joined: Mon Apr 20, 2009 9:11 pm

Re: 'Correct' Method of Public IP assignment

Tue Nov 26, 2019 7:03 am

That's how it works with public addresses, you don't need any NAT. Nice, isn't it? :) Of course if you'll also connect some private subnets to your routers, you will need NAT for them. But it's important to use it selectively only for those subnets, and don't let it interfere with other public addresses that don't need it.
 
marklodge
Member Candidate
Member Candidate
Topic Author
Posts: 250
Joined: Sun Jun 21, 2009 6:15 pm

Re: 'Correct' Method of Public IP assignment

Tue Nov 26, 2019 11:26 pm

That's how it works with public addresses, you don't need any NAT. Nice, isn't it? :) Of course if you'll also connect some private subnets to your routers, you will need NAT for them. But it's important to use it selectively only for those subnets, and don't let it interfere with other public addresses that don't need it.
1. You are correct, there was a Masquerade NAT rule with interface=all on Router2. I removed it.
2. Regarding default route, if I make it 45.45.45.1 then it does not work. But if I make it 45.45.45.2 then it works! Is this right, or is there something wrong?
3. Maybe off topic, but I have a /27 subnet routed to my IP 45.45.45.2 which belongs to ISP1. Now I have another Public IP with ISP2, I need more addresses there, can I route this subnet to a different ISP and use them there?

Again, thank you, you are very helpful.
 
Sob
Forum Guru
Forum Guru
Posts: 9121
Joined: Mon Apr 20, 2009 9:11 pm

Re: 'Correct' Method of Public IP assignment

Thu Nov 28, 2019 4:18 am

I assumed that 45.45.45.0/29 was for you and ISP would accept traffic from the other subnet from all routers, because why not. If not, then you have to route it back via 45.45.45.2. But you don't want to use it as default gateway for everything, traffic from 45.45.45.3 can go directly to 45.45.45.1. You can do this:
/ip route
add dst-address=0.0.0.0/0 gateway=45.45.45.2 routing-mark=othersubnet
/ip route rule
add action=lookup src-address=109.109.109.32/27 table=othersubnet
This will work for public addresses used directly by clients. If you'd use some with NAT, you'd need either other routing rule(s) for source subnets(s), or you could use mangle rules to mark routing, if you'd like to have things more dynamic (e.g. some internal addresses could use one ISP and other another).

Diffent public subnet from another ISP is possible too, with similar approach, the key is to tell router what should go where. Another thing you may want to look into is VRF, it should have similar functionality, but I didn't get a hang of it myself yet, so I won't tell you details.

Who is online

Users browsing this forum: No registered users and 17 guests