So I am trying to access a couple PTP panels externally that are behind a Mikrotik. The setup is as follows...

Me -----> Internet -----> (public IP) Mikrotik 3011 (10.1.10.1) -----> LAN (10.1.10.0/24) -----> QRT ac (10.1.10.209) -----> QRT ac (10.1.10.211)

I have full Winbox access to the 3011. The PTP panels are a very basic setup. The ether1 interface and the wlan interface are in a bridge and the bridge has a DHCP client setup. I have verified communication across and I can access both QRT panels via Winbox while on the 10.1.10.0/24 network.

My goal is to have external Winbox access to all 3 devices. Here is what I was thinking at first but it didn't work...

1. Port 8291 accepted from anywhere (bad practice but just for this example)
2. Anything with the source address of my house's public IP on port 8291 dstnat to the first QRT panel
3. Anything with the source address another location's public IP on port 8291 dstnat to the second QRT panel

I could see the external traffic hit the nat rules and could see it in connections but it seems like the QRT panels are responding. They are not set to filter via ip services.

I also tried changing the default Winbox port on the 3011 and the QRT thinking that there was a conflict with no success. I also tried SSH with SSH disabled on the 3011 with no success.

I am able to mac-telnet from the 3011 to the QRT panels but what I need to change on the QRT panels is the wireless settings and I am much more comfortable with those settings via Winbox.

I am sure I am missing something. Thoughts?

The best practice would be configuring a vpn to your 3011.
And then just give access to local resources from that vpn connection.

I understand that is the best practice. In reality, I just need to do some adjusting on the newly installed PTP panels and this is only a temp thing. But a VPN may be easier at this point. With that said, understanding how to NAT that through and why it isn't working is something I would love to know.

Use non-standard ports for WinBox access to the PTPs. Then it’s just standard NATting to get to them from the internet.



Sent from a $&@#% iPhone using Tapatalk

Think about both src-address and dst-address of packets in both directions.

The RB connected to internet listens on public address. On this RB, you can set a dst-nat rule to translate e.g. dst-port=48291 to to-addresses=first.panel.ip and to-ports=8291, and another one to translate dst-port=58291 to to-addresses=second.panel.ip and to-ports=8291. This will ensure that the packets from the internet will reach the panels' interfaces. The src-address of these packets will remain the real one. So both panels need to have your internet-facing RB's LAN address a default route's gateway. If that is the case and you cannot conect to them from outside, look at firewall rules. If it is not the case and you can change the default route this way, do it. If it is not the case and you cannot change the default route, you'll have to add a src-nat rule to the internet-facing RB, causing the packets towards the panels which come from the internet to be src-nated to the LAN IP of the internet-facing RB.

I am able to mac-telnet from the 3011 to the QRT panels [...]

Enable RoMON and you're set.

https://wiki.mikrotik.com/wiki/Manual:RoMON

Enable RoMON and you're set.

https://wiki.mikrotik.com/wiki/Manual:RoMON

+1

Use non-standard ports for WinBox access to the PTPs. Then it’s just standard NATting to get to them from the internet.



Sent from a $&@#% iPhone using Tapatalk

I did try with offset ports with no success. I mac-telneted into the panels and changed the service port.

I am able to mac-telnet from the 3011 to the QRT panels [...]

Enable RoMON and you're set.

https://wiki.mikrotik.com/wiki/Manual:RoMON

I will check RoMON out, thank you. I have seen it but never looked into it.

Think about both src-address and dst-address of packets in both directions.

The RB connected to internet listens on public address. On this RB, you can set a dst-nat rule to translate e.g. dst-port=48291 to to-addresses=first.panel.ip and to-ports=8291, and another one to translate dst-port=58291 to to-addresses=second.panel.ip and to-ports=8291. This will ensure that the packets from the internet will reach the panels' interfaces. The src-address of these packets will remain the real one. So both panels need to have your internet-facing RB's LAN address a default route's gateway. If that is the case and you cannot conect to them from outside, look at firewall rules. If it is not the case and you can change the default route this way, do it. If it is not the case and you cannot change the default route, you'll have to add a src-nat rule to the internet-facing RB, causing the packets towards the panels which come from the internet to be src-nated to the LAN IP of the internet-facing RB.

Thank you. I suspect it had something to do with the traffic from the panel back to me because when looking at the connections on the gateway I did not see any reply traffic. I will do some testing.