Hello guys.

How can I define a source IP/INTERFACE for traffic generated by router itself? Like DNS search, upgrade, ping, resolve, etc.

Thanks

Hello,

I also have this question.

Because of IPv4 depletion, and the need for several routers on my network, my ISP gave me RFC1918 addresses for the WAN interface and a single non-RFC1918 address for each router.

I was hopping I could assign the non-RFC1918 to a bridge interface and use it as source address mainly to upgrade the router, although, It will also need the DNS queries to be sourced from the non-RFC1918 address in my scenario.

I've identified a couple options where src-address is available with the following syntax
ping 8.8.4.4 src-address=203.0.113.11
system ssh 198.51.100.11 src-address=203.0.113.11

I was thinking it would be nice to have it for other features like:
system package update check-for-updates src-address 203.0.113.11
system telnet 10.1.1.130 src-address 203.0.113.11

or maybe a system wide option like
ip src-address or system ip src-address

If there is a workaround/solution that "mascarades" traffic generated by router itself, I'm willing to give it a try. I there is currently no way to do this, can it be made a feature request?

Thanks in advance.

The router normally chooses a local source address for each route based on the subnet of that route's gateway IP, and you can specify a particular address to use on that route for locally originated traffic.

Where this is not sufficient, like in your case where the public adddress is not assigned to the internet-facing interface, EDIT: you can use src-nat. (was: an ugly way to src-nat a locally originated packet exists).

an ugly way to src-nat a locally originated packet exists

Maris sent me an email with this same suggestion: mark a packet on outside and src nat!

Actually I really don't like this, but seems we don't have another way.

mark a packet on outside and src nat!

EDIT: the text below is not true for src-nat.
The problem is that it is not this simple because RouterOS does not allow to src-nat locally originated packets directly, this picture says it all - there is no chain in the table. That's why the loopback tunnel described on the link above is necessary to dst-nat or src-nat locally originated packets before sending them to the wire.

People used to linux (aka ) usually forget about the fact that the functionality is not enabled 1:1 in RouterOS. On the other hand, people spoilt by Mikrotik's address lists are usually surprised that this functionality doesn't exist out of the box on many linux distributuions.

No! The ugly linked thing is only for dstnat. Srcnat works for locally originated connections just fine, because srcnat is postrouting thing. And that happens no matter if the packet came from output or forward.

srcnat is postrouting thing. And that happens no matter if the packet came from output or forward.

Agrrrreed. Apologies, same thing, too late here.

In case someone wanders by this thread and needs help, I think I've come up with a good solution that's simple and seems to solve the issue for all internal utilities/methods that generate DNS traffic (and probably all other types as well). My issue stems from the fact that I need it to go over IPSEC tunnels, which are policies, not routes, so it fixed the issue for me, but I'd suspect it's close to, if not dead on, what you need.

Please read what you can and comment in case there are some caveats I haven't explored or thought of yet.

viewtopic.php?f=2&t=177344


>> Quick Update: Since it's a big post with multiple issues encountered and solved, use the last code snippet in my original post, where I set a route to use the main bridge, that scoops up this internal traffic and puts it in the path of the IPSEC policy matchers or at least sets it to go out the main NAT/route if not. The solution mentioned there by pe1chl is useful to fix the IPSEC issues, but this solves other problems for what I'll call "undefined" traffic where a source address is not explicitly defined or selected.