Community discussions

MikroTik App
 
ross99999999

Port Forwarding. So Simple. So Difficult.

Sun Oct 23, 2022 9:28 pm

Seems many folks have issues doing something so intuitively simple with Mikrotik devices... Port forwarding.... So trivial, yet so difficult.

Chateau 5G. Out of the box. IP6 disabled. Wireless network disabled. Very vanilla. Not behind any NAT from my ISP.

Reduced the setup to something very simple - web server 192.168.88.2 on TCP 81 on the internal network.

Attached pictures and text file showing config.
NAT Config.jpg
ChateauConfig.txt
Any help from those with more experience of RouterOS or Mikrotik, much appreciated.
You do not have the required permissions to view the files attached to this post.
 
User avatar
loloski
Member Candidate
Member Candidate
Posts: 276
Joined: Mon Mar 15, 2021 9:10 pm

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 2:11 pm

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
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 2:25 pm

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
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 3:57 pm

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 Loloski and thanks for your input.

I think this (default) line in the config takes care of the outbound NAT doesn`t it?

add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

I tried adding an outboud NAT rule explicitly for the 192.168.88.0/24 network to see if it made any difference and it didn't.

Also for awareness, I just checked and can see in the webserver logs, that there is no traffic getting to the server... So this is an "inbound" traffic issue...

And yes, first hop from the web server at 192.168.88.2 is the internal interface of the Mikroitik router on 192.168.88.1

Any more ideas?
Last edited by ross99999999 on Mon Oct 24, 2022 4:50 pm, edited 1 time in total.
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 4:42 pm

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
Hi rextended and thanks for your help!

I have a publicly routable dynamic address from my ISP. I checked this by enabling an openvpn server in the Mikrotik router and telnetting to TCP 1194 using it's external address. Connected without issue.

Attached is a screenshot of the Advanced tab.... Nothing much to see...
AdvancedTab.jpg
Any other ideas?
You do not have the required permissions to view the files attached to this post.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 4:45 pm

Ok, 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
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 4:48 pm

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.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 4:54 pm

@Sob, the NAT rule, if dst-address-list="", probably can't match anything...
I do not know how is possible than the rule can be set with =""


@ross99999999
If you only have those two NAT rules in the export, paste this on the terminal:
/ip/firewall/nat set [find] !dst-address-list
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:12 pm

No, that's not it. If I do quick test with:
/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
and try to connect to port 666, I see both "test-list" and "test-no-list" logged.
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:17 pm

Ok, 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
Yep - greyed out - screenshots in original post
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:21 pm

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.
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)
InInterfaceAll.jpg
You do not have the required permissions to view the files attached to this post.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:24 pm

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...
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:28 pm

@ross99999999
If you only have those two NAT rules in the export, paste this on the terminal:
/ip/firewall/nat set [find] !dst-address-list
[/quote]

Nothing comes back...

[admin@MikroTik] > /ip/firewall/nat set [find] !dst-address-list
[admin@MikroTik] >
[admin@MikroTik] >
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:29 pm

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...
Testing from the internet, not from the internal network.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:31 pm

No about interface list. Nothing selected (option not active) means no restriction, any interface is allowed. You can't improve that.
 
User avatar
loloski
Member Candidate
Member Candidate
Posts: 276
Joined: Mon Mar 15, 2021 9:10 pm

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:34 pm

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
/tool/fetch http-method=get url=http://192.168.88.2 port=81
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:43 pm

No, that's not it. If I do quick test with:
/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
and try to connect to port 666, I see both "test-list" and "test-no-list" logged.
Nothing logged and no traffic
NothingLoggedAndNoTraffic.jpg
You do not have the required permissions to view the files attached to this post.
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 5:54 pm

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
/tool/fetch http-method=get url=http://192.168.88.2 port=81

[admin@MikroTik] > /tool/fetch http://192.168.88.2/index.html
status: failed

failure: closing connection: <connection failed> 192.168.88.2:80 (5)
[admin@MikroTik] > /tool/fetch http://192.168.88.2:81/index.html
status: finished
downloaded: 0KiBC-z pause]
total: 0KiB
duration: 1s

[admin@MikroTik] >
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 6:07 pm

No, sorry for confusing you, that one with port 666 was for @rextended. You can try this:
/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
And you should see this in log:
port-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, ...
#1 - request from client c.c.c.c comes to public address p.p.p.p
#2 - packet is passing through router after dstnat
#3 - packet successfully passed through router and is being sent to server
#4 - response from server
#5 - response passing through router
#6 - response being sent to client

If you don't see #1, then requests are not reaching your router at all. If you don't see #4, then internal server is not responding.
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Mon Oct 24, 2022 9:14 pm

Thanks everybody - really appreciate the time and effort from you guys here.

Ultimately, the most simple of router configuration (port forwarding) doesn't work on this device when an out-of-the-box device is configured exactly according to the KB article of the manufacturer, which I must say, makes complete sense to me. I took a "punt" with Mikrotik for the first time (usually run Teltonika kit or something with OpenWRT) and it bit me. Burned more money in terms of time trying to do the most basic of thing than this hardware is worth.

Am now away from the customer site for two weeks, having caused quite some serious delay to the project. Something that should have taken 5 minutes, wasted a day and half in head scratching.

When I go back on site, I could spend more time (money) digging into this to find the cause of the issue.... But I wont. I will very quickly try and make this Chateau 5G a simple bridge, stick a (proper) firewall behind it and just use the modem (which is actually the best and really only great feature of this product). If it wont bridge after 10 mins, it will go in the bin (actually 2 of them because we bought another for redundancy) and I will use something that I know will be up and running within half an hour.

But again, to everybody who offered suggestions, I really appreciate it.
 
LdB
Member Candidate
Member Candidate
Posts: 141
Joined: Thu May 20, 2021 4:23 pm

Re: Port Forwarding. So Simple. So Difficult.

Tue Oct 25, 2022 9:13 am

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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Port Forwarding. So Simple. So Difficult.

Tue Oct 25, 2022 11:50 pm

 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Wed Oct 26, 2022 7:54 pm

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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Port Forwarding. So Simple. So Difficult.

Wed Oct 26, 2022 10:09 pm

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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Port Forwarding. So Simple. So Difficult.

Wed Oct 26, 2022 10:28 pm

Posting your latest full config minus serial number and any public wanip info, is conducive to getting help!! Networks diagrams are good to.
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Thu Oct 27, 2022 3:19 am

o
Posting your latest full config minus serial number and any public wanip info, is conducive to getting help!! Networks diagrams are good to.
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
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Thu Oct 27, 2022 3:37 am

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.
Phew... Long post... Let me try to write a succinct response and stick to the facts:

1. 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.
2. 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.
3. 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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Port Forwarding. So Simple. So Difficult.

Thu Oct 27, 2022 4:19 am

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
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Thu Oct 27, 2022 4:25 am

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...
 
nilsk
just joined
Posts: 4
Joined: Wed Jan 03, 2018 9:49 am

Re: Port Forwarding. So Simple. So Difficult.

Fri Feb 03, 2023 10:46 am

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?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Port Forwarding. So Simple. So Difficult.

Fri Feb 03, 2023 11:09 am

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.
 
ross99999999

Re: Port Forwarding. So Simple. So Difficult.

Fri Feb 03, 2023 4:00 pm

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?
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!
 
optio
Long time Member
Long time Member
Posts: 655
Joined: Mon Dec 26, 2022 2:57 pm

Re: Port Forwarding. So Simple. So Difficult.

Sat Feb 04, 2023 10:39 pm

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.
 
nilsk
just joined
Posts: 4
Joined: Wed Jan 03, 2018 9:49 am

Re: Port Forwarding. So Simple. So Difficult.

Mon Feb 06, 2023 9:57 am

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?
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...

Who is online

Users browsing this forum: Briancer, gigabyte091, GoogleOther [Bot] and 54 guests