Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
openwrt-bot opened this issue Feb 12, 2019 · 13 comments
Open

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

openwrt-bot opened this issue Feb 12, 2019 · 13 comments
Labels

Comments

@openwrt-bot
Copy link

ThomasCr:

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.

@openwrt-bot
Copy link
Author

ThomasCr:

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.

@openwrt-bot
Copy link
Author

ThomasCr:

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()

@openwrt-bot
Copy link
Author

jow-:

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

@openwrt-bot
Copy link
Author

ThomasCr:

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 :-(

@openwrt-bot
Copy link
Author

jow-:

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.

@openwrt-bot
Copy link
Author

ThomasCr:

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

@openwrt-bot
Copy link
Author

ThomasCr:

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

@openwrt-bot
Copy link
Author

ThomasCr:

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

@openwrt-bot
Copy link
Author

ThomasCr:

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

$ifname = wwan
but fw3 needs the device?

@openwrt-bot
Copy link
Author

ThomasCr:

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)"
      }</code>
    

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

@openwrt-bot
Copy link
Author

ThomasCr:

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?

@openwrt-bot
Copy link
Author

ThomasCr:

Is there not a proto_send_update needed?

@openwrt-bot
Copy link
Author

ThomasCr:

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)"
      }</code>
    

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant