It would help to post your config so we can see what’s going on.
Also, It would be easier to use the Netmap action, with in-interface specified, to perform port forwarding. This way you won’t have to modify your rule if your external IP changes.
2 D address=–.–.–.–/29 network=–.–.–.-- interface=ether1-gateway
actual-interface=ether1-gateway
/ip route print detail
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
0 ADS dst-address=0.0.0.0/0 gateway=xxx.xxx.xxx.xxx
gateway-status=xxx.xxx.xxx.xxx reachable via ether1-gateway distance=1
scope=30 target-scope=10 vrf-interface=ether1-gateway
already did that, didn’t work. I was suspecting about any firewall rule blocking something, so I disabled all restricting rules just for test… and didn;t worked either.
is there any way to activate some kind of log that tells me what is blocking those connections?
I feel there may be something fundamentally flawed with your testing method. Are you attempting to test it by connecting to the external IP of your router from within your local LAN?
What is the purpose of this line? Are you trying to stop 10.1.3.0/24 traffic from being masqueraded? Since it isn’t going out the gateway interface it wouldn’t be, anyway. Its existence might be stopping traffic from hitting your other rules.
Also, are you using the 192.168.88.0/24 subnet on your network? Your router still has an IP in that range.
You can try setting the ‘log’ flag on all your firewall rules and see if anything pops up. Also, clear your counters and watch if any of the NAT rules have their counters incremented when you try to connect.
I’m out of ideas; I’ve tried your config on my lab setup and everything works fine for me.
You can append “log=yes” to your firewall rule, and optionally “log-prefix=” to apply a prefix to those log entries. “/log print” shows log if you’re using terminal.