Hi all,
The device needs to forward to one of three devices depending on the value incoming port. Forwarding to the first to-address (192.168.20.2) works as expected, the other two doesn’t. I can ping all the addresses from the router.
Here is the configuration:
[admin@MikroTik] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=masquerade out-interface-list=WAN
I’m trying to get access from the WAN. @Jotne: Apologies, will run with /export hide-sensitive next time. Rest assured, though, I did anonymise the data.
That’s not a matter of apology, the point is the following: you have a mistake somewhere in your configuration. The dst-nat part itself is OK, and the filter part of the firewall is totally empty which is not OK for production deployment but it means that the issue is not caused by some rule in the filter. Ergo the mistake is somewhere else in the configuration, but it is not possible to say where if you don’t show the whole configuration.
The mistake may be also outside the Tik, so the first thing I would do would be to run /tool sniffer quick port=xxxx and try to access port xxxx from outside. I don’t know whether you’ve used the real port numbers in your example - it would be surprising if your ISP was blocking two out of three 20xxx ports, but if you actually use different ports, it is possible that the ISP filters some port ranges.
Got it, I initially thought that your command anonymized the addresses. See below.
A few comments:
I can confirm that the issue is not with the ISP, that was my initial suspicion as well.
The line assigning the public address has a bizarre entry (network = gateway.gateway.gateway.gateway -1). I have never seen that address before
I used Winbox for the initial configuration (ip addresses/dns/gateway) and configured port forwarding remotely from the command prompt.
As it’s not an issue with the dst-nat rules either, we have to move further down the line. So run /tool sniffer quick port=22 (without specifying an interface) and see whether the dst-nated packets can be seen on any interface as you try to access the ports from outside. The issue may also be a missing default route on some of the connected devices in 192.168.20.0/24 - if so, they can respond to pings coming from the same subnet (where no gateway is necessary), but cannot send anything to destinations outside this subnet.
There are two terms associated to a subnet - a network address (with all bits set to 0 where the corresponding bits of the mask are 0) and a broadcast address (with all bits set to 1 where the corresponding bits of the mask are 0). For a /26 mask, there are 4 possible values of the last byte of the IP address:0, 64, 128, 192. So If your network address is in accord with this, nothing to worry about - but if so, you’ve obfuscated the address in a wrong way because both your own address and the gateway address have the last byte .1, which is likely not the case.
Other than that - unless there is some other firewall between your CRS and the internet, you should export (not backup) the configuration, save it somewhere else, and netinstall the device as soon as possible. Because you have connected it to the internet without setting up a firewall to protect even the device itself (using rules in /ip firewall filter chain=input) from access via WAN, nor have you restricted access to the management services (telnet, winbox, ssh, http…) to an IP address range using the /ip service settings, so it may easily be infected by malware by now.
Yep, I ran sniffer tool and there is no traffic from the other devices. I suspect you’re spot on identifying a routing issue: the other devices have access to two WANs and I suspect the configuration is not optimal. I’ll confirm in a little while.
The router has been behind a firewall all the time but I would love to learn how to configure the device firewall and disable the wan configuration option, is there a resource you can recommend I can use?