My ISP connection (draytek router) has a single public ip address on pppoe/wan side.
I have replaced the router with a hex-s and all is running fine.
Now it offers a /29 public ip pool transparently available on lan side for customer needs.
How to configure this on MikroTik machine ?
What you can do depends on how exactly the ISP provides those addresses (as 8 PPPoE accounts or as a subnet routed to you via the same PPPoE tunnel, and in the latter case, whether the address allocated using PPPoE is within that /29 or outside).
It is your decision whether you want to delegate the public IPs directly to the LAN device(s) or to use some dst-nat (port forwarding/1:1 nat) rules. There are at least three ways how to delegate them, but some devices may not support all of these ways.
I don’t want to sound like @anav with the answer, but you didn’t even list a prerequisite or how the IPs are provided.
Since NO ONE here in the forum is a fortune teller,
but EVERYONE doesn’t answer you exactly as you want or expect, BUT first they want to know why they should spend time for you…
I tell you that 1 IP is more than enough in most cases, you just need to open the port of the service you want to put on the internet, instead of foolishly giving public IPs within the network.
Obviously without the prerequisites (why on earth should a machine have a public IP directly) it is difficult to understand the reason for things.
Thanks,
Rextended, as per your location, it is the classic /29 subnet TIM or other ISPs (Retelit this case) delivers over your existing connection (hope this helps)
where (i.e.) in a aaa.bbb.ccc.104/29 network, aaa.bbb.ccc.105 is assigned to your router and 106-110 are the usable adresses.
la configurazione è tipo:
pppoe 185.21.12.79
185.62.62.104 sprecato
mikrotik brdge 185.62.62.105/29
NIC server1 185.62.62.106 / 255.255.255.248 / Gateway 185.62.62.105
NIC server2 185.62.62.107 / 255.255.255.248 / Gateway 185.62.62.105
NIC server3 185.62.62.108 / 255.255.255.248 / Gateway 185.62.62.105
NIC server4 185.62.62.109 / 255.255.255.248 / Gateway 185.62.62.105
NIC server5 185.62.62.110 / 255.255.255.248 / Gateway 185.62.62.105
185.62.62.111 sprecato
senza toccare il resto, tipo le VLAN, ovviamente va poi considerato il FIREWALL… eccetera.
Grazie,
I reply in english just to keep discussion useful for others:
Now I got it working with
/interface pppoe-client
add comment=Retelit interface=ether1 keepalive-timeout=60 name=pppoe-out1 password=mypassword profile=PPPoE_Profile1 service-name=Retelit user=myuser
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-out1
How should I manage the bridge ?
Should I include pppoe interface AND lan interfaces (eth) as ports of same bridge and assign to bridge the first useful ip address of public pool (185.62.62.105/29 in your example) ??
Of course with this basic configuration, HEX-S purpose is just to be the router for make public ip addresses available to firewalls and aventual other internet-exposed machine.
mikrotik default = bridge port 2..5
no default = no birdge…
mikrotik default = firewall OK if pppoe-out1 is added to WAN interface list
no default = NO firewall…
The bridge is internal between ether2…ether5 (+ sfp1)
pppoe-out1 (or ether1) never go on any bridge
Sorry, I’m missing a part :
This routerboard has to be just a bridge to carry public ip pool to ethernet(s) devices (i.e. a firewall) .
pppoe is working on eth1
eth2 to eth5 are bridged together, I assign bridge the first useful /29 address
I missed HOW these two different things are connected together to made pool transparent from internet .
Answering to Sindy, /29 subnet is routed (I suppose) over pppoe connection and /29 pool addresses are completely different from pppoe one.
Okay. So the RB will not be (strictly speaking) a bridge but a router. The ISP will send packets for any address from the /29, including the .0 and .7, to the RB, and the RB may
- attach the whole /29 to its bridge interface, wasting 3 of the total 8 addresses for its own address, the network address, and the broadcast one. The LAN hosts will use the IP address of the RB in that /29 as their gateway
- assign all 8 of them to other devices via PPPoE again (itself acting as a PPPoE server)
- assign each of them to another LAN device as a /32 one, attaching some private IP address to the same interface and indicate it as a gateway to the LAN devices (all this can be done using DHCP or configured manually). Some devices may be unable to handle this, but you probably don’t want to assign a public address to that kind of devices anyway.
This one !
It’s the way local ISPs here usually deliver public ip addresses.
Just wondering how to accomplish with RB devices once internet connection (pppoe in this case) is established.
Well, the fact that the ISP wastes three public addresses in order to deliver five actually usable ones to you does not imply that you have to do the same 
But I understand you want a drop-in replacement of the original router by the hEX S so that the configuration of the existing LAN hosts using those public addresses could remain unchanged.
There is no magic about public addresses, the router itself handles private and public addresses exactly the same unless you tell it otherwise. So assuming that you start from a default configuration of the hEX S, do exactly what you yourself wrote in response to @rextended - replace the default IP address associated to the bridge interface, 192.168.88.1/24, by aaa.bbb.ccc.105/29, and if DHCP needs to be used, modify accordingly the corresponding items in /ip pool and /ip dhcp-server network. If DHCP is not to be used, disable the server associated to bridge. Then, disable or remove the action=masquerade rule in chain srcnat of /ip firewall filter, so that outgoing connections from the LAN hosts on public addresses would not get src-nated. To provide access to the LAN hosts from the internet, add the necessary action=accept rules to proper position within chain forward of /ip firewall filter. Depending on the kind of the connected LN hosts, it may or may not be fine to allow everything in firewall filter - your knowledge and understanding is critical here.
Sounds like OP has made known his preference already, but we would be remiss if we did not mention a 4th popular option that also allows for all 8 addresses to be useful:
- Continue using private addressing for all devices on “LAN-side”, and then add individual 1-to-1 NAT rules, one set per public IP that you want to give exclusive use of to a given LAN host.
You would want 2 rules per IP/host: one dst-nat for unsolicited inbound traffic to a given public IP, and one src-nat for any traffic sourced by that LAN host that isn’t in response to an outside request.
My fault not to specify what NathanA wrote… and what is “tricky” for me , as I never done it with MT machines (many times with fritz, cisco etc).
The goal is to add the public pool while the private lan address is natted over pppoe.
So I suppose I have to add a secondary ip address to bridge (the first useful /29 one to be used as gateway for /29 machines) and since each /29 address/machine has to be reached from internet and at same time each /29 machine must face internet with its own public address, a set of src/dst-nat rules has to be configured (that’s my unknowledged part), and then one per host or a global one ?
Of course each of 5 available /29 addresses will be assigned statically to machines.
It’s either-or:
- either you want the LAN hosts to have the public addresses on themselves, and in such case you need to attach one of the public addresses to the router (as a secondary one to a common bridge or VLAN or as the only one on a dedicated bridge or VLAN)
- or you want the LAN hosts to have private addresses on themselves, and in such case you do not need to attach any address from the /29 to any of the router’s interfaces, and just rules in dstnat and srcnat chains will be sufficient. If you choose the private addresses the right way, you can use a single action=netmap rule in the srcnat chain to replace the private prefix by the public one, keeping the least significant 3 bits unchanged. You can even use a single action=netmap rule in the dstnat chain if it makes more sense to you than port-by-port dst-nat rules.
The latter approach allows you to use also the 0, 1, and 7 addresses for LAN hosts.
The first, just to make it easy :
pppoe single ip address + 1:1 nat to a firewall , any other eventual LAN device attached to HEX eth, obtain a 192.168.1.x address , facing outside with pppoe public address.
Now for various reasons, one needs multiple public ip addresses, ISP says “ok new pool available” without touching nothing about pppoe connection:
(this is how ISPs here manage public ip addresses pools on their own routers )
Now what I need is the right set of nat rules after setting the first useful adress of the pool as secondary on the bridge (as I will replace ISP router or I could buy a line without router from ISP).
No NAT (Network Address Translation) rules are necessary because you will not be translating any address. The destination address of the packet for 185.62.62.107 will be 185.62.62.107 already as it comes in via the PPPoE, and the router will find out that it has to send an ARP request for 185.62.62.107 from the bridge because 185.62.62.105/29 is attached to the bridge, and it will forward the packet for 185.62.62.107 to the MAC address that will come in the ARP response.
What you may want to set up, though, are filter rules if the LAN host with address 185.62.62.107 does not have its own firewall.
Got it !
Is it the same for outgoing packets from 185.62.62.107 to internet via 185.62.62.105 → pppoe ?
Or do I setup something to preserve .107 source ?
You have to make sure that the src-nat or masquerade rule that handles outoing connections from the LAN hosts that use private addresses will not act on the outgoing connections from the LAN hosts that use public addresses. So let that rule match on src-address=192.168.1.0/24 or on src-address=!185.62.62.104/29 (please note the exclamation mark).
I think you intended to communicate this, but just to be clear: it is possible to selectively NAT traffic sitting behind any given interface, which means you can in fact have both hosts with public IPs and hosts with private IPs sitting on the same LAN/network segment, mingling together. As you mentioned in the last reply, you just have to make sure that you craft your NAT rules appropriately, so that they only match the traffic you intend for them to match.
One potential downside (or at least “weird quirk”) to such an approach would be that if any host with a private address wanted to talk to any host with a public address, they would both have to hairpin their traffic through the router to do so, since the only path they would have knowledge of that they could take to reach the other party would be via their default gateway. If this is going to be a common occurrence, and depending on which router model you have and how performant you want the communication between your LAN hosts on the different subnets to be, you might actually be better off giving all LAN hosts private addresses, and dst-natting the public IPs to the hosts that you want to respond to those publics.
It works like a charm !
/interface bridge
add name=bridge1 protocol-mode=none
/interface vlan
add interface=ether1 name=VLAN875 vlan-id=875
/interface pppoe-client
add add-default-route=yes disabled=no interface=VLAN875 name=pppoe-out1 service-name=MyISP user=myusername password=mypassword
/interface bridge port
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
/ip address
add address=192.168.1.1/24 interface=bridge1 network=192.168.1.0
add address=22.33.44.145/29 interface=bridge1 network=22.33.44.144
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-out1 src-address=192.168.1.0/24
No magic indeed, pppoe transports the pool and rb knows where to route packets, my concern was about pool routing over pppoe , but it’s all “automatic”…
Last rule, as suggested, prevents masquerade when src-address is different from lan one.
Easier than supposed…
Also, what amazed me , is adding fasttrack rule has increased download speed from 350Mbps to 960Mbps ! (where the limit is the NIC speed, being FTTH rated 2.5Gbps), but this is another story…