That one way nature makes me believe the device at 192.168.88.2 doesn’t have the gateway at 192.168.88.1 it’s probably 192.168.88.254.
Been caught like that before it’s pretty evident 192.168.88.2 isn’t sending anything back to the Tik and so 192.168.88.1 is probably not the gateway.
__
Yeah, read all that and it didn’t help me… Will let you guys know the results in a couple of weeks when I go back to site.
If it didnt help then you have not grasped other fundamentals… It takes time, dont feel like you are not like the rest of us, save a few here that are actually IT trained and eat magic mushrooms.
- Dont use quickset other than to set the initial mode of the device (example wisp mode for wifi devices such as capac).
- Use safe mode button all the time
- keep copies of your config when you make a batch of changes!!!
- When setting up the router, try to keep one port separate, for an OFF bridge access, as it is often errors in bridge setups that causes lockups and start overs!!
As far as port forwarding thinking of it this way.
Traffic is heading to your router or more accurately your routers public IP
It is either going to the router itself - and thus an input chain rule, actually mostly just initial connections for VPNs.
Everything else is one of two things
a. return traffic from requests originated on the LAN of the router (like www internet stuff). → This is handled by firewall rules mostly (admin allowed traffic to exit the wan in the forward chain)
b. less common is external originated traffic headed for the LAN. ( this is handled in NAT rules)
c. With one exception, we have one rule in forward chain to allow dst-nat type traffic.
/ip firewall filter
add action=accept chain=forward comment=“allow internet traffic” in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment=“allow port forwarding” connection-nat-state=dstnat
add action=drop chain=forward
You should note that we do not distinguish where this traffic is coming from because many times admin want local users to access a server via the WANIP of the router.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The link you noted as didnt understand is simply explaining a couple of things:
1 - the fact that depending upon the nature of the WANIP connection, static or dynamic, some settings are different.
UNDERSTAND THIS FIRST before thinking about hairpin nat. In fact many of the different methods being described are simply ways one can do basic port forwarding on a dynamic WANIP when local users are forced to use the the WANIP of the router vice the lanip of the server. In other words the basic default premise on the all the port forwarding rules dst line of 'IN-INTERFACE (or -LIST)" = WAN, is just not good enough.
2 - hairpin nat is a special case where users on the SAME LAN subnet as the server are required to access the server by the WANIP of the router.
- just use LANIP I say
- put the server on a different subnet I say…
Otherwise a simple sourcenat rule allows us to bypass the hairpin nat scenario. Often called the hairpin nat rule.
Whether you understand exactly how hairpin sourcenat rule bypasses issues, is not all that important at the moment but in time you can work it out.
Posting your latest full config minus serial number and any public wanip info, is conducive to getting help!! Networks diagrams are good to.
o
Full config attached to original post… not sure how giving you my public IP will help… network is pretty simple… Internet ↔ Chateau 5g ↔ server on LAN
Phew… Long post… Let me try to write a succinct response and stick to the facts:
- I am “IT trained” as you put it. I configured my first Cisco kit in 1995 and haven’t stopped being a “techie” since then.
- I understand everything in the (very good) article you pointed me at. There are no mysteries here for me. Hairpin NAT is irrelevant to my scenario.
- Yes! I did at first try to use “Quick Set” in Winbox, thinking this is a relatively straightforward activity and assuming that this functionality in RouterOS would actually work out-of-the-box on an out-of-the-box router. When it didn’t work, I resorted to the KB article from Mikrotik to set up the forward. Which I also understood, by the way, and which also made complete sense to me.
Thanks a lot for the other hints and tips, they are gratefully received.
If you really want to help, take a look at the config in the original post and tell me why this will not port forward from the internet, to a web server on an internal network.
I did, nothing in your config is incorrect. 
My guess is something is funky on that server (some local firewall or network setting or something).
Other than that the only conclusion is you dont have a reachable public WANIP or your ISP is blocking port 81…
The only other thing to try would be a fresh install, use netinstall of v7.6 and put the config back in and try. This has been known to fix unexplained blockages in other threads
telnet ddnsname 1194 to the router when running openvpn works… Hence publicly routable IP
Played with Port Address Translation and set external port as 8081 to rule out ISP blocking low ports…
Good to know that somebody with some Mikrotik experience looked at my config and there isn’t anything stupid or missing in there.
May try the reinstall…
This still seems to be a problem. I am using a Chateau 5G with v7.6 as UE in a Nokia 5G SA cell(no CGNAT, all private IPv4). The Chateau was configured as a VXLAN VTEP to allow L2 connection, this works fine. When I configure UDP forwarding to an internal VTEP the described problem occurs. Simple firewall filter with action accept does not catch packets on the lte1 interface, the same with the DNAT rule. According to changelog no fix in v7.7 or later.
Is there a workaround?
Probably your mobile provider has a firewall that drops unsolicited incoming traffic to protect you, your bill, and them from the background noise on internet that would make you complain about paying for traffic you did not want.
Just for awareness the reinstall didn’t work and 2 brand new Mikrotik Chateau 5G’s have been in a Malaysian landfill for the past few months… Good luck!
Some mobile providers can filter incoming connections for some standard internet services, like for http 80, 81, 443, 8080, 8081 even if you have public IP.
I’m also on LTE internet connection (4G) using Chateau LTE12 and I had to contact my ISP to assign me public IP (not static) without filtering. They agreed and gave me different APN for such purpose without additional fee.
Did you try to open some nonstandard port?
Try setup port forward to port 34543 and from shell you can open port and response with http protocol body using netcat (or setup on your webserver that port):
echo -e "HTTP/1.1 200 OK\nContent-Length: 47\nContent-Type: text/html\nConnection: Closed\n\n<html><body><h1>It's working</h1></body></html>" | nc -lp 34543
and from browser on computer/mobile phone connected to some other internet connection try to open http://router_public_ip:34543.
In my case, the problem has now been solved. As described, the Chateau is used in a 5G SA network in which no public IPs are assigned. I did a remote session with a customer, the problem occurred, I asked to set the Chateau to factory default and use the latest stable version v7.7. The customer also updated lte1 interface and router board firmware.
Then the DNAT rule was created and it worked as expected. Packet matcher has caught packets, no workaround needed. Cause unknown, that is a bit of a pity…