OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by ThomasCr - 12.02.2019

FS#2122 - NAT-Loopback not working with NCM protocol

Hi,

today I updated my LEDE installation to OpenWRT 18.06.2 in hope, it fixes some problems:

One of them is, that the NAT loopback rules get not automatically created on interface up / firewall reload

I think, it is because of the virtually assigned _4 / _6 suffix of the interface name.

ThomasCr commented on 12.02.2019 15:56

I think, the bug must be located somewhere in this file

https://git.openwrt.org/?p=project/firewall3.git;a=blob;f=redirects.c;hb=HEAD

I tried to figure out how it works, but didn't found the right function where the ip address get resolved - on this point should be a query if the proto is ncm and if yes the ip should be get from interface_4 or interface_6 to add it to the reflection rule.

ThomasCr commented on 12.02.2019 16:03

ok, I think I located the right point for the fix:

https://git.openwrt.org/?p=project/firewall3.git;a=blob;f=zones.c

On function fw3_resolve_zone_addresses()

Admin
Jo-Philipp Wich commented on 12.02.2019 16:30

The firewall package is not the proper place to fix this. Please try the attached patch (you can edit the ncm.sh file live on your router and reboot if you do not want to compile).

ThomasCr commented on 14.02.2019 16:18

thanks - I have patched /lib/netifd/proto/ncm.sh and made a reboot.

this only affects now the firewall - or other packages too? When I get it right - you add only the zone identifier to the virtual interface?

Because I know, that some packages have now be fixed to get the ips from _4 and _6 virtual interfaces for ncm (like the mwan3 package)

EDIT: hmmm - the router don't come online again. Need to call someone tomorrow :-(

Admin
Jo-Philipp Wich commented on 14.02.2019 16:22

Yes, it ensures that _4 and _6 subinterfaces are put into the same firewall zone as the parent interface. The firewall draws its IP information for loopback setup from all interfaces members of a given zone (as seen by "ifstatus xxx").

Hardcoding any _4 or _6 subinterface assumptions is not the proper fix since this is a protocol specific implementation detail.

ThomasCr commented on 14.02.2019 16:30

what ever happened - it looks like something goes wrong with this fix - because the router wont get online again.

EDIT: cant connect from external via ssh and even the computer from behind the router dont come online - because the host dont come up in teamviewer.

I made a backup of the original ncm.sh - tomorrow I will report back, when someone it at the site to recover the original.

I have patched the file with the patch util and entered the right filename.

root@gw:~# patch -p0 < /root/0001-comgt-inherit-firewall-zone-membership-to-virtual-su.patch 
can't find file to patch at input line 16
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From e05b3363e39f596e3cd3b9dfc764f1e51fa4b6a6 Mon Sep 17 00:00:00 2001
|From: Jo-Philipp Wich <jo@mein.io>
|Date: Tue, 12 Feb 2019 17:28:09 +0100
|Subject: [PATCH] comgt: inherit firewall zone membership to virtual sub
| interfaces
|
|Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|---
| package/network/utils/comgt/files/ncm.sh | 12 ++++++++++++
| 1 file changed, 12 insertions(+)
|
|diff --git a/package/network/utils/comgt/files/ncm.sh b/package/network/utils/comgt/files/ncm.sh
|index 60b39655ec..e3c820ab3f 100644
|--- a/package/network/utils/comgt/files/ncm.sh
|+++ b/package/network/utils/comgt/files/ncm.sh
--------------------------
File to patch: /lib/netifd/proto/ncm.sh
patching file /lib/netifd/proto/ncm.sh
ThomasCr commented on 15.02.2019 11:06

ok, I could solve the problem - it was the LTE usb stick - the stick was in an unexpected state. All trys (reboots/poweroff/on/change usb port and restore the original ncm.sh) did not solve the problem.

I saved the logfile - maybe I make a bug report. OpenWRT should implement a better initialization of the lte stick. I put the stick to my laptop with Ubuntu 18.04 installed and made a connection. All was working well.

So now back to topic:

I patched the file again and made a new reboot - but the reflection rules are not present and on the network page of luci the virtual interfaces are still not the same color like the parent (wwan) interface

ThomasCr commented on 18.02.2019 21:26

today I had time to debug this a little:

I added the follow line down under the local zone="...

logger -t ncm.sh "debug: $ifname has zone $zone"

and I got

Mon Feb 18 21:24:58 2019 user.notice ncm.sh: debug: wwan0 has zone

so it seams, that on this point, the zone is not known to fw3.

But when the interface is connected, I can get the zone without any problems:

root@gw:~# fw3 -q network wwan
wan
ThomasCr commented on 18.02.2019 21:28

grr.. after reading again my comment I get the problem:

$ifname = wwan
but fw3 needs the device?

ThomasCr commented on 18.02.2019 21:42

so, ok - the right patch should look like this:

--- /lib/netifd/proto/ncm.sh.orig       2019-02-14 17:09:58.000000000 +0100
+++ /lib/netifd/proto/ncm.sh    2019-02-18 22:36:51.000000000 +0100
@@ -146,12 +146,19 @@
        proto_close_data
        proto_send_update "$interface"
 
+       local zone="$(fw3 -q network "$interface" 2>/dev/null)"
+
        [ "$pdptype" = "IP" -o "$pdptype" = "IPV4V6" ] && {
                json_init
                json_add_string name "${interface}_4"
                json_add_string ifname "@$interface"
                json_add_string proto "dhcp"
                proto_add_dynamic_defaults
+               [ -n "$zone" ] && {
+                       proto_add_data
+                       json_add_string zone "$zone"
+                       proto_close_data
+               }
                ubus call network add_dynamic "$(json_dump)"
        }
 
@@ -162,6 +169,11 @@
                json_add_string proto "dhcpv6"
                json_add_string extendprefix 1
                proto_add_dynamic_defaults
+               [ -n "$zone" ] && {
+                       proto_add_data
+                       json_add_string zone "$zone"
+                       proto_close_data
+               }
                ubus call network add_dynamic "$(json_dump)"
        }

But still no reflection rule in fw3

root@gw:~# fw3 print|grep -i MyAPP
iptables -t nat -A zone_wan_prerouting -p tcp -m tcp --dport 34098 -m comment --comment "!fw3: MyAPP" -j DNAT --to-destination 192.168.2.1:29422
ThomasCr commented on 18.02.2019 21:46

But I also can not get the zone from ubus call...

ubus -v call network.interface.wwan_4 dump|grep zone

How can I verify if the zone is set?

ThomasCr commented on 18.02.2019 21:49

Is there not a proto_send_update needed?

ThomasCr commented on 18.02.2019 21:58

Ok, I got it running:

I modified the code like seen there: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/ipv6/odhcp6c/files/dhcpv6.script;h=dcb7a95d98f8342fb7626449a11ecadb2e050e5e;hb=refs/tags/v18.06.1

--- /lib/netifd/proto/ncm.sh.orig       2019-02-14 17:09:58.000000000 +0100
+++ /lib/netifd/proto/ncm.sh    2019-02-18 22:52:36.000000000 +0100
@@ -146,12 +146,18 @@
        proto_close_data
        proto_send_update "$interface"
 
+       local zone="$(fw3 -q network "$interface" 2>/dev/null)"
+
        [ "$pdptype" = "IP" -o "$pdptype" = "IPV4V6" ] && {
                json_init
                json_add_string name "${interface}_4"
                json_add_string ifname "@$interface"
                json_add_string proto "dhcp"
                proto_add_dynamic_defaults
+               [ -n "$zone" ] && {
+                       json_add_string zone "$zone"
+               }
+               json_close_object
                ubus call network add_dynamic "$(json_dump)"
        }
 
@@ -162,6 +168,10 @@
                json_add_string proto "dhcpv6"
                json_add_string extendprefix 1
                proto_add_dynamic_defaults
+               [ -n "$zone" ] && {
+                       json_add_string zone "$zone"
+               }
+               json_close_object
                ubus call network add_dynamic "$(json_dump)"
        }

Now the wwan_v4 interface has the same color like wwan in luci webif and I get the reflection rules:

root@gw:~# fw3 print|grep -i MyAPP
iptables -t nat -A zone_wan_prerouting -p tcp -m tcp --dport 34098 -m comment --comment "!fw3: MyAPP" -j DNAT --to-destination 192.168.2.1:29422
iptables -t nat -D zone_lan_prerouting -p tcp -s 192.168.2.0/255.255.255.0 -d 123.123.123.123/255.255.255.255 -m tcp --dport 34098 -m comment --comment "!fw3: MyAPP (reflection)" -j DNAT --to-destination 192.168.2.1:29422
iptables -t nat -A zone_lan_prerouting -p tcp -s 192.168.2.0/255.255.255.0 -d 123.123.123.123/255.255.255.255 -m tcp --dport 34098 -m comment --comment "!fw3: MyAPP (reflection)" -j DNAT --to-destination 192.168.2.1:29422
iptables -t nat -D zone_lan_postrouting -p tcp -s 192.168.2.0/255.255.255.0 -d 192.168.2.1/255.255.255.255 -m tcp --dport 29422 -m comment --comment "!fw3: MyAPP (reflection)" -j SNAT --to-source 192.168.2.254
iptables -t nat -A zone_lan_postrouting -p tcp -s 192.168.2.0/255.255.255.0 -d 192.168.2.1/255.255.255.255 -m tcp --dport 29422 -m comment --comment "!fw3: MyAPP (reflection)" -j SNAT --to-source 192.168.2.254

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing