Router Cascade Port Forwarding Issue

apo440 · February 3, 2024, 9:24am

Probably been asked & solved 10e7 times, but I can't find the right posts/threads, sorry.
Problem: need to forward public port 80&443 to a machine behind primary router (fritzBox, latest FritzOS) and then behind a 2nd router running openWRT. It used to be simple and working until I changed from a dated model (running openWRT) to a more recent box, where I had to re-configure all from scratch. Now can't see where I'm wrong.

Setup:
ISP(DSL) <-> FritzBox:LANx <-LAN1-> WAN:OpenWRT-Box:LANx <-LAN2-> Server (running VMs).
IP on DSL side is a "real" public one.
Fritzbox:LANx has IP 10.0.0.1
LAN1 uses 10.0.0.x/24 addresses.
OpenWRT-Box WAN IP is 10.0.0.2
OpenWRT-Box LANx IP is 10.0.10.1
LAN2 uses 10.0.10.x/24 addresses.

On OpenWRT-BOX, I have ports open in the firewal for different 10.0.10.x IPs (VMs).
Clients on LAN1 can access services on the VMs, i.e. the ports opened on WRT-Box are working IF the request comes from a machine on the WAN side of WRT-Box.

When I forward a port on the FritzBox to the WAN IP of OpenWRT-Box (for accessing its luci config interface), that does work, i.e. I can then access OpenWRT-LUCI from the outside world. So, the port-forwarding on the FritzBox works as expected.

When I forward a port on the FritzBox to an IP on LAN2, i.e. one of the VMs behind OpenWRT-Box, that does NOT work, I can't reach through OpenWRT-BOX (which I can if the request comes from a client on LAN1). I don't see how OpenWRT-Box can block forwards coming from FritzBox whilst not blocking the same request coming from a client on LAN1. Shouldn't openWRT-Box be indifferent whether the request comes from 10.0.0.1 (fritzBox) being an external request forwarded by FritzBox or the request coming from e.g. 10.0.0.123 being another client on LAN1?

Hope you get my problem. Probably a simple tick box somewhere...?

Mijzelf · February 3, 2024, 11:07am

From LAN1 you can directly access a device in LAN2? How does the device in LAN1 know the request has to go to the OpenWRT router?
If you access the device in LAN2 by accessing a forwarded port on the OpenWrt router, the FritzBox has to do the same. Forward to the WAN interface of the OpenWrt box, to the forwarded port.

mk24 · February 3, 2024, 2:26pm

If you're running NAT in both routers, you will need to forward twice. First from the Internet to the wan port of the OpenWrt router, then inside the OpenWrt router from its wan to the server on its lan.

It is better to set up symmetric routing in the house so the packets only NAT once. In the Fritzbox, install a static route: 10.0.10.0/24 via 10.0.1.2. Then in OpenWrt firewall, turn off Masquerading on the wan, and allow forwarding wan->lan (in addition to the default lan->wan). Now a Fritzbox rule can forward directly to 10.0.10.123 since it knows how to reach the 10.0.10.0 network.

If you want to block 10.0.1.0 devices from reaching the 10.0.10.0 network, a more specific firewall rule can replace the overall wan->lan forward.

apo440 · February 3, 2024, 3:36pm

FritzBox already has a "static route" entry (should have mentioned that, sorry guys) for 10.0.10.x/24 (=LAN2) via 10.0.0.2 (=WAN Port of OpenWRT box). That works flawlessly, all services on 10.0.10.x machines can be reached from 10.0.0.x machines.

Then in OpenWrt firewall, turn off Masquerading on the wan, and allow forwarding wan->lan (in addition to the default lan->wan).

Guess you are referring to this tick box for the WAN interface on the "Network>Firewall" page? That was ticked, have disabled it now, no change...

I'm generally blocking WAN=>(anywhere), and then have under Network>Firewall on the TrafficRules tab individual ports open for dedicated destination IPs on the 10.0.10.x ("LAN2") network. This one should do the job (as it does for clients on the LAN1 / 10.0.0.x network of the FritzBox):

mhhhmm??

egc · February 3, 2024, 3:42pm

Did you reboot?

On the Fritzbox did you port forward to 10.0.10.104?

Just some wild guesses, maybe the Fritzbox does not allow port forwarding to something outside its subnet?

Can you do an iptables -vnL -t nat and iptables -vnL FORWARD on the fritzbox?

apo440 · February 3, 2024, 4:02pm

Rebooted openWRT box (after changing the masq tick box in "FW zones" settings) and fritzBox (just to be sure).

Yes, on the FB I do explicitly fwd the respective port (e.g. 22, for testing with plain ssh) to the particular target IP 10.0.10.104.

For the "wild guessing": no, it (the FB) does allow that. I had this setup running with the old router (openWRT on dated hardware) before. I know that it works, because every 3 months the let'sEncrypt certificate for that host .10.104 expired, and as I don't permanently expose it to the outside world, I then had to activate the forward rules on the fritzbox, did "certbot renew" on that .104 VM, and after it completed, closed (deactivated) the forward rules on the fritzbox again. Done that for years... then swapped the openWRT box less than 3 M ago and broke something

Edit: Nope, can't run any shell commands on the fritzbox, there's no SSH or telnet running on those with their stock firmware (and I stopped hacking those years ago because they are "good as they are" for me).

psherman · February 3, 2024, 4:28pm

What is the OS that is running the server on 10.0.10.104? Windows in particular, but some other OS's as well, will block connection attempts from outside the host's subnet. So check that the local firewall on that host allows those connections. A good quick test is to see what happens when you have a device on the upstream (Fritz) lan and attempt to connect to that host (then you are only dealing with 2 variables -- the OpenWrt config and the host config behind OpenWrt; the internet and port-forwarding is no longer in play for this test).

If that doesn't help, try re-enabling masquerading and set the FB port forward to the wan address of the OpenWrt router (which will be on the FB's lan subnet).

apo440 · February 3, 2024, 4:45pm

Ubuntu 22.04 on those VMs mostly.
As per my original post: Clients on LAN1 (FritzBox's LAN; 10.0.0.x/24 subnet) have no problem connecting to 10.0.10.x/24 machines. I.e., 10.0.10.104 definitely answers any requests coming from the WAN side of the openWRT box - IF those requests come from hosts on the FritzBox LAN. ONLY not when the requests originate from a FritzBox "port forwarding" aiming directly for the 10.0.10.104 VM's IP.

IF I configure the FritzBox to forward to the openWRT WAN IP, then I won't need a firewall rule ("let traffic for destination 104 port 22 through"), but a port forwarding rule ("traffic on WAN port, TCP port 22 shall be diverted not to localhost=openWRTBOX, but 10.0.10.104") on the openWRT box. That's not what I want. As all the firewall port rules work from LAN1 (FritzBox Lan) to LAN2 (openWRT Lan) for the various VMs and Services they offer, I don't want to change that.

As said, the setup worked on that old openWRT box - it must have been different in a nuance, but I can't re-construct which.

Oh, another thing: When I de-activate masquerading, I can't ping from LAN2 behind openWRT to the outside world any longer!?
Masquerading ENABLED:

PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=243 time=20.1 ms

Masquerading DISABLED:

PING www.ct.de (193.99.144.85) 56(84) bytes of data.
From XX.X.XX.XXX icmp_seq=1 Packet filtered

The X'ed IP is my current public IP on WAN port of the FritzBox

psherman · February 3, 2024, 4:50pm

let's take a look at the relevant config files:

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/firewall

apo440 · February 3, 2024, 5:19pm

Here we go.
ubus:

root@GL-AR750S:~# ubus call system board
{
        "kernel": "5.15.134",
        "hostname": "GL-AR750S",
        "system": "Qualcomm Atheros QCA956X ver 1 rev 0",
        "model": "GL.iNet GL-AR750S (NOR/NAND)",
        "board_name": "glinet,gl-ar750s-nor-nand",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.0",
                "revision": "r23497-6637af95aa",
                "target": "ath79/nand",
                "description": "OpenWrt 23.05.0 r23497-6637af95aa"
        }
}

and network:

root@GL-AR750S:~# cat /etc/config/network

config interface 'loopback'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'
        option device 'lo'

config globals 'globals'
        option ula_prefix 'fdf1:3ea8:72ac::/48'

config interface 'lan'
        option proto 'static'
        option ip6assign '60'
        option hostname 'GL-AR750S-24e'
        option device 'br-lan'
        list ipaddr '10.0.10.1/24'
        list dns '10.0.0.1'

config interface 'wan'
        list comment 'using list comment tag to ensure this comment stays in the config file even if changed through  GUI'
        list comment 'source for this work around: https://forum.openwrt.org/t/can-luci-please-leave-comments-in-config-files/153341'
        list comment 'using option macaddr with the Slate HW Mac but increasing by +1 in last two hex pairs to distinguish MAC for WAN port from the rest'
        list comment 'otherwise, slate seems to be very slow when responding'
        option macaddr '94:83:C4:0F:B3:4F'
        option ipv6 '0'
        option device 'eth0.2'
        option proto 'static'
        option ipaddr '10.0.0.2'
        option gateway '10.0.0.1'
        option broadcast '10.0.0.255'
        option netmask '255.255.255.0'
        option ip4table 'default'
        option force_link '0'
        list dns '10.0.0.1'

config interface 'wan6'
        option proto 'dhcpv6'
        option disabled '1'
        option device 'eth0.2'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '2 3 0t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '1 0t'

config interface 'guest'
        option proto 'static'
        option ipaddr '192.168.9.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option device 'br-guest'

config interface 'wwan'
        option proto 'dhcp'
        option metric '20'
        option auto '0'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config device
        option name 'br-guest'
        option type 'bridge'
        list ports 'guest'

and firewall; Note: several rules are deactivated (option enabled '0'), but left them in for now.

root@GL-AR750S:~# cat /etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '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 output 'ACCEPT'
        option forward 'REJECT'
        option mtu_fix '1'
        option input 'REJECT'
        list network 'wan'
        list network 'wan6'
        list network 'wwan'
        option masq '1'

config rule
        option name 'Allow_dockerhost_access'
        option src 'wan'
        option dest 'lan'
        list dest_ip '10.0.10.106'
        option dest_port '22 80 3333 5984 8080 8081 8100 9443'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option family 'ipv4'
        option target 'ACCEPT'
        list icmp_type 'echo-request'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'
        option enabled '0'

config include
        option path '/etc/firewall.user'
        option reload '1'

config include 'glfw'
        option type 'script'
        option path '/usr/bin/glfw.sh'
        option reload '1'

config zone 'guestzone'
        option name 'guestzone'
        option forward 'REJECT'
        option output 'ACCEPT'
        option input 'REJECT'
        list network 'guest'

config forwarding 'guestzone_fwd'
        option src 'guestzone'
        option dest 'wan'

config rule 'guestzone_dhcp'
        option name 'guestzone_DHCP'
        option src 'guestzone'
        option target 'ACCEPT'
        option proto 'udp'
        option dest_port '67-68'
        option enabled '0'

config rule 'guestzone_dns'
        option name 'guestzone_DNS'
        option src 'guestzone'
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '53'
        option enabled '0'

config rule 'sambasharewan'
        option src 'wan'
        option dest_port '137 138 139 445'
        option dest_proto 'tcpudp'
        option target 'DROP'
        option enabled '0'

config rule 'sambasharelan'
        option src 'lan'
        option dest_proto 'tcpudp'
        option target 'ACCEPT'
        option family 'ipv4'
        list proto 'icmp'
        option dest '*'
        option name 'Allow_Ping_ICMP_outbound'

config include 'gls2s'
        option type 'script'
        option path '/var/etc/gls2s.include'
        option reload '1'

config include 'glqos'
        option type 'script'
        option path '/usr/sbin/glqos.sh'
        option reload '1'

config zone
        option name 'tun0zone'
        option mtu_fix '1'
        option input 'REJECT'
        option forward 'REJECT'
        option masq '1'
        option output 'ACCEPT'

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

config zone
        option name 'VPNtun0'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config rule
        option name 'Allow_Admin_from_WAN'
        list proto 'tcp'
        option src 'wan'
        option dest_port '22 80 443'
        option target 'ACCEPT'

config rule
        option name 'BlockCameras'
        option src 'lan'
        list src_mac 'EC:71:DB:2E:95:F0'
        list src_mac 'EC:71:DB:07:73:EC'
        option dest 'wan'
        option target 'REJECT'

config rule
        option name 'Allow_Ping_to_LAN'
        list proto 'icmp'
        list icmp_type 'echo-request'
        option src 'wan'
        option dest 'lan'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow_ZM_Access'
        option family 'ipv4'
        list proto 'tcp'
        option src 'wan'
        option dest 'lan'
        list dest_ip '10.0.10.100'
        option dest_port '22 80'
        option target 'ACCEPT'

config rule
        option name 'Allow_IOB_Access'
        list proto 'tcp'
        option src 'wan'
        option dest 'lan'
        list dest_ip '10.0.10.102'
        option dest_port '22 80 1880 8080 8081 8082 8200 '
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow_NXC_Access'
        list proto 'tcp'
        option src '*'
        option dest 'lan'
        list dest_ip '10.0.10.104'
        option dest_port '22 80 443'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow_PH_Access_Admin'
        option family 'ipv4'
        list proto 'tcp'
        option src 'wan'
        option dest 'lan'
        list dest_ip '10.0.10.105'
        option dest_port '22 80'
        option target 'ACCEPT'

config rule
        option name 'Allow_PH_Access_DNS'
        option family 'ipv4'
        option src '*'
        option dest 'lan'
        list dest_ip '10.0.10.105'
        option dest_port '53'
        option target 'ACCEPT'

config rule
        option name 'Allow_N_Access_SMB+Duplicati'
        option family 'ipv4'
        list proto 'tcp'
        option src 'wan'
        option dest 'lan'
        list dest_ip '10.0.10.10'
        option dest_port '137 138 139 445 8200'
        option target 'ACCEPT'

config rule
        option name 'Allow_N_Access_Admin'
        list proto 'tcp'
        option src '*'
        option dest 'lan'
        list dest_ip '10.0.10.10'
        option dest_port '22 8006'
        option target 'ACCEPT'

config rule
        option name 'Allow_HTHPMOD_Access'
        option family 'ipv4'
        list proto 'tcp'
        option src 'wan'
        option dest 'lan'
        list dest_ip '10.0.10.11'
        option dest_port '23 4001'
        option target 'ACCEPT'

config rule
        option name 'Block_HTHPMOD_Outbound'
        option src 'lan'
        list src_mac '00:90:E8:04:EC:01'
        option dest 'wan'
        option target 'REJECT'

config rule
        option name 'Allow_NXC_Access_MDLNA'
        option family 'ipv4'
        list proto 'tcp'
        option src '*'
        option dest 'lan'
        list dest_ip '10.0.10.104'
        option dest_port '8200'
        option target 'ACCEPT'

psherman · February 3, 2024, 5:22pm

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.

mk24 · February 3, 2024, 5:27pm

I see now that the OpenWrt box is running VPNs which you didn't mention before.

The problem is probably that when your web server answers a request from the Internet, the reply packet is routed by OpenWrt into a VPN tunnel instead of back out the WAN toward the Fritzbox, which would NAT the reply back to its IP on the unencrypted Internet connection that the request came in on.

If the reply goes through a VPN tunnel and eventually gets a different public IP than the requestor used, it will be lost.

The solution to this is to use policy routing.

apo440 · February 3, 2024, 5:55pm

VPN? Huh? I don't even know where to configure that on the openWRT box. Happy to disable anything related to that, as I don't use it - but where?

And I don't understand how that should be the problem. Requests from clients on the WAN side of the openWRT box do work perfectly fine with the services behind the openWRT box. All they do is access e.g. 10.0.10.104:443 and it works, responses from that service do get back through the openWRT box to the source client. ONLY if the SAME (?) request originates from the FritzBox (as it forwards the request from the internet side to the openWRT box), it fails. What's the difference for Mr. OpenWRT?
(1) Incoming request from .0.123 client on WAN side, reply goes back to it.
Vs.
(2) Incoming request from .0.1 (Fritzbox, but for Mr OpenWRT just another IP, right?) on WAN side, reply... goes into some VPN of Mr OpenWRT?
=> Why would it route the response to .0.123 correctly back, but not to .0.1

Running an official WRT...well, I think I am!? Going through the firmware-selector, searching for my GL-AR750s, and setting the version back to what I'm on (23.05.0), I get to https://mirror-03.infra.openwrt.org/releases/23.05.0/targets/ath79/nand/ and in there the file
openwrt-23.05.0-ath79-nand-glinet_gl-ar750s-nor-nand-squashfs-sysupgrade.bin
which is exactly the file I used to bring this box to what it runs right now (confirmed with the backup of that file I kept in my archives). How could I be more "official"?

mk24 · February 3, 2024, 6:44pm

This packet is not "from the FritzBox". It will have a source IP of the original requestor on the Internet, and a destination of 10.0.10.104 due to DNAT (the destination IP is altered, not the source). This means that the web server will attempt to return the reply to the original requestor's public IP. When it gets back to the Fritzbox, the Fritzbox will find the connection in its DNAT table and de-DNAT the packet by replacing the private source IP with its public IP, then send it to the Internet.

This is no problem if it is simple lan->wan routing, as all destination IPs will go by wan. If there is a defaullt route via a VPN it is likely to go there instead.

Examining the routing tables and doing some packet captures (package tcpdump) should help make this clear.

I see extra zones in the firewall which would not be there in a basic lan-wan router.

psherman · February 3, 2024, 6:49pm

Right... that's because the OP is not using OpenWrt. They are using a gl-inet fork.

@apo440 - you can install official OpenWrt on your device (do not keep settings when you do this).
https://firmware-selector.openwrt.org/?version=23.05.2&target=ath79%2Fnand&id=glinet_gl-ar750s-nor-nand

If you continue to use the existing gl-inet firmware, you need to ask them for help -- the modifications they have made in their fork significantly and materially modify the way that OpenWrt functions.

apo440 · February 3, 2024, 8:30pm

This is no problem if it is simple lan->wan routing, as all destination IPs will go by wan. If there is a defaullt route via a VPN it is likely to go there instead

I don't have any entries under "Network > Routing". Also, I don't know where there's a "VPN" configured anywhere, and hence I have no clue what routing rule should send the return packages (thanks for the explanation btw!) into a VPN Tunnel (that does not exist). Where is that "VPN" you are seeing, and where do I get rid of it?

/Edit1: Do you mean these two lines under "Network > Firewall" down under "Zones"?

I've deleted those now and rebooted the box. No change.
/Edit1/

Under "Status > Routing" I see only this:

Sorry, I don't get it.
I use the firmware selector, type in GL-AR750s, and get the following options to chose from regardless of the 23.05.0 or 23.05.2 version setting.

I then click on the "NOR/NAND" version and get a page like this:

On there, I follow the "folder" Icon to get to all available files for that version (23.05.0 in my case).
And from there, I chose glinet_gl-ar750s-nor-nand-squashfs-sysupgrade.bin
What's different in the link/way you are telling me? I just don't get it, where is that not the "official" OpenWRT thing, aren't you sending me to the exact same place, only for the .2 version?
Also, going through the "folder" icon as I do and picking the file myself gives me the same file I'd get using the "sysupgrade" button on those pages.

Sorry if I'm too blind and or too stupid to see the difference, but I have no clue how that's supposed to be a "fork". What tells you that I'm on a "fork"?

psherman · February 3, 2024, 8:42pm

You should select 23.05.2. But my bigger point is that the version of firmware currently on your device was provided by gl-inet (or if you did install official OpenWrt, you must have kept settings from the gl-inet firmware).

One tell-tale of this is this following:

this is a gl-inet specific firewall script.

So, you need to make sure that you have official OpenWrt on your device and start from scratch with the official configuration.

From the link I provided, you will see a big button to download the sysupgrade version... download that to your computer and then use the sysupgrade method to install the official OpenWrt stable release. Do not keep settings when you apply the update.

apo440 · February 3, 2024, 9:24pm

Okay, thanks for pointing that out. I guess it is "have kept settings" then somehow (not sure how I did that), as I'm sure I used those sysupgrade file mentioned above to bring openWRT onto the box.
Will need to find some time to wipe it and then setting up all from scratch will take a while.

psherman · February 3, 2024, 9:32pm

Sounds good.

When you run sysugprade on the command line, you need to use the -n argument to tell it not to keep settings. Similarly, with the GUI, there should be a checkbox (checked = keep settings, unchecked = don't keep settings & reset to defaults). Especially when changing from a vendor fork to official OpenWrt, this is critical because the vendor's configuration methods may not be compatible with official OpenWrt.

You can reset to defaults using the GUI or via CLI firstboot -y && reboot.
If you make a backup of your current config, you can use that as a human readable reference to help you remember what you had configured, but you'll want to reconfigure from scratch (don't restore the backup). Depending on your goals, you might be able to do this all within 10-30 minutes or less.

apo440 · February 4, 2024, 1:13pm

Okay, so I was bold enough to wipe that thing, but

Setup as before:
LAN2 (10.0.10.x) <-> LAN:openWRT:WAN <-> LAN1 (10.0.0.x) <-> FritzBox <-> DSL/ISP/WWW

Current problem I need to solve first: Hosts behind openWRT can't ping (nor do anything else) to anywhere outside LAN1+LAN2, e.g.
ping 8.8.8.8 gives From XX.X.XX.XXX icmp_seq=1 Packet filtered (with the X's being the public (dynamic) IP address of my FritzBox DSL ISP connection).
This time, it doesn't matter whether I activate masquerading on WAN in the Firewall (as it did before); keeping MASQ=OFF there now.

I guess you'll need these again instead of screenshots?:

ubus call system board
cat /etc/config/network
cat /etc/config/firewall

Here we go again.

root@SLATE:~# ubus call system board
{
        "kernel": "5.15.137",
        "hostname": "SLATE",
        "system": "Qualcomm Atheros QCA956X ver 1 rev 0",
        "model": "GL.iNet GL-AR750S (NOR/NAND)",
        "board_name": "glinet,gl-ar750s-nor-nand",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.2",
                "revision": "r23630-842932a63d",
                "target": "ath79/nand",
                "description": "OpenWrt 23.05.2 r23630-842932a63d"
        }
}

root@SLATE:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd60:e069:b6c8::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ip6assign '60'
        list ipaddr '10.0.10.1/24'
        option gateway '10.0.0.1'
        list dns '10.0.0.1'
        list dns_search 'fritz.box'

config interface 'wan'
        option device 'eth0.2'
        option proto 'static'
        option ipaddr '10.0.0.2'
        option netmask '255.255.255.0'
        option gateway '10.0.0.1'
        list dns '10.0.0.1'

config interface 'wan6'
        option device 'eth0.2'
        option proto 'dhcpv6'
        option auto '0'
        option reqaddress 'try'
        option reqprefix 'auto'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '2 3 0t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '1 0t'

config device
        option name 'eth0.2'
        option type '8021q'
        option ifname 'eth0'
        option vid '2'
        option macaddr '94:83:C4:0F:B3:4F'

Note on the above last line option macaddr...:
There seems to be a bug I came across already in the past. WAN and LAN by default get the same (!) MAC address, i.e. the hardware address. This leads to various strange effects, e.g.:

you can (after punching a hole into the FW) ping hosts behind the openWRT from LAN1. Pinging from a host behind the openWRT to a host on the WAN side gives ~90% packet losses.
you can't ssh to any host behind the openWRT, even though a correct FW rule has been set
others...

Fix: in LUCI, Network>Interfaces>Devices tab, for eth0.2, force a MAC address changed on the last digit to be different from the hardware MAC

Next, Firewall.

root@SLATE:~# cat /etc/config/firewall 

config defaults
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

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

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option mtu_fix '1'

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

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'Allow_Web+SSH_WAN-to-LAN-IP'
        list proto 'tcp'
        option src 'wan'
        option dest 'lan'
        list dest_ip '10.0.10.1'
        option dest_port '22 80 443'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow_WebIF_on-WAN-IP'
        list proto 'tcp'
        option src 'wan'
        option dest_port '22 80 443'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow_VM-105_pihole'
        option src 'wan'
        option dest 'lan'
        option dest_port '22 53 80 443 '
        option target 'ACCEPT'
        option family 'ipv4'
        list dest_ip '10.0.10.105'
        list proto 'tcp'

config rule
        option name 'Allow_Ping_to_LAN'
        option family 'ipv4'
        list proto 'icmp'
        option src 'wan'
        option dest 'lan'
        option target 'ACCEPT'

Have only added some few rules to gain access to the openWRT web if from both sides, ssh into it, and for one host (DNS server, .10.105) behind openWRT. Need to get that to speak to the outside world first, other machine specific rules will then be easy. Have not changed any of the default rules though eventually I want to lock down any and all IPv6 stuff cause I just don't master any of it yet and want to be sure anything I do always uses the IPv4 routes, not "bypassing" me (because something isn't right on IPv4 and the server/service/app silently falls back to IPv6 without me knowing).

So, what do I need to do now to get the machine on LAN2 to pass through openWRT via LAN1 to the world without my ISP blocking something?