Open onemustpersist opened 2 years ago
There may be some argument that this is an urgent issue as you cannot run the proxy without the firewall on
Hey there!
As in, you should really have the firewall on otherwise data might leak outside the vpn. Now maybe the problems lies in
2022/02/20 14:52:10 INFO routing: local ethernet link found: gretap0
2022/02/20 14:52:10 INFO routing: local ethernet link found: erspan0
2022/02/20 14:52:10 INFO routing: local ethernet link found: eth0
And then all traffic coming from eth0 is allowed, but not for the other 2 interfaces. I guess you are trying to reach the proxy through gretap0
or erspan0
?
I just had some talk in #834 to be able to specify manually the default interface, maybe that should be done? What do you think?
EDIT: Or just allow trafficx from all links I guess
As in, you should really have the firewall on otherwise data might leak outside the vpn Totally agree, hence why bringing it up.
I have multiple interfaces on the server it is running on (5 to be precise) and each of those have multiple networks (VLAN).
It is running on one of the VLAN interfaces. Is this likely what is causing the multiple networks to be shown?
Unsure which would be best, either allowing traffic from all interfaces or an option to change the binding interface. The former would require less input from the user, though the latter would give more control. I guess you could combine the 2, bind to all unless an interface is defined?
Is there a command I can pass on startup to address the issue temporarily ?
Some extra information for you. The 2 interfaces are down so it is unlikely that the request is coming via them :
ip link show:
4: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000
5: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1464 qdisc noop state DOWN mode DEFAULT group default qlen 1000
Could it be that the http server / shadowsock servers are binding to the first it finds regardless of state ?
Is there a command I can pass on startup to address the issue temporarily ?
You can use https://github.com/qdm12/gluetun/wiki/Firewall-options#custom-iptables-rules if you want to fiddle with the firewall. I will work on allowing incoming traffic from all detected network interfaces in the container, let's see if it will help.
Can you try with the latest image docker pull qmcgaw/gluetun
? It should now use all default routes and allow input/output traffic on each of them. Let me know if it fixes your problem!
Is this urgent?
No
Host OS
Unraid
CPU arch
x86_64
VPN service provider
NordVPN
What are you using to run the container
docker run
What is the version of Gluetun
v3.27.0
What's the problem 🤔
The HTTP proxy only works if the firewall is turned off. Same issue whether using username/password or not. Seems like the firewall just does not let it through.
Adding the ports to FIREWALL_INPUT_PORTS options does not seem to fix the issue although it does add the ports to the iptables:
iptables --list:
Disable the firewall and the same config works
Share your logs
Share your configuration
No response