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#2901 - Flow offload not working properly in case of IPv6 (NAT6) #7683

Open
openwrt-bot opened this issue Mar 13, 2020 · 6 comments
Open
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release

Comments

@openwrt-bot
Copy link

nomagick:

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.

@openwrt-bot
Copy link
Author

por:

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

@openwrt-bot
Copy link
Author

nomagick:

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.

@openwrt-bot
Copy link
Author

por:

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

@openwrt-bot
Copy link
Author

nomagick:

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

@openwrt-bot
Copy link
Author

por:

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.

@openwrt-bot
Copy link
Author

por:

Just saw a big patch (by Alin Nastac) "[OpenWrt-Devel] [firewall3][PATCH] [[http://lists.infradead.org/pipermail/openwrt-devel/2020-March/022375.html|redirect & nat: add IPv6 NAT support]]" on the dev list.

@aparcar aparcar added the release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release label Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release
Projects
None yet
Development

No branches or pull requests

2 participants