-
-
Notifications
You must be signed in to change notification settings - Fork 360
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
Bug: iptables-nft on host without nftables #896
Comments
Interesting, can you try: docker run -it --rm --cap-add=NET_ADMIN alpine:3.15
apk add ip6tables
ip6tables -L
echo $?
ip6tables-nft -L
echo $? What do you get? Gluetun tries |
Interesting, on the alpine container as you provided it seems that ip6tables-nft is the one that works? haha. packages installed:
ip6tables:
ip6tables-nft:
Host kernel is However! Even if
|
How about If it still works, what do you get with: ip6tables -A INPUT -i lo -j ACCEPT
echo $? Anyway, it looks like some iptables bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915187 I also created #898 which should offer a better handling of the firewall for nftables compatible systems. |
It seems that neither command works.
However running
|
So I guess only a policy change will fail? That's rather odd, but I can twist the code to react on this, although it's not totally ideal. Can you try: docker run -it --rm --cap-add=NET_ADMIN alpine:3.15
apk add ip6tables
ip6tables-nft --policy INPUT DROP
echo $? |
Just wanted to follow as I have the exact same problem, using qmcgaw/gluetun:v3.28.0 as a workaround untill a fix is released. Here's the output on a fresh install of ubuntu server 20.04:
And some more info
And here's the output on my old server that never had problem with gluetun and it's working with v3.28.0
I've found this issue with openvpn image that look similar if this can help. |
Oops, I forgot about this issue, I can confirm the output by arsenicks also happens to me as well, I also ran this same test on an archlinux-based machine, updated today, and I'm able to reproduce the original issue, so it seems to be an issue with the alpine base container. |
- Add dummy rule to `INPUT` to test for iptables support - This may resolve #896
I pushed 20f20f0 on the latest image, it now tries to do |
I've just tested the latest image from docker hub and it seems to have resolved the issue, thanks! |
Using the latest image, as far as I can tell I still get the error and the vpn doesn't start. |
@arsenicks can you share the logs you got (essentially the error you get and the version logged a the top). |
Sure, here it is.
|
@arsenicks can you try: docker run -it --rm --cap-add=NET_ADMIN alpine:3.15
apk add ip6tables
ip6tables-nft -A INPUT -i blabla -j REJECT
echo $?
ip6tables-nft -A OUTPUT -i blabla -j REJECT
echo $?
ip6tables-nft -A FORWARD -i blabla -j REJECT
echo $?
exit What a strange bug, I think you can modify the input table but not the output one. Let me know and I'll add additional checks to detect support with gluetun. |
In fact, the error message state -i cannot be used with OUTPUT table, it's been a long time since I played with iptables, let along this new nft thing but as far as I can tell from the manpage the -i is used for in-interface
-o looks more like the option we should use
Result of -o:
|
I just changed the iptables test to use I'll make a release as soon as this issue is fixed. |
Is this fixed now? Please everyone make sure the latest image works correctly, I would like to make a release this weekend. Thanks! |
sorry for the delay, it looks like it doesn't work, it's the input that seems to be problematic that time..
|
Very strange, adding a reject rule works but changing its policy doesn't... Can you try docker run -it --rm --cap-add=NET_ADMIN alpine:3.15
apk add ip6tables
ip6tables-nft --policy INPUT ACCEPT
echo $? I hope this one fails, that way I can test ip6tables support using that random rule + setting the policy as the existing one (ACCEPT in this case). If it does not fail, I'm not 100% sure how to address the problem since that would mean we would have to cut off traffic (change policy to drop) to test support. That is fine for now in a container, but I'd like one day to have gluetun work outside docker too and that becomes problematic (aka we don't want to shutdown the machine network, even for a quick moment). |
Hi, it does fail:
I'm personally out of idea but this post and the links provided might give you the answer https://unix.stackexchange.com/questions/588998/check-whether-iptables-or-nftables-are-in-use
Here's the output from the alpine container I started as stated in your previous post with the output of both commands:
As you can see, nft-save tell us legacy is used, so we can just use the output of those commands to decide which mode we'll use, sounds like that should do the trick |
Awesome thanks for sharing this @arsenicks fc5cf44 addresses this, can you please try the latest image again? The strategy is now to:
To detect which iptables is really supported. It works for me, but I'm obviously curious if it works for your weirdo kernels 😄 |
Hi, it looks like it's fixed now!
Thanks for your time and help! |
Awesome thanks I'll do a release v3.29.0 soon then! |
Is this urgent?
No
Host OS
Ubuntu 16.04
CPU arch
x86_64
VPN service provider
Private Internet Access
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2022-03-15T08:20:32.863Z (commit 984e143)
What's the problem 🤔
Running on a host with IPv6 enabled, looks like gluetun is now attempting to use nftables to drop incoming ipv6 traffic, however it seems that nftables is unable to locate the default chain (the host is running iptables not nftables).
This issue does not happen on gluetun
v3.28.0
.Share your logs
Share your configuration
The text was updated successfully, but these errors were encountered: