Community discussions

MikroTik App
 
alfredo
newbie
Topic Author
Posts: 43
Joined: Wed Jul 01, 2015 3:06 pm

CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 3:00 pm

2nd - licensing similar to all other Mikrotik ROS products - instead of a subscription based license.
I would like to license and forget instead of having to track a subscription license.
I hesitate to install any products that use a subscription based license.
Similar situation here. We want a license that works for us. In our case, that means do not assume that routers are always Internet connected like end hosts.

We use CHRs with RFC1918 IP addresses only, and have no NAT in front of them (as it is not wise running NAT on autonomous system border routers). So there is no way our CHRs could establish a session with licence.mikrotik.com.
We can add a public IP address on an interface, for example a loopback interface. But then, there is no way to tell the CHR to use that IP address or the address in that interface to open sockets to the outside, rather than using the outgoing IP/interface, which is the default behaviour of most IP devices (including CHRs).

In one line, we would like to have this command:
/system license set source address=ADDRESS
And/or this command:
/system license set source interface=INTERFACE
We have opened a case with support regarding this (Ticket#2016091222001032) but so far it's been a waste of time.

Thanks.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26287
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: CHR feature requests

Thu Sep 22, 2016 3:10 pm

Alfredo. You can already do this using routing.
 
alfredo
newbie
Topic Author
Posts: 43
Joined: Wed Jul 01, 2015 3:06 pm

Re: CHR feature requests

Thu Sep 22, 2016 3:18 pm

Alfredo. You can already do this using routing.
Hi Normis,
I would much appreciate if you could give me a hint or pointer on how to do that. How do you mangle packets sourced by the router itself? I did search the wiki and the forum but couldn't find it, therefore I opened a case. Perhaps I am starting in the wrong place with mangle?
Furthermore, I think this would be of interest to some others using CHRs.
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6694
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: CHR feature requests

Thu Sep 22, 2016 3:26 pm

/ip route add dst-address=159.148.147.196 gateway=x.x.x.x
159.148.147.196 is address of licence.mikrotik.com
x.x.x.x is a single IP address of a gateway that can be directly reached through one of router's interfaces (there should be access to the Internet on this address).
 
savage
Forum Guru
Forum Guru
Posts: 1262
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Re: CHR feature requests

Thu Sep 22, 2016 3:28 pm

/ip route add dst-address=159.148.147.196 gateway=x.x.x.x
159.148.147.196 is address of licence.mikrotik.com
x.x.x.x is a single IP address of a gateway that can be directly reached through one of router's interfaces (there should be access to the Internet on this address).

Read the OPs message again...
 
alfredo
newbie
Topic Author
Posts: 43
Joined: Wed Jul 01, 2015 3:06 pm

Re: CHR feature requests

Thu Sep 22, 2016 3:41 pm

/ip route add dst-address=159.148.147.196 gateway=x.x.x.x
159.148.147.196 is address of licence.mikrotik.com
x.x.x.x is a single IP address of a gateway that can be directly reached through one of router's interfaces (there should be access to the Internet on this address).
That won't fly. I can see several problems:
  • Routing to a static IP address when you (Mikrotik) designate the licensing server by its DNS name is bound to break at some point in the future when you, for whatever reason (scalability, network reconfiguration, whatever) need to change the IP address. But you can't route by name; at most you can make a script to resolve the name periodically (say, each day) and change the route if needed. But that is wasteful of resources and inelegant. Still, having said that, things would work if it weren't for reason number 2:
  • gateway, in our scenario, is resolved by OSPF. We don't know it statically, and that is precisely the point of using OSPF: Redundancy and load balancing. Furthermore, we are still using RFC1918 IP addresses for the links out, which leads to:
  • As explained before, all the IP addresses are RFC1918 and there is no NAT in front of the CHR. So even if the packets do exit the router, they will be sourced with an RFC1918 IP address and won't get far.
To summarize, we are Internet-connected but can't set up a TCP session out, unless we force the source IP address of the session, which I don't know how to do for router-sourced packets (if at all possible). Hence my suggestion for a command to perform exactly this.

Maybe this matter should get its own thread, in order to avoid drifting off the topic of this one. Would a moderator be able to split this, or should I just go ahead and open a new one?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26287
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: CHR feature requests

Thu Sep 22, 2016 3:53 pm

/ip route add dst-address=159.148.147.196 gateway=x.x.x.x
159.148.147.196 is address of licence.mikrotik.com
x.x.x.x is a single IP address of a gateway that can be directly reached through one of router's interfaces (there should be access to the Internet on this address).

Read the OPs message again...
You too. How does the feature request help him then? He will provide internet access for specific src/dst on specific interface.
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6694
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 4:14 pm

Once again,

1. MikroTik.com does not initiate connection to your device, your device initiate connection to licence.mikrotik.com

2.
gateway, in our scenario, is resolved by OSPF. We don't know it statically, and that is precisely the point of using OSPF: Redundancy and load balancing. Furthermore, we are still using RFC1918 IP addresses for the links out, which leads to:
Do you have Internet access on any of routers, that are participating in the OSPF network?
If answer is yes, then create static route to 159.148.147.196 and redistribute this static route to CHR devices, CHR will receive gateway dynamically from OSPF.
(at the moment there is no plan to change licence.mikrotik.com address, but you can make resolve script, if you are afraid of address change
http://wiki.mikrotik.com/wiki/Manual:Sc ... _host-name).

If answer is no, I do not see how address/interface is going to help in your case. And it is possible to make routing-mark in chain=output for outgoing packets, but there you will still need static gateway configuration (and configuration provided above is simpler).
 
alfredo
newbie
Topic Author
Posts: 43
Joined: Wed Jul 01, 2015 3:06 pm

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 4:29 pm

Once again,
1. MikroTik.com does not initiate connection to your device, your device initiate connection to licence.mikrotik.com
I never had a problem understanding that. But, packets must flow in both directions, right? It is not enough that a SYN from the CHR reaches licence.mikrotik.com. It is equally necessary that the SYN-ACK from licence.mikrotik.com reaches the CHR, right? Given this, and the lack of NAT, it is irrelevant which part initiates, although it may be important depending on the solution to the problem. But I think it's a point that doesn't deserve to be stressed any more than the rest of the points in the problem description.
Do you have Internet access on any of routers, that are participating in the OSPF network?
If answer is yes, then create static route to 159.148.147.196 and redistribute this static route to CHR devices, CHR will receive gateway dynamically from OSPF.
(at the moment there is no plan to change licence.mikrotik.com address, but you can make resolve script, if you are afraid of address change
http://wiki.mikrotik.com/wiki/Manual:Sc ... _host-name).

If answer is no, I do not see how address/interface is going to help in your case. And it is possible to make routing-mark in chain=output for outgoing packets, but there you will still need static gateway configuration (and configuration provided above is simpler).
Yes, we do have Internet access on other routers participating in the OSPF network. Depending on your definition of Internet access, we do have that in the CHR itself; it just doesn't have a public IP address. We could provide it with one if it helped, though.

What we still don't have is NAT or, more generally, a means to take the outgoing packets sourced in the CHR and ensuring they have a public, routable source IP address. This latter definition is obviously a superset of lacking a way to make the CHR use a source address other than that of the outgoing interface, which would be a simple, elegant solution.

@normis, I am intrigued by your earlier statement that this can be resolved using routing. It would be awesome if you could elaborate or point me in some direction. A colleague and I worked in this problem hours and couldn't find a satisfactory solution, before asking for help.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26287
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 4:34 pm

Sergejs is doing his best trying to tell you how. Please follow his instructions.
 
alfredo
newbie
Topic Author
Posts: 43
Joined: Wed Jul 01, 2015 3:06 pm

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 4:48 pm

Sergejs is doing his best trying to tell you how. Please follow his instructions.
I am sure Sergejs is doing his best. However, his idea is not a solution, for the reasons I explained earlier. I think neither Sergejs nor you understand completely the scenario, because if you did, you wouldn't be stuck assuming that there is some NAT box somewhere further upstream. I think @savage did understand the scenario, and therefore his remark to read my question again.

So we are stuck here: Need a way for a CHR that has only private IP addresses and no NAT in front of it to source the traffic required for licensing from an arbitrary IP address or interface (and statefully accept the reverse traffic, of course). Otherwise it will use a private (RFC1918) IP address and won't do it.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26287
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 4:52 pm

He is preparing an updated response. Please hold.
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6694
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 4:52 pm

CHR required configuration,
1) Configure public IP address on loopback interface.
2) Configure SRC-NAT,
/ip firewall nat add chain=srcnat action=src-nat to-address=<public-ip> out-interface=<xxx>
3) Make sure to redistribute OSPF connected routes on CHR to ensure that reply reaches your CHR device.
 
educollado
just joined
Posts: 2
Joined: Mon May 27, 2013 10:12 pm

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 4:57 pm

It works, but I lost all machines behind my router

Thanks a lot anyway
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26287
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 5:17 pm

It works, but I lost all machines behind my router

Thanks a lot anyway
Can we consider the main issue solved?
The other issue is most likely related to other config that you need to resolve separately
 
educollado
just joined
Posts: 2
Joined: Mon May 27, 2013 10:12 pm

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 5:19 pm

I add
dst-address=159.148.147.196
to your command and right now it is working
chain=srcnat action=src-nat to-addresses=loopback_ip dst-address=159.148.147.196 out-interface=wan_interface
Right now it is working

Thanks!!!
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6694
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 5:22 pm

Modify 2) and set src-address=your_local_outgoing IP address.
 
User avatar
TomjNorthIdaho
Forum Guru
Forum Guru
Posts: 1492
Joined: Mon Oct 04, 2010 11:25 pm
Location: North Idaho
Contact:

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 5:58 pm

Question - why is the license on a CHR ROS 64-bit (running on AMD or Intel CPU) different than a license on an x86 ROS 32-bit (running on AMD or Intel CPU ?

I don't like or trust core devices in or on my switches or routers that use a "Call-Home" mechanism to check on the license - especially if it is a virtual switch or virtual router.

To me, it is unclear what would happen if I had to move or relocate or rebuild or upgrade or replace or replicate or repair any virtual or physical device. In my VMware ESXi environment, I like the ability to be flexible and to move anything around as wanted between servers and networks. The last thing I would ever want to worry about is a broken "Call Home" auto license check resulting in the entire network no longer working.

My rule of thumb for ultra-secure core routers and switches is to 100-percent block everything (block all IPs and all ports), then specifically put in an allow list for exactly what may talk to what and when it may talk. And even then - some devices can never reach the Internet - and some devices must use a proxy server to get to the Internet.

Can the Mikrotik "Call-Home" license feature use/talk/check when there is a proxy server ?

A license should be easy to understand and use and clearly stated what you may and may not do. A license should not be subject to a remote 3'rd party "Call Home" computer somewhere out there on the Internet.

Please - just change the license to behave the same way every other Mikrotik license functions - without a "Call Home" check-in function. When I license it - I want to forget about it.

North Idaho Tom Jones
Last edited by TomjNorthIdaho on Thu Sep 22, 2016 6:31 pm, edited 1 time in total.
 
User avatar
TomjNorthIdaho
Forum Guru
Forum Guru
Posts: 1492
Joined: Mon Oct 04, 2010 11:25 pm
Location: North Idaho
Contact:

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 5:59 pm

EDIT - for some reason my post double posted - so removed the duplicated post

Hm - I could not find a delete post function.

North Idaho Tom Jones
Last edited by TomjNorthIdaho on Thu Sep 22, 2016 6:20 pm, edited 1 time in total.
 
alfredo
newbie
Topic Author
Posts: 43
Joined: Wed Jul 01, 2015 3:06 pm

Re: CHR: renewal from behind NAT (routing question)

Thu Sep 22, 2016 6:13 pm

So at some point we may add a script to check and react automatically to DNS changes... But for now, we can add a monitor for DNS changes and that should be enough.
I think the router broke the OSPF adjacency before Eduardo's change and don't understand exactly why, but it is no big deal if with that change it doesn't do it. So yeah, I think we can call this one solved. Thanks a lot for your help!
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26287
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: CHR: renewal from behind NAT (routing question)

Fri Sep 23, 2016 8:40 am

Question - why is the license on a CHR ROS 64-bit (running on AMD or Intel CPU) different than a license on an x86 ROS 32-bit (running on AMD or Intel CPU ?
This is off topic here. But to answer your question, this is so you can move the license to other virtual systems. x86 license was bound to the installation, so if you wanted another one, you had to pay again. In this case, you can simply remove the license and apply it to another machine. Nothing can get broken, if RouterOS CHR can't "call home" you will simply lose ability to upgrade RouterOS after 30 days. RouterOS will continue to work without any other limitations. You can give access to internet once you need to upgrade again.
 
User avatar
novasys
just joined
Posts: 3
Joined: Tue Jul 02, 2013 2:15 pm
Location: Bucharest / Romania
Contact:

Re: CHR: renewal from behind NAT (routing question)

Sun Dec 29, 2019 1:13 pm

Hello guys,

I have a similar situation in my setup except that we have disabled connection tracking on all our virtual borders routers so we are unable to set nat locally or in upstream in order use Sergejs solution.
It is pointless to alter the routing table for all the traffic that is going through this CHR for obvious reasons already mentioned by Alfredo (source of ip address will still be from private space no meter what the routing decision is).
To complicate the topic more, I'm unable to thing further for other CHR that we have in a production environment where we use VRFs and were the management traffic ( which have access to the internet ) is bound to a VRF).

We have done a scheduler to alter the configuration in such a way that connection from CHR to license.mikrotik.com is possible but this is not elegant nor professional in such an environment.

Maybe you should reconsider adding a feature to set the outgoing interface ( or source address ) for traffic generated by the CHR itself. The same situation is faced for DNS queries locally generated and for NTP client queries.
 
User avatar
BananaJack
just joined
Posts: 2
Joined: Wed May 24, 2023 9:08 am

Re: CHR: renewal from behind NAT (routing question)

Sun Jun 25, 2023 10:42 am

…Nothing can get broken, if RouterOS CHR can't "call home" you will simply lose ability to upgrade RouterOS after 30 days.

For anyone else like me trying to figure this out, I was confused by normis’ comment until I realised that he is referring to upgrading the RouterOS version number, not upgrading the RouterOS licence level.

…RouterOS will continue to work without any other limitations. You can give access to internet once you need to upgrade again.

I believe this is only true if you have previously bought and installed a paid perpetual licence. If you’re running a trial licence then the router will revert to ‘free’ licence level and throughout will be severely restricted to only 1 Mbps

Who is online

Users browsing this forum: No registered users and 14 guests