Something that annoys me on complex mikrotik configs is how do you know what source IP the internal tik DNS will use?
I usually end up having to jam a /32 static route route to the DNS and use a preferred source IP.
On failover configs you may have to use multiples for reachability
I thought now we have the “lo” interface if I stuck the IP I want on that it might use it because that is supposedly the local but that doesn’t work.
It must obviously choose a source IP from the large number on the router so there must be a rule on how it selects it?
The rule for selecting IP address is: do the routing selection and take IP address, associated with egress interface. Which is either pref-src (if set) or interface’s “native” IP address. Which is more or less the same procedure as when it comes to SRC NAT action masquerade.
My experience is that if interface has multiple IP addresses set, the numerically lowest value is chosen (but this is based on a very limited testing, so I may be wrong). If interface has neither pref-src nor IP address set, router will choose one of other own IP addresses (again according to my limited experience it’ll be the numerically lowest address but I may be wrong again).
If you want to use a particular IP address (could be associated to some loopback interface), then you have to set it as pref-src property to all routes. I don’t know if this is possible when some routing protocol (BGP, OSPF, …) is in use.
Yes the problem come up like clockwork on transit routers where the default route is usually some bgp-ospf down emergency recovery route.
There is internet everywhere and many transit IPs but you have to use the right source IP to get return path back.
Running static routes on a transit router is a maintenance nightmare.
You usually only need the dns for ntp client and dynamic dns entries.
It is weird they give source IP selection on all sorts of local services Radius, SNMP, Telnet/SSH etc
However DNS and NTP client never got that ability seems like short sighted development.
Even stranger is you expose the “lo interface” so you would think local services should use any IP on that if you can’t set them. You sort of scratch you head so it’s a local interface but not for local services?
The management IP is carried on the OSPF how the hell do I tell the stupid DNS on each tik to use a preferred source IP
You can’t jam a static route with preferred source because it will stop following routers working
I have exactly this problem too. OSPF adds default route but subnets used for OSPF connection between routers are not routable and added to NAT (network design)
I also need to use specific src IP for DNS connections, or even better for traffic generated by router itself (DNS request, Mikrotik updates, NTP…)
This is a well known situation. The simplest solution is srcnat. (You mark connections in mangle input and output, and then nat based on the mark.) This is not the most elegant but works.
There are alternatives: pref-src can be set in routing filters. The router’s own traffic can also be forced into an alternative routing table, or a vrf via routing rules.
any service listeners should reply back to which ip request came from. so what did you mean?
forget about the path - the servers don’t care about it as long as they can answers. the problem is on the routing design - not mainly on the server. be its ip listen on physical interface or loopback or whatever - as long as the client request to correct ip on the service - that server will reply.
assuming your mgmt vlan 11 is private block 11.0/24 and your MT router4 dns has multiple Ip on it - your mgmt dns client should be assigned the closest dns ip for that particular mgmt vlan 11.100/24 then the reply will go through mgmt vlan. and dns will reply with 11.100 not with any other ip - otherwise it will be discarded by the client.
ix bgp is another different topic. split routing, full ip routing vs natted ip etc.
You miss the whole point the packet can’t get to the NTP, DNS server because you have no idea what source IP the mikrotik is going to use BECAUSE YOU CAN’T SET THE SOURCE IP. So concentrate on the send forget the path how are you going to tell the mikrotik WHAT IP TO USE. That is why the whole mangle mark comes up but you can’t do that on a multihop OSPF.
There are perhaps a dozen IP’s on various interfaces and on most other services EXCEPT DNS an NTP client you can set the preferred source. Open the Radius, SNMP or any of the other service screens you can select an preferred source IP so it and you know absolutely what IP it will use. Even the stupid ping screen allows you to set a preferred source IP because you might need it … here see that.
There are two services that currently do not have a preferred source ip and they are DNS and NTP client and because of that it becomes a fight each and every time. You end up with ridiculously complicated configs for what appears to be nothing more that an oversight by the dev team. All I am asking is they fix the oversight and save us all heaps of problems.
you spoke about MT as ntp/dns clients but don’t know which ip will that clients is using to reach those servers. because the client and servers weren’t built to care about it. as long as they can reach the servers their job is done. and that goes for the servers too. (you can name any other client server protocols that concept is still apply). forget about the route.
ok let us back to the basics. there are reasons engineers made dynamic routing protocols. and 1 of them is to simplify routing Administration.
you don’t want to punch static routes to the server is fine. the whole mgmt vlan concept is to simplify your job. put your dns ntp servers on that vlan and your job is done. forget about what ip will the clients is using. it will automatically select which ip can reach the servers. 8f those clients see mgmt vlan can reach those servers easily they will use that vlan ip.
dynamic routing made things even easier. you don’t need to worry about asymmetrical request reply. as long as the transactions is working then the job is done.
FFS stop and just grab a mikrotik and put two IPs on one public and one private
Now on the DNS forward set 1.1.1.1 and 8.8.8.8
There is a 50% probability that the tik will choose the private one to try and reach 1.1.1.1/8.8.8.8 and it won’t work.
Please don’t tell me to NAT the private IP the private IP’s will exist for transit (on OSPF they are the link IPs).
That is why the ping screen has the ability to select the source IP … same problem it’s a guess what IP the tik will choose to ping from.
It has nothing to do with network or anything else just how the hell do you tell the Mikrotik to use a specific IP from the many it has.
We can’t be any clearer we want the ability to select the source IP same as every other service.
On OSPF the default route will be via an OSPF link which has a private ip lets say 10.66.66.1/30
In that situation its almost certain it will ping for 1.1.1.1 from 10.66.66.1 and it’s unroutable.
Why does the tik pick that because it has no source IP and so it uses the interface IP … that is the tiks default behaviour.
There is no public IP translation for 10.66.66.1 and even if you got the packet to 1.1.1.1 there is no path back to 10.66.66.1
You can’t NAT the OSPF private link IP’s … think about it beyond even the security problem.
All I am getting is you clearly have never used a tik as a transit router.
On a single hop you mark traffic to 1.1.1.1 and then static route it from a public IP on the router. That won’t work on a chain of transits because each router will strip the priors router IP. So on multihops there are complex mangle tricks you have to do.
For me it works perfectly. For ping (without src-address), dns, all of them. The source address is assumed according to the FIB lookup. The default pref-src is chosen over the recursive local (as it should be.)
On a simple setup the tik knows where the internet is and chooses the interface correctly. On a transit router there is no way it knows where the internet is.
As I said why do you think ping contains the option for source IP .. something you never have to use because the tik guesses right for you.
Here is a transit router see it has no idea where 1.1.1.1 is unless I give it a source IP. So in this case the private local IP will NAT to a public IP and then it can reach 1.1.1.1
So because I can’t set the source IP for the local DNS server I can’t use it or I have to do hijinx with mangle. The internet in this case is 3 hops away.
It’s not a matter of simplicity. In your scenario, you have two routes:
10.66.66.0.30 on-link local-address=10.66.66.1
0.0.0.0/0 via 10.66.66.2 pref-src=2.3.4.5
When sending a request to 8.8.8.8, the source address is 2.3.4.5. If you don’t select a pref-src, then of course as a fallback, 10.66.66.1 will be used.
What is pref-src set to in your scenario? Is it ignored?
For example for my test scenario logging shows:
in:(unknown 0) out:, connection-state:new proto ICMP (type 8, code 0), 2.3.4.5->8.8.8.8, len 56
(ping was logged, but no src-address was specified, and no, I don’t “own” 2.3.4.5)
On very simple setups you can do it. When you get complicated OSPF you can’t because there is no “one native source IP” it depends on network status.
Start with a simple two ISP gateway transit the router has two public IP’s and if you wrote the as static routes it would look like two routes with a ping test and a different preferred source IP.
So in your example of preferred source what I would need at a minimum is something like
set pref-src A.B.C.D; ping test; accept;
set pref-src W.X.Y.Z; ping test accept;
Some of the transits have many more paths than that and it gets increasing complex and you end up fighting the ospf and BGP with local mangle rules.
