NanoPI R5C and NAT Reflection/Hairpin problems

Fijxu · April 8, 2025, 10:37pm

hi. I'm trying to access exposed ports from a machine behind my router via my public IP address on a machine on the same network, but it doesn't seem to work for some reason that I really don't understand how to solve at this point. The ports are successfully exposed to the internet, but I can't just access them trough LAN using my own public IP. I already tried:

Enable promiscuous mode on br-lan and lan (separately)
Switch between "Use internal IP address" and "... external ..." on the port forwardings (/cgi-bin/luci/admin/network/firewall/forwards)
Set reflection zones to lan and wan, only lan and only wan. None of those 3 options worked.

On the br-lan lan configuration at /cgi-bin/luci/admin/network/network (Devices tab), I also did this:

Accept Local: enabled and disabled, they don't change anything.
Enable promiscuous mode: enabled and disable, didn't change anything either.

After setting promiscuous mode, I restarted the router just to try, that didn't fix it either.

The only way I'm able to solve this problem is by setting the device of the lan interface to eth1 (the lan port) instead of br-lan

But that comes with another problem. I can't bind it to the wifi interface.

running nft list ruleset outputs:

...
	chain dstnat_lan {
		ip saddr 192.168.1.0/24 ip daddr 186.107.238.209 tcp dport 80 dnat ip to 192.168.1.3:80 comment "!fw4: asd4 (reflection)"
		ip saddr 192.168.1.0/24 ip daddr 186.107.238.209 tcp dport 443 dnat ip to 192.168.1.3:443 comment "!fw4: asd3 (reflection)"
		ip saddr 192.168.1.0/24 ip daddr 186.107.238.209 tcp dport 52200 dnat ip to 192.168.1.3:52200 comment "!fw4: asd2 (reflection)"
		ip saddr 192.168.1.0/24 ip daddr 186.107.238.209 tcp dport 52220 dnat ip to 192.168.1.3:52220 comment "!fw4: asd (reflection)"
	}

	chain srcnat_lan {
		ip saddr 192.168.1.0/24 ip daddr 192.168.1.3 tcp dport 80 snat ip to 192.168.1.1 comment "!fw4: asd4 (reflection)"
		ip saddr 192.168.1.0/24 ip daddr 192.168.1.3 tcp dport 443 snat ip to 192.168.1.1 comment "!fw4: asd3 (reflection)"
		ip saddr 192.168.1.0/24 ip daddr 192.168.1.3 tcp dport 52200 snat ip to 192.168.1.1 comment "!fw4: asd2 (reflection)"
		ip saddr 192.168.1.0/24 ip daddr 192.168.1.3 tcp dport 52220 snat ip to 192.168.1.1 comment "!fw4: asd (reflection)"
	}

	chain dstnat_wan {
		meta nfproto ipv4 tcp dport 80 counter packets 8304 bytes 449380 dnat ip to 192.168.1.3:80 comment "!fw4: asd4"
		meta nfproto ipv4 tcp dport 443 counter packets 145982 bytes 7844533 dnat ip to 192.168.1.3:443 comment "!fw4: asd3"
		meta nfproto ipv4 tcp dport 52200 counter packets 3 bytes 156 dnat ip to 192.168.1.3:52200 comment "!fw4: asd2"
		meta nfproto ipv4 tcp dport 52220 counter packets 2 bytes 104 dnat ip to 192.168.1.3:52220 comment "!fw4: asd"
	}
...

I don't care about the public ip being exposed

It clearly says that the ports are being reflected from the public ip address to the target machine with the port forwarding, but it still doesn't work...

Any clues?

brada4 · April 8, 2025, 10:47pm

What is the original non-working rule from /etc/config/firewall?
And the output if ubus call system board ?
What is the point of 20 changes described here?

Fijxu · April 8, 2025, 10:58pm

config defaults
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'DROP'
	option synflood_protect '1'
	option drop_invalid '1'
	option flow_offloading '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone
	option name 'wan'
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'DROP'
	option fullcone4 '1'
	option fullcone6 '1'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'

config forwarding
	option src 'lan'
	option dest 'wan'

=== TRIMMED DEFAULT `config rule` RULES ===

config redirect
	option dest 'lan'
	option target 'DNAT'
	option name 'asd4'
	list proto 'tcp'
	option src 'wan'
	option src_dport '80'
	option dest_ip '192.168.1.3'
	option dest_port '80'

config redirect
	option dest 'lan'
	option target 'DNAT'
	option name 'asd3'
	list proto 'tcp'
	option src 'wan'
	option src_dport '443'
	option dest_ip '192.168.1.3'
	option dest_port '443'

config redirect
	option dest 'lan'
	option target 'DNAT'
	option name 'asd2'
	list proto 'tcp'
	option src 'wan'
	option src_dport '52200'
	option dest_ip '192.168.1.3'
	option dest_port '52200'

config redirect
	option dest 'lan'
	option target 'DNAT'
	option name 'asd'
	list proto 'tcp'
	option src 'wan'
	option src_dport '52220'
	option dest_ip '192.168.1.3'
	option dest_port '52220'

{
	"kernel": "6.1.99",
	"hostname": "meow",
	"system": "ARMv8 Processor rev 0",
	"model": "FriendlyElec NanoPi R5C",
	"board_name": "friendlyelec,nanopi-r5c",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.0",
		"revision": "r28427-6df0e3d02a",
		"target": "rockchip/armv8",
		"description": "OpenWrt 24.10.0 r28427-6df0e3d02a",
		"builddate": "1738624177"
	}
}

Being able to access to my public ip address exposed ports from my LAN devices
Most of those changes come from different post recommending those type of changes to be able to fix it, but none of them worked.

brada4 · April 9, 2025, 2:25am

That is not OpenWrt, ask help where you got software from

psherman · April 9, 2025, 2:27am

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

Fijxu · April 9, 2025, 3:04am

I would like to do it, but FriendlyWRT forums are literally dead and official support for the NanoPI R5C is still experimental (I forgot to mention that I'm using FriendlyWRT in the first place, sorry)

I don't think FriendlyWRT differs that much from OpenWRT when it comes to network configuration. My old router which uses OpenWRT, uses almost the exact same configuration when comparing it to the configuration that I made on this FriendlyWRT router.

I'll try installing upstream OpenWRT on this NanoPI instead, otherwise, I don't think I will be ever able to get support

psherman · April 9, 2025, 3:08am

I believe that it can be substantially different, especially because the friendlywrt firewall has stuff that doesn’t exist on openwrt.

If the friendlywrt forums are mostly dead, probably best not to be running firmware from there. Fortunately, the device is fully supported by 24.10.

brada4 · April 9, 2025, 3:09am

Install OpenWrt before "thinking' again.

Fijxu · April 9, 2025, 5:50am

Problem solved by using OpenWRT instead of FriendlyWRT. I thought FriendlyWRT was going to be better because it was the one coming from the manufacturer and the https://openwrt.org/toh/friendlyarm/nanopi_r5c said "OpenWrt does not yet have official support for the R5C as it does the R4S."

But latest snapshot just works fine. I didn't have to touch any settings for NAT Reflection to work, as expected.

Thanks!

frollic · April 9, 2025, 6:17am

that line's gone now.

brada4 · April 9, 2025, 8:24am

Friendlywrt has fullcone firewall patch, likely from immortalwrt or close.
It glitches when you deviate too far from one nat home network setup, like flat static routes without nat, or now reflection. If you manage to recreate reflection glitch using x86 vm probably immortalwrt can improve their customisations with clear test case. (dont ask them to help with friendlywrt though)

system · April 19, 2025, 8:24am

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.