Hi Loloski and thanks for your input.two things ensure you have NAT/Masquerade rule for 192.168.88.0/24 going to WAN and your host 192.168.88.2 its next-hop / default gateway is your mikrotik router
Hi rextended and thanks for your help!You sure you have one public IP address for your own?
Usually on 5G are all shared IPs until you do not pay some extra for have your own Public IP...
you have dst-address-list="" on test forward, check if on "Advanced" tab you do not have leaved the dst. address list filed enabled and empty.
if you set that field enabled and empty, no one IP match the empty dst-address-list and the rule not work
/ip/firewall/nat set [find] !dst-address-list
/ip firewall mangle
add action=log chain=prerouting dst-address-list="" dst-port=666 log-prefix=test-list protocol=tcp
add action=log chain=prerouting dst-port=666 log-prefix=test-no-list protocol=tcp
Yep - greyed out - screenshots in original postOk, in the export is v7, my fault to not remember it, everytime specify RouterOS version.
Check on "General" if dst.address list is "white" or "gray" like src address list.
Must be gray, click on the arrow up at the end
With In. Interface List set to WAN, zero traffic. But... If I change this to "all", I seem to see traffic that matches this rule.... But again, it never gets to the server (nothing in the logs)Rules have counters that increase with each matching packet. How are yours? If zero, then no such packets are coming. If non-zero, then there are such packets and since there doesn't seem to be anything in your config that would block them, next thing to check would be the target internal server.
/ip/firewall/nat set [find] !dst-address-list
Testing from the internet, not from the internal network.Ok, you try with a smartphone outside your network, for example with LTE (and wifi off) or you testing the NAT inside your network?
Probably the answer is inside the question...
/tool/fetch http-method=get url=http://192.168.88.2 port=81
Nothing logged and no trafficNo, that's not it. If I do quick test with:
and try to connect to port 666, I see both "test-list" and "test-no-list" logged.Code: Select all/ip firewall mangle add action=log chain=prerouting dst-address-list="" dst-port=666 log-prefix=test-list protocol=tcp add action=log chain=prerouting dst-port=666 log-prefix=test-no-list protocol=tcp
if the rule hits, out of curiosity can you visit http://192.168.88.2:81 or can you use /tool/fetch from the router to check if the port is open post the output here
Code: Select all/tool/fetch http-method=get url=http://192.168.88.2 port=81
/ip firewall nat
add chain=dstnat dst-address-type=local protocol=tcp dst-port=81 action=dst-nat to-addresses=192.168.88.2
/ip firewall mangle
add chain=prerouting connection-mark=debug-pf action=log log-prefix=port-forward
add chain=prerouting connection-state=new dst-address-type=local protocol=tcp dst-port=81 action=mark-connection new-connection-mark=debug-pf log=yes log-prefix=port-forward-NEW passthrough=yes
add chain=forward connection-mark=debug-pf action=log log-prefix=port-forward
add chain=postrouting connection-mark=debug-pf action=log log-prefix=port-forward
#1 - request from client c.c.c.c comes to public address p.p.p.pport-forward-NEW prerouting: in:lte1 out:(unknown 0), ..., proto TCP (SYN), c.c.c.c:xxx->p.p.p.p:81, ...
port-forward forward: in:lte1 out:bridge, ..., proto TCP (SYN), c.c.c.c:xxx->192.168.88.2:80, NAT c.c.c.c:xxx->(p.p.p.p:81->192.168.88.2:80), ...
port-forward postrouting: in:lte1 out:bridge, ..., proto TCP (SYN), c.c.c.c:xxx->192.168.88.2:80, NAT c.c.c.c:xxx->(p.p.p.p:81->192.168.88.2:80), ...
port-forward prerouting: in:bridge out:(unknown 0), ..., proto TCP (SYN,ACK), 192.168.88.2:80->c.c.c.c:xxx, NAT (192.168.88.2:80->p.p.p.p:81)->c.c.c.c:xxx, ...
port-forward forward: in:bridge out:lte1, ..., proto TCP (SYN,ACK), 192.168.88.2:80->c.c.c.c:xxx, NAT (192.168.88.2:80->p.p.p.p:81)->c.c.c.c:xxx, ...
port-forward postrouting: in:bridge out:lte1, ..., proto TCP (SYN,ACK), 192.168.88.2:80->c.c.c.c:xxx, NAT (192.168.88.2:80->p.p.p.p:81)->c.c.c.c:xxx, ...
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.
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 LANPosting your latest full config minus serial number and any public wanip info, is conducive to getting help!! Networks diagrams are good to.
Phew... Long post... Let me try to write a succinct response and stick to the facts: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.
1. Dont use quickset other than to set the initial mode of the device (example wisp mode for wifi devices such as capac).
2. Use safe mode button all the time
3. keep copies of your config when you make a batch of changes!!!
4. 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.
telnet ddnsname 1194 to the router when running openvpn works... Hence publicly routable IPI 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
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!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?
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
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.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?