OpenWrt/LEDE Project

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

FS#2901 - Flow offload not working properly in case of IPv6 (NAT6)

Linksys WRT32X with NAT6 configuration.

On latest 19.07 branch r10959

With the flow_offload feature turned on, nat6 is not working properly.
The first (or several) TCP packets seemed to be fine but later packets were not properly transmitted. The connection was soon closed.

(In case of accessing ipv6.google.com, the browser would freeze. And the curl would freeze after receiving a portion of the HTML content.)

In the meantime, ICMPv6 worked normally.

After removing the FLOWOFFLOAD ip6tables record, everything is fine.
After inserting the `-m conntrack –cstate RELATED,ESTABLISHED -j ACCEPT` before the FLOWOFFLOAD everything is also fine.

IPv4 part looked normal even if flow_offload is on.

NAT6 worked on older versions like 18.04 branch with flow_offload enabled.

Paul Oranje commented on 13.03.2020 14:03

Not really on-topic, but out of curiosity, what is your use-case for NAT6 ?

Yanlong Wang commented on 15.03.2020 12:35

I live in China.

ISPs in China are now providing native IPv6 for the general public.

However, to access sites blocked by the Gov like Google or Facebook, VPN is somewhat required.

This applies to IPv6 traffic as well.

Thus NAT6 is needed on my OpenWRT router so that the router could do the VPN stuff for my IPv6 Traffic as well as IPv4.

Paul Oranje commented on 16.03.2020 10:15

Ah, this concerns tunnelled IPv6 (could have guessed that).

As you set NAT on this interface (how ?), it seems that forwarding outgoing traffic from your downstream subnets (i.e. LAN) over that interface is intended.

Standard fw3 insert "-m conntrack –ctstate RELATED,ESTABLISHED -j ACCEPT" as first rule on the INPUT, OUTPUT and FORWARD chains.
So on which ip6tables chain is the rule inserted as a work around ?

(No tunnelled IPv6 available here, so I've not reproduced the set-up).

Yanlong Wang commented on 18.03.2020 16:40

It was the FORWARD chain.

I had a bunch of VPN Interfaces.
mwan3 helps me mangle the traffic to a specific interface by dest ipset.
Then source IP got MASQUERADE to the IP of the interface, only if the traffic was mangled by mwan3 (by ipmark).

Paul Oranje commented on 21.03.2020 18:08

Sorry, this is over my head, to complicated.

Maybe posting the output of "ip6tables -S" and "ip6tables -S -t nat" before and after might give a clue.

Paul Oranje commented on 24.03.2020 20:15

Just saw a big patch (by Alin Nastac) "[OpenWrt-Devel] [firewall3][PATCH] redirect & nat: add IPv6 NAT support" on the dev list.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing