I’ve got a rather complex system, but I’ve got a simple question. We have a primary MikroTik X86 system that handles our T1 connection. We use that to route traffic to both our subscribing customers and a RB532A that handles our hotspot traffic. The PC, has a public IP on one nic and hands out IP’s (10.10.10.x) via DHCP on the 2nd nic. The RB532A receives a 10.10.10.x address from the x86 box and then assigns 192.168.40.x addresses to several RB133 boards with wifi cards that act as our hotspots. Each RB133 is simply set up as a bridge, passing DHCP from the RB532A to the hotspot customer.
What I need is to be able to access the RB133’s from outside the net. I understand this should probably be done by setting up a route, but I’m not sure what needs to be in the route or where it should go. I can easily get into the x86 mikrotik, (it has a public IP) and I’ve got a dst-nat/src-nat rule set up to access the RB532A. but the RB133s can’t be seen unless I log into one of the hotspots.
It’d save me a 40 mile trip if I could find a way to monitor these buggers remotely.
I understand about your DHCP - what I would do is change your DHCP network on the PC to exclude some lower addresses so you can use a static IP on the RB532. Like this, DHCP range 10.10.10.20-10.10.10.254 Now set the RB532 with a static IP that is not in the DHCP range, and of course not used by any other IP connection. You probably have it set for default which would be 10.10.10.2-10.10.10.254
Now the same thing on your RB532 handing out IP to your Hotspots/RB133s…exclude some lower IP addresses from your DHCP range. You once again probably have your DHCP range set to the default of 192.168.40.2-192.168.40.254 - exclude enough to give your RB133s static IPs and a couple extra for expansion…
Now you didn’t say you had additional public IPs so I am going to recommend that you use VPN. Just follow the guide (ROS manual) for whichever ROS - 2.9.x or 3.x - that you are using, setup a VPN that connects you to the Internal LAN side of your PC router (10.10.10.x), turn on ‘proxy-arp’ on that interface.
Now - you should be able to VPN in, then use Winbox, HTTP, telnet, or ssh to connect directly to the RB133 in question (because you’ll already know the IP address - you made it static in the above…). Your RB532 and the PC should already have a route to the 192.168.40.x IP space that the RB133s are on so you’ll be able to jump right in there…
I have several RB133s behind other RB133s. I can see and change them all. I get two IP addresses from my provider and use a dstnat in /ip firewall nat. I access the first IP (“mom”) and change the nat setting to get to each box as I need them. Then I can access the box through the second IP. In “mom”:
Change dst-address to your second public IP address, and change the to-addresses setting to each AP behind the router as you need access. The example above sends the public address xxx.xxx.xxx.xxx to the AP with the local net IP address 10.0.0.2. You can now ssh, ftp, telnet, etc into that box by calling the second public IP.
Is that what you are looking for?
BTW, if you do this, it becomes very important to set the /system identity to unique names. It is easy to forget which box you are accessing if you don’t.
Ok, first, the DHCP issue isn’t a problem. Static or Dhcp I can’t access the 133’s. The problem I’m dealing with is to do this, it basically becomes a “tripple” nat situation. First, I’ve got to nat the Main X86 Mikrotik to the 532A board, and then from there on to whichever 133 board I want. IP addresses are not a factor as we have a as many as needed.
I have already tried a src-nat/dst-nat rule on the X86 MT and am able to log directly into the 532A board via the public ip address. But when I add a src-nat/dst-nat rule to the 532A board, the whole thing stops working.
Can anyone give me an example of what I need to do to complete the last hop to the 133’s?
Sounds like everything is nat’d along the way through your network - so I am guessing that this is a ‘semi-routed’ network. Using that premise;
First RB532 has a private IP of 10.1.2.10/24
RB532 has a second private IP of 10.1.2.11 for the RB133 behind it.
RB133 has a private IP of 10.2.1.15/24
Core public IPs - for nat’ing are 199.22.23.5 and .6 IP 23.5 is for the RB532 and 23.6 is for the RB133.
core has public IP for the RB532 at IP address 199.22.23.5/24 is nat’d to say 10.1.2.10 the first RB532’s private IP.
core also needs to have a second public IP for the RB133, so public IP 199.22.23.6 is dst-nat’d to 10.1.2.11 - the ‘secondary’ IP address of the first RB532. The secondary IP address here is dst-nat’d in the RB532 to the RB133’s private IP address of 10.2.1.15
The x86 machine is on a public ip block 73.194.59.1 but I’ve also assigned it 73.194.59.5
532a board is 10.10.10.159 but I’v also assigned it 10.10.10.5
rb133 is 192.168.40.189
I have a nat that will allow any traffic attempting to hit 73.194.59.5 to translate to 10.10.10.5 and vice versa.
When I try to implement a nat on the 532A board, that will direct all traffic from 10.10.10.5 to 192.168.40.189, I can’t reach either the 532a board or the 133 from a public IP.
You don’t need to use src-nat for this - in fact it will probably screw you up anyway. Just use dst-nat and be sure to pick the src address/32 and the outgoing interface.
What is the default gateway and src-nat you are using on the rb532?
Under winbox - /IP Firewall, connections tab - make sure connection tracking is enabled.
under winbox again - /IP routes , second tab - rules, make sure you have at least one rule - src 0.0.0.0/0 and dst 0.0.0.0/0 action=lookup table=main…
Still doesn’t work…send me an email off forum with your phone number - I’ll call you.
I think you may be missing a step. I use relational names for my boxes, like grandma, mom, and junior, because it is easy for me to see the relationships between them all. I will use really generic IP addresses in this example.
Grandma is your box that connects to the internet. She has two public IP addresses, xxx.xxx.xxx.2 and xxx.xxx.xxx.3. You access her through xxx.xxx.xxx.2 always. It is xxx.xxx.xxx.3 that you will be routing.
Mom is the 532. She has the addresses 10.0.0.2 and 10.0.0.3. You always access her through 10.0.0.2. It is 10.0.0.3 that you will be routing.
Junior is the 133. She has the address 192.168..0.2. You always access her through this IP.
ssh into grandma xxx.xxx.xxx.2 and set the dstnat on xxx.xxx.xxx.3 to-addresses=10.0.0.2
ssh into mom xxx.xxx.xxx.3 and set the dstnat on 10.0.0.3 to-addresses=192.168.0.2
ssh back into grandma xxx.xxx.xxx.2 and set the dstnat on xxx.xxx.xxx.3 to-addresses=10.0.0.3
ssh into junior xxx.xxx.xxx.3 . That should be the 133.
You can have multiple moms and juniors. Just repeat the process with the new IPs.
Does not need to be ssh. I’m just a CLI kinda guy.
…and I really like reading galaxynet’s stuff. Way good!
Answer… To signify only that address…ROS will drop it (the /32) after you add or apply the rule - the point is you understand that is is only that address and not the entire subnet…
Under winbox /ip routes 2nd tab, I have no rules, however, do I add that to both Mom and Grandma? or just mom? or just GrandMa?
Yes Tim’s family tree…well I do not have a complete explanation as to why you need to have the rules turned on, I know through experience that if you are using connection tracking and any kind of routing (yes static and broute included) that you need to have at least the ‘basic’ routing rule - src 0.0.0.0/0 dst 0.0.0.0/0 action=lookup and table=main for all of it to work together. So really - you should have this basic rule in just about everything. Transparent bridges excluded…
I think Tim was just showing you that you could continually change the dst nat to any box - since he has only the two public IPs to work with that is what he has been doing…
As I said earlier - if you need a little more help - drop me a line off forum at the email address below - I’ll shoot my phone number up here in Seattle…
Grandma only has one nat rule. That is for the xxx.xxx.xxx.3 (secondary IP) address. Leave the xxx.xxx.xxx.2 alone. It is how you get back to Grandma later.
In mom there should be only one rule for this also. Only for 10.0.0.3. Leave 10.0.0.2 as mom’s control IP.
I use the “family tree” because it is easier to picture mentally for me, and most of the students I tutor in programming. And they are like my children…
And, yes, the reason I do this is because my provider charges me for extra IPs, and why pay if you don’t need them? Two is plenty for me. One for the control IP, and one for the routed IP.
And if you use ssh for this, you will quickly find out where your /.ssh/known_hosts file is.
EDIT: What you are doing is changing Grandma’s routed IP to mom’s control IP, doing the route change on mom’s routed IP to the correct “junior”, then going back to Grandma and changing her routed IP to mom’s routed IP (junior). Now do you see why I use relational names? A little confusing, huh?
Ok, well, now I think I’ve got what ya’ll are saying, but I may have a new issue. I tried to ping daughter from mom and got no reply, wonder why I can’t ping the 192.168.40.x addressed RB133’s from the 10.10.10.x addressed RB532A? I’m going to assume this is the reason I can’t access the RB133’s.. Any ideas??
I should mention that the RB133’s are simply briged, they have a mini-pci wifi card on them and I have the wifi interface briged to the ethernet interface, this allows mom, (RB532A) to handle all the DHCP and RADIUS for the hotspot network.
Is there an interface on mom (RB532) that is assigned the 192.168.40.0/24 subnet? Like wlan1 maybe? If not, it should be assigned 192.168.40.1/24. It would be the “parent” interface on this local network. EDIT: This should be the interface that daughter is on.
BTW, galaxynet is working with me on using a VPN to access the boxes, but I’m not sure how flexible that will be if I need access from another location, and how well it will get past the NAT’ed interfaces. But I like new ideas, and reading his stuff.
Ok - well now I need to know where you are in converting from bridge to routed…
I understand that your gateway has 10.10.10.1 as the IP. Your RB532 has 10.10.10.159 and 10.10.10.5 as IP addresses…now are these on the eth ports or the wireless ports? How does the RB532 connect to the gateway? Wired/wireless? Are the ports bridged now or routed? If routed, whos on first? (Three Stooges…) What I mean is what IP is on what port (wired/wireless) if you have the RB532 setup as routed now vice bridged…
Your RB133 - a simple bridge setup - with a 192.168.40.x IP address…how does it connect to the RB532? Wired/wireless? I have to assume (always dangerous) that the RB133 is wired to the RB532 as I look at your description of the setup above…
Drop a line back - I will be in and out of the office all day today…
Ok, I’m not sure I understand about converting from bridge to routed. The only “bridge” I’ve got in the whole system is the bridge between the main ethernet interface and the wifi interface on the RB133’s. The x86 (Grandma) and the 532A (mom) don’t have any bridges on them at all.
The RB532 has the 10.10.10.x addresses on the same eth port. The port is connected to the switch that comes out of the x86 gateway box to provide internet, dhcp etc.
The RB532 has an interface coming out of it that also hands out dhcp, that interface, for all intents and purposes is going through a “switch” to the various RB133’s, and connecting to the primary ethernet port on each of the RB133’s, that primary ethernet port is bridged to the mini-pci slot on the RB133’s and that slot contains the wifi card.
To make it more complicated, technically, the connection between the 532A and the RB133’s is wireless, but, it is done using a Motorola Canopy Access Point and subscriber modules. It is, in practicality, an ethernet switch and very very very long invisible ethernet cables, that exist just out of phase with our visible space time structure ;P.
Each of the RB133’s has a DHCP client running on it to “pull” an IP from the 192.168.40.x pool being handed out by the DHCP server on the 532A board. but because each RB133 is also bridged to the wifi card, it also hands out 192.168.40.x ip’s from the 532A to each of it’s connected clients. (Side Note, thus far, the only way I can access the 133’s is to actually be connected to the 532A board with a 192.168.40.x ip address. I’ve yet to be able to access it from anywhere else.)
I would recommend getting the RB133’s off DHCP. I would set those up with static IPs. If your system goes down, when it comes back up, you could have different IP addresses issued to your boxes.
The interface on mom that connects to the daughter 133s should have the IP 192.168.40.1/24 assigned to it. Then assign the daughter 133s:
192.168.40.2/24
192.168.40.4/24
192.168.40.6/24
etc
Set the IP range on your dhcp server issuing addresses to 192.168.40.16-192.168.40.254. Insure the lower of this range is above your highest daughter 133 IP.
Until you have an interface on mom that has the same subnet as the 133’s, they will remain “hidden” from you.
Also, did you notice l left the odd addresses out of the RB133 assignments? Those I reserve for routed IPs if these “daughters” eventually have children.
Mactrekr -
As I said Mactrekr I wanted to know where you were at so now I know…
SurferTim has it about right. I would say that you need to reserve 192.168.40.2 - 192.168.40.20 as possible RB133 addresses, then give the remaining addresses out via DHCP.
Ok on the Canopy system…we’ll just consider it a switch for this exercise…
Ok then - your main router, the one that the RB532 is connected to - you need to add a route that says dst-addr 192.168.40.0/24 gateway = your RB532 10.10.10.x address.
Your RB532 has to have a default gateway of the core router (mom?) 10.10.10.1, so the route should be src-addr 0.0.0.0/0 dst-addr 0.0.0.0/0 gateway 10.10.10.1 You also need to have that ‘default’ route rule, src 0.0.0.0/0 dst 0.0.0.0/0 action=lookup table=main
You need to have a NAT rule in mom, src 192.168.40.0/24 , dst-addr 0.0.0.0/0 src-nat=IP on your core - you can use masq if you want or set this to a public IP that you have available on your core(mom) router public side. I also usually set the ‘out interface’ parameter here as well - to the outgoing interface name.
On the RB133s, you need to make sure you have a default gateway (should have been set by DHCP - but since you are going static with it) - just like above src-addr 0.0.0.0/0 dst-addr 0.0.0.0/0 gateway=RB532 192.168.40.? You also need to have that default route rule in place - src 0.0.0.0/0 dst 0.0.0.0/0 action=lookup table=main
This will get your 192.168.40.x addresses routed from the clients (and the RB133s) on the Hotspots to your core (mom). There, mom will nat the 192.168.40.x to the public IP of your choice. Now, when you are connected to the core (mom) 10.10.10.x side, you should now be able to ping 192.168.40.x without any problems. If you cannot then post a traceroute…
Once all this works then you can setup a VPN to the core and get to the RB133s by local (192.168.40.x) addresses.
Well said SurferTim …(above) you are getting it aren’t you!
galaxynet: Yes, sir, I am! I like your route on the daughter interface on mom above too. I have not tried routing a “foreign” (non-localnet) IP rather than assigning a secondary IP to the interface. I will try that too. Or are you assigning the 192.168.40.1/24 IP to mom’s interface also?
Just a thought…will the 133s have any trouble navigating back out through that interface? Another route needed in the 133s to go through the 10.10.10.x net outbound? Like for NTP, DNS, if needed.
No Tim, the core (mom) has a route to the RB133s, it sends all packets destined for 192.168.40.x to the RB532 at 10.10.10.x (it’s eth interface the RB532). There, the RB532, knows where to send the individual 192.168.40.x packets to…
When the RB133s make a request, they use their 192.168.40.x address. It goes to the RB532, which in turn sends it to the core router (mom) with it’s original src-addr of 192.168.40.x still intact. Now mom nat’s this 192.168.40.x to the public IP that is set in the src-nat rule in the firewall and sends the ‘request’ out to the Internet with the scr-addr now set to the public IP…
Routers have one question;
Do I know where this network (packet for a network) is?
Yes - then send it there (where ever you tell it to send this network IP (packet) to…).
No - then send this packet to the default gateway.
