I had to set up a long wireless link on short notice and didn't have the time I would have liked to research things. Did what I could, got the link up, and hoped to fix things later.

Long story short, I have 4 wireless devices the make up the link that are before my RB750 router (on the WAN side) that I need access to. They are on the same subnet that the router serves (192.168.0.x).

Doing some research after the fact, I have learned that having them on the same subnet is bad. Would be better if they were on, say 192.168.1.x. I can change that, but it's difficult - requiring a visit to the remote site.

I have also read some past posts on things like this:

viewtopic.php?t=57219

I already had the masquerade rule mentioned in Firewall>>NAT:

add action=masquerade chain=srcnat disabled=no out-interface=ether1-gateway

but no access.

Is it possible to make this work, or do I need to change the IP's of the 4 wireless link devices?

The last post of the thread says this:
+++++++++++++++++++++++
Resolved, my steps:

1. Assign IP to the ether1-gateway interface in the same range as the ADSL modem, but different to the LAN (this is the step I missed)
2. Create a Masquerade NAT rule for the ether1-gateway interface.
+++++++++++++++++++++++

Don't know if this will work, and didn't want to kill the remote network trying it. I get the impression that since the link devices are on the same subnet that it won't. If I'm wrong, please let me know and what steps I need to take to get this working.

Thanks for any help and advice on this.

Can you make wireless1 the Router?
Or move the RB750 to where wireless1 is located?
Is that picture an accurate representation of your network?


(internet)---(wireless1)----(wireless2)----(wireless3)----(wireless4)(RB750) ---(LAN)

From your description it is not really clear what the actual problem is, but the firewall rules in the default configuration do not allow access to management of the router via WAN, so if you need it, you have to add your own rules permitting such access for authorized source addresses. If the WAN address is a public one, it is one step safer to set up a VPN access, but that doesn't seem to be your case.

But the above is just a guess. To get a better analysis, you have to post the actual configuration of the device once you have a chance to get there. A diagram of the network with addresses of the other devices will be useful too for such analysis.

Thanks for the responses and sorry for the lack of clarity. It was late and I was tired. Helipos' diagram is exactly what's in place:

(internet)---(wireless1)----(wireless2)----(wireless3)----(wireless4)(RB750) ---(LAN)

The RB750 can't be at the head end as there is also a Cradlepoint at the remote site in IP Passthrough mode to provide failover to LTE. It is currently NOT connected in any way so it doesn't contribute to the problem.

I have remote access to the 750 and VPN access to the remote network and both of those are working. So we have tools to change settings.

Logging into the VPN and using that access to get back to the devices on the WAN is fine with me, but that doesn't work right now with them on the 192.168.0.x subnet. Everything inside the network on that subnet is accessible.

I'm afraid I'm still a bit lost on what is the actual problem. Are you saying that the subnet on the 750's LAN is the same (192.168.0.0/24) like the subnet you've chosen to place the management addresses of the wireless devices at WAN side into, whereas the own IP of the WAN of the 750 is from another subnet and those wireless devices are L2-transparent so the packet exchange between the WAN IP and the gateway in the WAN subnet works fine? And that the actualy issue is not how to get to the 750 itself via WAN, but vice versa, how to get to the management of the wireless devices from the 750?

If so, then yes, having the same subnet at two L2 segments is not a good idea, and the final solution should be to either change the LAN subnet or to move the wireless devices' management into another subnet.

So if you can reach the 750 remotely via WAN and disable the IP assigned to the LAN interface of the 750 for a while (and thus make the network inaccessible for hosts on the LAN), you can attach the 192.168.0.1/24 to WAN in parallel to the usual one, and also assign 192.168.1.1/24 to it (so three addresses&subnets on WAN in total). Then, you can visit the wireless radios one by one and change their management addresses from 192.168.0.x to 192.168.1.x. And finally you remove the 192.168.0.1/24 from the WAN and re-enable it on LAN.

Sindy:

Thanks for sticking with this.

You are describing the situation in your first paragraph perfectly.

My "boots on the ground" at the remote site walked out there this morning (Yep, it is that remote) and changed the IP's on two of the most critical devices from 192.168.0.x to 192.168.1.x We verified that I still have Internet access with these changes, made a couple others related to channel width and MCS rate, and called it a wrap for now.

So, I two have two items on the WAN with 192.168.1.x addresses and unique non-standard ports assigned to them that we can tinker with. They are pingable on ether1-gateway with the Winbox PING tool.

I tried reaching them from a web browser when VPN'd into the network with no success.

I didn't get the feeling from your response that after changing these addresses I still need to assign 192.168.1.1/24 in parallel with the existing 192.168.0.1/24 on the router. Do I?

They are pingable on ether1-gateway with the Winbox PING tool.
...
I tried reaching them from a web browser when VPN'd into the network with no success.
...
I didn't get the feeling from your response that after changing these addresses I still need to assign 192.168.1.1/24 in parallel with the existing 192.168.0.1/24 on the router. Do I?

I assume that in order to ping them, you have to tick the arp-ping checkbox and specify the interface (ether1-gateway).

The basics of IP routing: to ping an IP address using ICMP, not ARP, a route to it must exist in the routing table.

• if that route has an interface name as a gateway, and the interface is a point-to-multipoint one by nature, such as Ethernet, an IP address from the same subnet like the target's one must be attached to that interface. So to to reach devices with 192.168.1.x/some-mask addresses via ether1-gateway, you have to attach an 192.168.1.y/some-mask to ether1-gateway.
• if that route has an IP address as a gateway, a router with that IP address must be reachable the way above.

But that's not all. Adding 192.168.1.1/24 (or what mask have you set on the wireless devices) to ether1-gateway only makes the devices in 192.168.1.0/24 accessible from the 750 itself. If you want to access them remotely, using the 750 as a router, you need to tell your PC that the 750 is a gateway to 192.168.1.0/24, but you also have to tell the wireless devices that the route back to your PC is the 750 too. So it depends on your VPN type, and on the routing settings on the wireless devices, what else has to be set. If no routes are defined on the wireless devices, or if their gateways are something else than 192.168.1.1, you'll need to add a src-nat rule to the 750, before the default action=masquerade one:

/ip firewall nat
add chain=srcnat action=src-nat to-addresses=192.168.1.1 out-interface=ether1-gateway dst-address=192.168.1.0/24

This way, any incoming connection, even from your PC, will be seen by the wireless devices as coming from the 750 itself, which they can reach without a manually added route because it is in their own subnet.

OK, then. I think we're getting there.

I did NOT change the gateway addresses on the two wireless devices that I changed the IP's on earlier today.

Do I need to only add this to Firewall>>NAT:

/ip firewall nat
add chain=srcnat action=src-nat to-addresses=192.168.1.1 out-interface=ether1-gateway dst-address=192.168.1.0/24

or is there other step(s) that must be taken?

or is there other step(s) that must be taken?

You must add the 192.168.1.1/24 address to ether1-gateway as well, keeping the other IP address it has (or the /ip dhcp-client attached to it) in place.

OK, again. So if I do that, Winbox won't stop working so I can undo things if necessary as it doesn't depend (at least to my understanding) on anything that might be affected by that change.

Sorry to nit-pick on this, but the network in question is a 7 hour drive away and whenever I do any remote config I try to be really, really sure that I don't knock it offline. Maybe Safe Mode would be an option here.

For your inspection, here's a sanitized version of current /ip/address such that you can stop me from making a big mistake if there's something hinky about it:

[admin@MikroTik] /ip address> print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 ;;; default configuration
192.168.0.1/24 192.168.0.0 bridge1
1 D 216.169.x.x/26 216.169.x.x ether1-gateway
[admin@MikroTik] /ip address>

the network in question is a 7 hour drive away and whenever I do any remote config I try to be really, really sure that I don't knock it offline. Maybe Safe Mode would be an option here.

Of course safe mode is a must no matter how risky or routine the configuration being done is, as at least typos happen. So of course, do everything with safe mode on, just don't forget to exit safe mode before logging off intentionally.

For your inspection, here's a sanitized version of current /ip/address such that you can stop me from making a big mistake if there's something hinky about it:

No potential conflict visible, so go ahead. First just add 192.168.1.1/64 to ether1-gateway, then try to ping the wireless boxes with arp-ping unticked and interface not specified. If that succeeds, add the src-nat rule described earlier and put it above the normal masquerade one, then try to ping the wireless boxes from your PC. If this doesn't succeed, post the export of the 750's configuration and describe the VPN type you use on your PC.

Made the changed per the above and VPN'd in. Still unable to access the two link devices.

Pinging the devices without specifying interface or ticking ARP works.

My VPN is a simple PPtP one with server running on the Mikrotik (I know, I need to change to something more secure - that's on my list). Client machine running Ubuntu and Gnome Connection Manager for CLI work.

Local address for the VPN is 192.168.0.235, remote is 192.68.0.236. I also tried 192.168.1.235 and 236 and the VPN connected but still no access to the devices on the WAN.

Relevant portions of the setup you helped me with are below:
+++++++++++++++++++++++++++++++
/ip firewall nat

16 chain=srcnat action=src-nat to-addresses=192.168.1.1 dst-address=192.168.1.0/24
out-interface=ether1-gateway

17 ;;; default configuration
chain=srcnat action=masquerade to-addresses=0.0.0.0 out-interface=ether1-gateway
log-prefix=""


[admin@MikroTik] /ip address> print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 ;;; default configuration
192.168.0.1/24 192.168.0.0 bridge1
1 D 216.169.x.x/26 216.169.x.x ether1-gateway
2 192.168.1.1/24 192.168.1.0 ether1-gateway
[admin@MikroTik] /ip address>
+++++++++++++++++++++++++++++

Rule #17 in NAT was the preexisting one to masquerade to ether1-gateway. I didn't create or edit that. Based on the other information I gathered about this issue, it appeared to be correct.

In your last post, you said:

"First just add 192.168.1.1/64 to ether1-gateway"

Got an error about value out of range with that, so figured a typo and entered /24 instead.

Some more info:

Neglected to mention that I am running a hotspot on the 750. Disabled the server just to see if that was a problem. Made no difference.

While watching the "new" NAT rule in Winbox, then using the Ping Tool to ping one of the devices, can see the byte/packet count increase.

My VPN is a simple PPtP one with server running on the Mikrotik (I know, I need to change to something more secure - that's on my list). Client machine running Ubuntu and Gnome Connection Manager for CLI work.
Local address for the VPN is 192.168.0.235, remote is 192.68.0.236. I also tried 192.168.1.235 and 236 and the VPN connected but still no access to the devices on the WAN.

I still assume it is a routing issue then. The local and remote addresses of PPP tunnels (like the PPTP VPN) are exceptions from the subnets they eventually match on either device, so regardless what other addresses are set on the PC, it can always reach the remote end of the PPP tunnel. But the rest of the routing is a different question, there may be a conflict between "local" 192.168.1.0/24 subnet on the PC (if it exists) and the "remote" 192.168.1.0/24 subnet on the 750. And unless the VPN supersedes the default route by another one via the tunnel when active or a dedicated route to 192.168.1.0/24 via the tunnnel is configured, packets sent to 192.168.1.0/24 will take the default route of the PC, so never get to the 750. And, finally, some firewall rules on the 750 may block forwarded traffic from the PPTP interface.

So make sure that the local and remote address for the PC are assigned from 192.168.0.0/24 in the configuration of the 750, and then

• post the output of ip address show and ip route show on your PC while the PPTP VPN is up,
• post the complete export of the 750's configuration, see my automatic signature below for anonymisation hints

In your last post, you said:
"First just add 192.168.1.1/64 to ether1-gateway"
Got an error about value out of range with that, so figured a typo and entered /24 instead.

Correct. In three previous posts there was /24

Working on uploading configs next.

Thanks again for the help so far. We are so close to making this work I can see those link setup screens in my dreams.

Here's what you asked for. I manually deleted a bunch of entries with MAC addresses under Hotspot>>Bindings and otherwise tried to eliminate unique and/or personally identifiable info. I hope it meets your standards for that. If there's anything in there I need to edit out, let me know ASAP and I will do so.

As you can see, I am pretty harsh on my users. That's because this link originally used Starband consumer satellite which had very low usage limits which if they were exceeded, we'd get slowed way, way down and perhaps cut off until we met the re-entry requirements. We're on Verizon LTE now, but it still costs $10 per GB so I haven't let up much. If I get the new backhaul working, I can loosen up a little. Maybe a lot.

It's also kind of a mess, several years of collected things that were tried (all those port forwards that are disabled), problem devices blocked, etc. and are not now being used. The two rules you sent me yesterday for /ip address and /ip firewall nat are currently disabled because they didn't have the intended effect (yet) and I didn't want to leave them enabled without knowing what effects they might have otherwise.

Let me know if you need any further info.

/ip address and /ip route with VPN running:

to eliminate unique and/or personally identifiable info. I hope it meets your standards for that.

You haven't sanitized at least the ip dhcp-server network part so the public IP addresses of the whole /22 are visible. Your firewall is quite leaky so it is probably quite easy to drain your monthly quota by sending bogus packets to your clients and possibly getting at least ICMP messages back.

If you did sanitize, you should have done that in a self-explanatory way, i.e. that it was clearly visible that those addresses are not real.

Other than the above, it's not so much a matter of my standards, for the analysis it is always better to have as much information as possible, that's why I stress out the need to take measures to keep the information consistent. It is rather the other way round, many people are lazy to sanitize the exports carefully before posting them so they post just the parts they assume to be problematic, and the actual problem often lays elsewhere.

Let me know if you need any further info.

I've already asked before for the ip a and ip r output from the PC running the VPN client, to watch for missing routes and conflicting subnets.

As for the configuration of the 750, all your dst-nat rules don't care from where the initial packet of a connection to the redirected ports came nor what is the original destination address, so it is well possible that they steal your management connections to the wireless devices. Not knowing the ports those devices listen at and seeing that you use non-standard ports for the services running at the 750 itself.

You haven't sanitized at least the ip dhcp-server network part so the public IP addresses of the whole /22 are visible. Your firewall is quite leaky so it is probably quite easy to drain your monthly quota by sending bogus packets to your clients and possibly getting at least ICMP messages back.

Okay. Will delete the contents of /ip pool and and /ip dhcp-server. For now, I have pulled the entire thing. Since you might have snagged it already, I won't put it back unless you ask for it.

Other than the above, it's not so much a matter of my standards, for the analysis it is always better to have as much information as possible, that's why I stress out the need to take measures to keep the information consistent. It is rather the other way round, many people are lazy to sanitize the exports carefully before posting them so they post just the parts they assume to be problematic, and the actual problem often lays elsewhere.

Sorry. Perhaps "suggestions" would have been a better choice than "standards". I completely agree on the need for consistency.

I've already asked before for the ip a and ip r output from the PC running the VPN client, to watch for missing routes and conflicting subnets.

Oops, misunderstood this one and sent the output from the remote 750. Will fix.

As for the configuration of the 750, all your dst-nat rules don't care from where the initial packet of a connection to the redirected ports came nor what is the original destination address, so it is well possible that they steal your management connections to the wireless devices. Not knowing the ports those devices listen at and seeing that you use non-standard ports for the services running at the 750 itself.

Pretty much everything on the network uses non-standard ports unless they don't have the ability to do otherwise. That's mostly a holdover from ancient times when I was doing port forwards for device admin before setting up the VPN to do that. I have all the device info in a spreadsheet so that I can sort on port/ip/whatever to be sure I don't have any duplicates. I am as sure as I can be that at this point I don't. Do you need additional info on this?

OK, I have the output of ip a and ip r from my workstation ready to go. It contained one instance of a public IP which I have mangled. And some of username@PC name which received the same treatment. Of course it is riddled with instances of 192.168.x.x but from my limited understanding it's OK to leave those.

Shall I post?

One thing has occurred to me - I have the Max MTU and Max MRU for the VPN server set to 1360 because that value is needed for the VPN to run over LTE. Could this be a problem? Everything else on 'Tik interfaces is running at 1500.

I am wary of changing this and losing the VPN. However, it does seem to be working normally.

Looked at the output of ip a again and there are some MAC addresses associated with ether xx and wlpls that I will also remove.

Yes, replace the public address and the mac addresses and post it. And yes, I don't need you to re-post the config you've withdrawn.

Output of ip a and ip r:

And this is it. The VPN does add a default route via the tunnel, but as your LAN subnet on the PC is 192.168.1.0/24 as well, packets for 192.168.1.0/24 never get to the 750 as they end up on local LAN.

3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether x.x.x.x.x.x brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global dynamic wlp1s0
valid_lft 6252sec preferred_lft 6252sec

default dev ppp0 proto static scope link metric 50
default via 192.168.1.1 dev wlp1s0 proto static metric 600
192.168.0.235 dev ppp0 proto kernel scope link src 192.168.0.236 metric 50
192.168.1.0/24 dev wlp1s0 proto kernel scope link src 192.168.1.254 metric 600


So one possibility is to set up port forwarding (dst-nat rules) on the 750 also for the wireless devices; another, maybe easier, possibility is to change your home subnet from 192.168.1.0/24 to 192.168.2.0/24. Yet another possibility is to add routes for the individual wireless devices' addresses:
ip a a 192.168.1.X via 192.168.0.235
A more precisely matching prefix always wins over a less precise one. So 192.168.1.0/24 beats 0.0.0.0/0 (default), but each 192.168.1.X beats 192.168.1.0/24.

And boom, we're in. Yee-Haw and Thank you!

For a quick 'n dirty trial, I just fired up the Verizon hotspot which dishes out IP's on 10.x.x.x and used that instead of the home network.

Now that I have access, should I change the gateway IP's on the link devices from 192.168.0.1 to 192.168.1.1? You mentioned that earlier. If it makes things easier, no problem. Or any other things that might help as far as network settings on those devices are concerned.

Or maybe we should adopt a "if it's not broke, don't fix it" approach. I get that.

Just wanting to do what it takes right now to make my life easier in the future. As you get older, you tend to forget what you did to make a particular thing work. I am planning on creating a .PDF from this whole thread and keeping copies in at least 3 separate places and have already backed up and "exported" the 750 config and downloaded both. I prefer to not have to reverse-engineer what we did here at some point should I lose the remote site due to a lightning strike and need to start over.

I like the idea of having dst-nat rules on the 750 if using that approach would make things more independent of the subnet you are VPN'ing in from. Would that be the case? What would a sample rule look like?

Many thanks again for taking time out from your weekend to work with me on this. Now, if I can just get an answer from Ubiquiti as to why their firmware version XW has a max. TX power of 25dBm whereas version XM had 28. That difference is not what I designed for and the link performance is, well, "not good" because of it. I needed to see the setup screens to confirm this.