i have a RB3011 Ui as my main switch in my home server rack now if i use my main internet connection the forwarding works 100% ports i normally open works so that part atleast works
bough me a LHGG Cat6 LTE kit to use as a backup and it has unrestricted access as well now it will never be used as a fail over for internet as its a capped service atm but im only using it for remote access purposes if my main link goes down so i can still access my equipment.
LHGG is on 192.168.88.0/24 Range
RB3011Ui is on 192.168.0.0/24 Range
made a route from the lhg to rb3011 so it can see my local devices and natting has been done accordingly
on the logs im getting dstnat: in:lte1 out:(unknown 0)
Recommended practice of the forum, if you post large pieces of configuration inline, put them between [code] and [/code] tags, try to edit your previous post to see the difference.
To the subject, there are two action=dst-nat rules with log=yes, so I assume your log snippet in the OP comes from hitting one of them. The dstnat chain handles the packets before they get routed, so it is normal that at that moment, the out-interface for the packet is not known yet, so the out:(unknown 0) part of the log row says nothing about what really happened to the packet later on.
Since the rest of the LHG configuration is dead simple, the route is there (but no static DHCP lease for the 3011 so you may get some surprise after a reboot if the 3011 is not the only device to be connected to ether1 of the LHG), and the filter rules in chain forward allow dst-nated connections to get established, I’m sure the initial packet has actually made it to the 3011. To confirm this, you can run /tool sniffer quick port=9987 (or 3389, depending on which of the two dst-nat rules you’ll use to test) on the LHG while testing the remote access, and you should see the initial packet to enter via lte1 and leave via ether1, dstnated.
So either the initial packet itself got blocked by 3011’s firewall, or the 3011 has routed the response to it somewhere else than to the LHG.
It’s not jumping back and forward, look at the MAC addresses. The packet comes in via ether10 with the source MAC address of the LHG and destination MAC address of the 3011; the 3011 routes it to the destination and sends it via ether1 with its own MAC address as source. But nothing ever comes back from the destination server at DC:A6:32:DF:EA:3A. So either the gateway of the default route of the server at DC:A6:32:DF:EA:3A is not the 3011, or the firewall/application settings on that server block incoming requests from the internet (public IPs).
I’ve got no idea why the packets come in pairs, but that’s a separate question that may not be important at all.
Also, make the terminal window as wide as your screen allows before sniffing; the sniffer adjusts the number of columns displayed to accommodate to the available window width, so the IP addresses are missing.
all of the devices connected to the RB3011 has the 3011 as the gateway, mac that ends with 3A happens to be the device i was testing the access to. only works with my main wan link .
the only diff is i do not have a 0.0.0.0/0 route for the LHG as im not using it for my internet only want to be able to use it for remote access.
Just to be clear then you are:
a. accessing your servers from external internet via normal port forwarding to manage them.
b. not accessing the router directly from the external internet for configuration purposes.
But that’s not what most people understand under the name “cloud access”. The Tik registers its public IP into the DynDNS, and you then access this address directly (or via dst-nat if the xxx.sn.mynetname.net is the one of the 3011, not of the LHG).
Cloud access means that the device, which may not be accessible via any public IP at all, actively connects to a cloud server, and you can access the device via that cloud server, typically identifying it by something else than an IP address.
What sindy was trying to politely say, which I will say directly.
MT CLOUD is your public IP address or more accurately is used to determine your public IP, and is used for various purposes of troubleshooting, identifying public IP if behind a private IP etc…
It is NOT used for the purposes of direct (non encrypted access) configuration of the router from external IP addresses.
CLOUD ACCESS, is typically used because a system behind your router needs to provide information to a website
(such as my solar system, or my septic system) in a one way directional feed that is secure. Folks can read the information on the website but have no access to the device behind the router.
Last question. How do you access your router for configuration purposes, when away from (aka not behind the router)… Winbox from a laptop, from smartphone?
post your firewall rules to see if they are secure!