I have a special ISP that provides me two addresses in the same subnet: 10.x.x.11 and 10.x.x.12. Those addresses depend on MAC address of a DHCP client. The 10.x.x.11 address goes to static public IP address 18x.x.x.x48 and whatever connects from the internet to 18x.x.x.x48, it ends up on the 10.x.x.11. It provides me effectively my own public static IP address and then I have some rules in my router that says "port A goes to internal host A port X, port B goes to internal host B port Y, etc… (using firewall - nat … dst-nat). This works well since ages, several years (over a decade, maybe two). I just upgraded MT several times and always copied the configuration, so there is some old routeros mess which I want to clean now using new routeros 7.x (7.11+).
Then I have another router (not MT) with the MAC address that gets an IP address 10.x.x.12 on its WAN port from the same ISP. This address goes to shared NAT public address like 18x.x.x.x41 which “hides” me and lots of another ISPs clients that does not have public IP address. This configuration is pretty straightforward and I would be able to do this with routeros as well - it’s in fact like default configuration without the need of setting anything.
The “mess” starts with the fact that all hosts in my LAN can use either the non-MT router as a default gateway, or the MT as another default GW (the two routers are also connected at the LAN side and MT has and IP address from the LAN subnet and acts as the second gateway). The non-MT router acts like DHCP server for all hosts and based on MAC address it gives them their correct IP addres from the LAN subnet and most importantly their default gateway. There are several exceptions (usualy virtual servers) that gets the MTs LAN IP as a gateway, since they are those “dst-nated” and needs to reply back through the static public IP address. For other hosts the non-MT router gives them its own LAN IP as a gateway and the traffic then goes through the ISPs shared public NAT address. The idea is: what should be reachable directly from the internet, goes through the public IP 18x.x.x.x48 and what should NOT be reachable directly from the internet, goes through the shared NAT address 18x.x.x.x41. Right now it works as expected - with two routers - one MT and one non-MT.
Now to the “problem”: I need all of this to be done by MT and remove the non-MT router completely. Right now there is a bridge on the MT whose one port goes to ISPs router and other goes to my non-MT routers WAN port. And I don’t know how to tell the MT to get two IP addresses from one single cable going from ISP - then make two group of hosts based on their MAC addresses, where most of them will goes to the ISPs side gateway 10.x.x.12 (NAT) and several exceptions (based on MAC address) will go to the internet through the 10.x.x.11 gateway (static public IP address). I’d like to give all hosts their “static DHCP-based” IP addresses from LAN subnet.
Whether it will be done by two LAN subnets (with the necessity to communicate from subnet A to subnet B and vice versa), or one subnet only, doesn’t matter for me. The actual configuration is not really important since I’d like to start from scratch (like with a new router (RB750GR3 with latest RouterOS), also the LAN can be completely readdressed, which I plan anyway). I can make the dst-nat rules for those hosts going through 10.x.x.11 on my own then (I hope it will work the same as now, there are 11 of them).
And I don’t know how to tell the MT to get two IP addresses from one single cable going from ISP
This was difficult, as you need 2 MAC addresses for the ISP.
Playing with VRRP was a trick to get a second MAC address on an interface. (Or use 2 ethernet interfaces, as MT suggests)
But now MACVLAN may be helpfull. https://help.mikrotik.com/docs/display/ROS/MACVLAN
OK, back after a while… MACVLAN really did help and it’s ridiculously simple.
What I’m now looking for is a solution to this scenario:
I have two IP addresses from my ISP, like 10.3.33.11 and 10.3.33.12 (one on ether1 and the other on macvlan1). They are both from the same subnet, but both behave differently on the ISPs side. 10.3.33.11 goes up on a static public IP address, which means: whoever tries to communicate to the internet from the LAN, acts like that public ip address and whoevere tries to communicate with that public IP address ends up at the Mikrotik at 10.3.33.11.
The second one (10.3.33.12) goes up on similar (different) public IP address, but that address is shared among more clients.
Since I don’t know how to do it and since my configuration had some mess from older routeros than 6.x, I reset my Mikrotik to default configuration (routeros is now 7.18.1), added the macvlan1 interface with its specific MAC address and changed the configuration so this macvlan1 is WAN instead of default ether1. With such configuration everything works perfectly - DHCP server on Mikrotik gets 10.3.33.12 using macvlan1 and local LAN clients can use the internet through ISPs public IP addres shared among other IPSs clients. For now the ether1 port itself is just not used - only the macvlan1 (mounted at the ether1).
Then I want to use the ether1 port with it’s address 10.3.33.11 (obtainable by second DHCP-client configuration, now disabled) as a default “way” for just several IP addresses from the LAN (let’s call them “special address list”). Those are like web server (TCP 80 and 443) and another server using different port, for example RDP 3389 (it’s just example, don’t bother about security now). And some other servers with their services on some defined ports.
So I need some mechanism that will send all clients to the public shared IP through 10.3.33.12 (which is now working configuration) and only IP addresses in the “special address list” to the static public IP address through 10.3.33.11. The thing is - those addresses in special addres list are web server (on TCP 80 and 443) and there are some other servers providing it’s services at their special ports. So there has to be anothe mechanism that will send whatever comes to 10.3.33.11 from an ISP to the corresponding servers on LAN.
The example is:
/ip firewall filter add action=dst-nat chain=dstnat comment=“Web server” dst-port=80 in-interface=ether1 protocol=tcp to-addresses=192.168.1.10 to-ports=80
/ip firewall filter add action=dst-nat chain=dstnat comment=“Another server” dst-port=1234 in-interface=ether1 protocol=tcp to-addresses=192.168.1.15 to-ports=5678
That was my previous working configuration where the router used only one IP address from my provider (the static public using 10.3.33.11). But when two IPSs addresses from one subnet come into the game everythink tends to not work at all and I don’t know where it all collides.
First, you can just functionally replicate your previous setup (Mikrotik and the other router) by engaging the VRF functionality of the Mikrotik and using a macvlan interface also on the LAN side. So like before, each device in the LAN subnet would get a distinct default gateway IP depending on which WAN it should use. The LAN interface (the bridge or the macvlan attached to it) and the corresponding WAN interface (ether1 or the macvlan attached to it) would both be assigned to the same VRF, and in that VRF, the default route would go through the proper WAN interface and gateway address.
If the above is not enough and you want more flexibility, e.g. that the servers that are targets of the dst-nat from the dedicated public address would respond through that address to incoming connection requests that arrive to that address from the internet but their own outgoing connections would use the shared one, you would use policy routing instead. Policy routing means that other attributes of a packet than its destination address are used to route it, and in detail that means that you set up more than one routing table and use routing rules and/or firewall mangle rules to tell the routing to use a particular routing table to route packets whose “other attributes” conform to the match conditions of those rules. One possibility is to match on source port, another possibility is to match on a connection-mark value that gets assigned to the whole connection when handling the initial request.
Whether you actually need it to be that complicated depends on whether 10.3.33.11 and 10.3.33.12 use the same default gateway and whether the ISP checks the match between the source MAC address and the source IP address in the packets you send. For the same gateway and no check, you don’t need to do anything to make the responses from the servers use the same address (10.3.33.11) to which the requests have arrived because the connection tracking will take care of un-dst-nating them. But if the gateway at the ISP side is different or if the ISP checks the MAC to IP address correspondence, you need to force the response packet through the correct interface (ether1 or the macvlan one attached to it) so that it would get the proper MAC address as source, hence you need a dedicated routing table with a dedicated route and the routing or mangle rules that choose it.
@WIFT
Could you possible show your working config curious to see macvlan in action.
/export file=anynameyouwish ( minus router serial number, any public WANIP information, keys and any wan mac addressess LOL )
/ip fi na add action=src-nat chain=srcnat src-address=192.168.1.0/25 to-addresses=10.3.33.11
/ip fi na add action=src-nat chain=srcnat src-address=192.168.1.128/25 to-addresses=10.3.33.12
Hmm interesting I recently read this at MT Docs, but assume it doesn’t affect your solution…
“The preferred source is not used anymore for connected routes. FIB chooses the source address based on the out-interface. This allows making setups that in ROS v6 and older were considered invalid. See examples for more details.”
If you enable the second DHCP client temporarily, do both the default routes added dynamically via DHCP have the same IP address as the gateway?
Anyway, as you haven’t added a dedicated routing table, neither by creating a VRF (which needs a name of a routing table) nor manually, all the traffic would use the ISP-macvlan1 as the gateway interface even if you enabled the now disabled DHCP client attached to ISP-ether1. So your action=masquerade rule that matches on out-interface=ISP-macvlan1 sets the reply-dst-address to the IP address assigned via DHCP to ISP-macvlan1, but that rule only acts for outgoing connections initiated by hosts that are not on the pubwans address list. The other rule does not act at all because currently, ISP-ether1 is never the out-interface so outgoing connections from hosts on the pubwans address list are not src-nated at all.
So if your ISP does not check that the source IP address matches to the source MAC address, and if the addresses they assign you via DHCP never change, you can just change the rules in the srcnat chain from action=masquerade (which use the address associated to the out-interface as the reply-dst-address) to action=src-nat to-addresses=10.3.33.x (where you explicitly specify the reply-dst-address to be used for that connection) and let them both match on out-interface-list=WAN-pub; the one matching on src-address-list=pubwans would assign one reply-dst-address and the one matching on src-address-list="pubwans would assign the other one.
So I’d suggest that you try this first, as it is a relatively small change yet it may be sufficient. If it is not, because either the addresses change or the ISP checks the match between source MAC address and source IP address, we can implement the more complicated approach with an additional routing table and either a full VRF approach or just a policy routing within the “default routing instance”.
What surprises me is an absence of any dst-nat rules, you said the goal of the whole exercise was to make some servers in your LAN accessible from the outside via the dedicated public IP? What am I missing?
They were there before resetting the router to factory default. There was several dstnats that I saved for later. First I’d like to make it work the way that the pubwan addresses wil act like the one dedicated static public IP address and other will use the shared one. Then I’m going to add the dstnat rules back and see if it will work.
An here goes something that I don’t understand. When I just enable the second DHCP client on ether1, “the internet stops working correctly” - LAN PCs are not able to browse the internet in a reasonable manner. When I traceroute from my laptop (not on a pubwan address list) to some internet address, I end up on mikrotik as the only hop that responds (192.168.xx.1), but traceroute to the same address from the mikrotik itself works well. Also traceroute from a PC on pubwan address list does the traceroute, but when I try to go to infosniper.net, the page loads half and stuck - after a while it completes loading and shows the static public IP address. infosniper.net on my laptop (not on a pubwan address) also behaves stucky and then shows the shared public addres (which is correct).
It just behave “randomly”, as if the router tries both ways to the gateway in a random fashion. When I disable the ether1 DHCP, all PCs NOT on a pubwan address list goes to the internet without problem and the PC on a pubwan address list is completely without the internet.
Sniffing on WAN would tell you more about what actually happens, but now as I look at your screenshots again, it seems to me that something is rotten in routing - in RouterOS, not in your configuration. While the default route with distance=5 is marked as active and the default route with distance=10 as inactive (which is correct), the + signs in the leftmost column should be there for both routes to 10.x.x.0/24 (because indeed this subnet is reachable through both your WAN interfaces) whereas the + sign should not be there for the default route with distance=5 as there is no other route with same dst-address and distance in the same routing table.
What happens if you set add-default-route on the DHCP client attached to the macvlan interface to no and change the rules in srcnat the way I have suggested above (you can add my rules after your ones and then disable your ones so that you could return to them easily by first enabling them and then disabling mine).
What is happening is correct, which is why I wrote that macvlan is unnecessary. For this configuration, policy routing would be required. It will be simpler to give up on macvlan, use DHCP to get one address, and set the second manually.
Now the PC on pubwan list goes to the internet through static dedicated public IP address and others go through the shared one. I just had to hope that my ISP will not change “its own 10.x…” addresses. It did not happen for several (tens? of) years now, so let’s hope it will stay intact. My ISP probably (i think so) has hard-set reservations since he wants to know our MAC addresses (especially when we change our hardware). It’s kinda small ISP, not any big one. We even don’t have monthly fee for our static public dedicated IPv4 address . (or is it possible to make a working script that will make the rule with the IP address got from DHCP server?)
It even works no matter whether I have “add-default-route” to no or yes on the ISP-macvlan1 DHCP client settings, but I left it set at no.
So now I can try to return those dstnat rules back and see if it will do its job.
Well, the possibility that this might happen is exactly the reason why I prefer the solution with two DHCP clients attached to the physical interface and to the macvlan one, although @panisk0’s suggestion is fine if the addresses never change and the ISP doesn’t check the MAC address/IP address match. Because if you make your action=dst-nat rules match on in-interface=xyz dst-address-type=local rather than on dst-address=10.3.33.x, they will keep working even if the ISP guys decide to change the addresses they lease to you (of course, provided that they also adjust the forwarding from the dedicated public address).
Well, that may be an issue, as they do have to pay for it themselves. My ISP was also giving me a public IPv4 for free for a couple of years, and then all of a sudden I got a new ISP because the old one had to sell the business, as this was just one of his business decisions that were suboptimal. And one of the side effects of that ISP change was also a change of my public address.
Other small ISPs forward just a couple of TCP and UDP ports to each customer, so the price of the public address is split between multiple customers.
As stated above, you don’t even need a script if you use the combination of match conditions I’ve suggested.
. (or is it possible to make a working script that will make the rule with the IP address got from DHCP server?)