Allow wan -> docker

Installing and Using OpenWrt
1

I have nanopi-r5s as main router. I installed docker, and let's say I have plain caddy container run with:

docker run -d -p 8080:80 caddy

I can access 192.168.0.1:8080 but I want to be able to connect to it from WAN. I already setup ddns so my dns provided points to my wan ip. How to configure firewall to allow incoming connection from WAN to port 8080 pass to caddy container in DOCKER zone to port 8080?

Port forwarding using Firewall -> Port forwards to other devices/services in my lan works as expected. Using Firewall ->Traffic rules works fine if I open port for a service that works on router directly but how to set it up to for a docker container?

2

Are you running OpenWrt (official) or the vendor firmware?

ubus call system board
3

I use vendor firmware, friendlywrt (and waiting for stable release of openwrt for this board).

{
        "kernel": "6.1.25",
        "hostname": "nanopi",
        "system": "ARMv8 Processor rev 0",
        "model": "FriendlyElec NanoPi R5S",
        "board_name": "friendlyelec,nanopi-r5s",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.2",
                "revision": "r23630-842932a63d",
                "target": "rockchip/armv8",
                "description": "OpenWrt 23.05.2 r23630-842932a63d"
        }
}
4

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:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. 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.

1 Like
5

I compared openwrt 23.05.2 and friendlywrt 23.05.2. There are minor differences of course, you can of course see them in the attached patch file. However, I don't think those differences are root cause of this problem.

Unfortunately I don't have any other hardware to verify this issue on stock openwrt. Maybe spawning a VM with x86 openwrt is a good idea to validate it?

6

You should ask your questions on the FriendlyWrt support channels -- they're the ones who know that firmware in-and-out; it is materially different than official OpenWrt and is just a black-box to us.

1 Like
7

You can install OpenWrt on the NanoPi; using FriendlyELEC's firmware isn't necessary.

That said, this issue is reproducible on stock OpenWrt and is a known conflict between fw4 and Docker’s interaction with iptables. You have a couple of options:

  1. Revert to fw3 – If you prefer, you can switch back to fw3 (make sure to back up your fw4 configurations beforehand).

  2. Adjust nft zones – Researching how to add the correct nft zones can help Docker communicate properly with fw4.

Since this is an upstream issue, suggesting someone go to another forum might not be the best approach. Vendors like FriendlyELEC primarily focus on hardware enablement for new SoCs, so the root of the problem lies in the transition from iptables (fw3) to nft (fw4). Many applications haven’t yet been fully adapted to fw4, and mwan3 is another example that requires additional configuration to function properly.

Hope this helps!

8

I see it differently here. FriendlyELEC sold the product and ultimately owns the issue responsibility even if it is an upstream (OpenWrt) issue. It is up to FriendlyELEC to find a way to resolve its customers' problems.