gluetun
gluetun copied to clipboard
Bug: No UDP to LAN without FIREWALL_OUTBOUND_SUBNETS
Is this urgent?
No
Host OS
Ubuntu 22.04.2
CPU arch
x86_64
VPN service provider
IVPN
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2023-10-07T13:26:08.155Z (commit 1c43a1d)
What's the problem 🤔
edited urgency to not urgent ~Not urgent but also not not urgent. There isn't a 'somewhat' option.~
I'm running gluetun with a connected container (unbound recursive, no forwarding). I'm able to get resolve requests from the container host and other hosts in my network with TCP (eg, dig @192.168.1.90 news.google.com -p 5353 +tcp
) but not UDP (eg, dig @192.168.1.90 news.google.com -p 5353
).
Yet if I include the option FIREWALL_OUTBOUND_SUBNETS=192.168.1.90/32
both TCP and UDP requests will return.
tcpdump in the container WITHOUT FIREWALL_OUTBOUND_SUBNETS
:
tcpdump -n -i eth0 port 53
00:12:57.246216 IP 192.168.1.90.51763 > 172.26.0.2.53: 54181+ [1au] A? barf.com. (49)
00:12:59.248532 IP 192.168.1.90.42635 > 172.26.0.2.53: 54181+ [1au] A? barf.com. (49)
00:13:01.248365 IP 192.168.1.90.55363 > 172.26.0.2.53: 54181+ [1au] A? barf.com. (49)
tcpdump in the container WITH FIREWALL_OUTBOUND_SUBNETS=192.168.1.90/32
:
tcpdump -n -i eth0 port 53
00:08:08.872154 IP 192.168.1.90.35053 > 172.25.0.2.53: 18140+ [1au] A? barf.com. (49)
00:08:08.872319 IP 172.25.0.2.27429 > 192.12.94.30.53: 54924% [1au] A? barf.com. (37)
00:08:08.949134 IP 192.12.94.30.53 > 172.25.0.2.27429: 54924- 0/6/5 (726)
00:08:08.949380 IP 172.25.0.2.6190 > 173.201.73.26.53: 46220% [1au] A? barf.com. (37)
00:08:08.964126 IP 173.201.73.26.53 > 172.25.0.2.6190: 46220*- 2/2/1 A 3.33.130.190, A 15.197.148.33 (121)
00:08:08.964480 IP 172.25.0.2.53 > 192.168.1.90.35053: 18140 2/2/1 A 3.33.130.190, A 15.197.148.33 (121)
I'm reluctant to call this a bug or think of it as unique. I was also very surprised to not find any mention of this behavior in previous issues or discussions.
I understand I could use FIREWALL_OUTBOUND_SUBNETS
with custom iptables rules (ie, /iptables/post-rules.txt
) yet I believe there's something missing with the ip tables construction not considering mapped UDP ports.
EDIT: A quick and easy way to reproduce/demonstrate this:
# docker exec -it unbound sh
/ # vi /etc/unbound/unbound.conf
verbosity: 2
# docker logs -f unbound
# dig @192.168.1.90 efg.com -p 5353
;; communications error to 192.168.1.90#5353: timed out
# docker logs -f unbound
[ ... ]
[1698497848] unbound[9:0] info: resolving efg.com. A IN
[1698497849] unbound[9:0] info: response for efg.com. A IN
[1698497849] unbound[9:0] info: reply from <com.> 192.35.51.30#53
[1698497849] unbound[9:0] info: query response was REFERRAL
[1698497849] unbound[9:0] info: resolving a12-66.akam.net. A IN
[ ... ]
Share your logs (at least 10 lines)
Running version latest built on 2023-10-07T13:26:08.155Z (commit 1c43a1d)
[ ... ]
2023-10-28T00:50:58Z INFO [routing] default route found: interface eth0, gateway 172.29.0.1, assigned IP 172.29.0.2 and family v4
2023-10-28T00:50:58Z INFO [routing] local ethernet link found: eth0
2023-10-28T00:50:58Z INFO [routing] local ipnet found: 172.29.0.0/16
2023-10-28T00:50:58Z INFO [firewall] enabling...
2023-10-28T00:50:58Z DEBUG [firewall] iptables --policy INPUT DROP
2023-10-28T00:50:58Z DEBUG [firewall] iptables --policy OUTPUT DROP
2023-10-28T00:50:58Z DEBUG [firewall] iptables --policy FORWARD DROP
2023-10-28T00:50:58Z DEBUG [firewall] ip6tables-nft --policy INPUT DROP
2023-10-28T00:50:58Z DEBUG [firewall] ip6tables-nft --policy OUTPUT DROP
2023-10-28T00:50:58Z DEBUG [firewall] ip6tables-nft --policy FORWARD DROP
2023-10-28T00:50:58Z DEBUG [firewall] iptables --append INPUT -i lo -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] ip6tables-nft --append INPUT -i lo -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] iptables --append OUTPUT -o lo -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] ip6tables-nft --append OUTPUT -o lo -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] iptables --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] ip6tables-nft --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] iptables --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] ip6tables-nft --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] iptables --append OUTPUT -o eth0 -s 172.29.0.2 -d 172.29.0.0/16 -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] ip6tables-nft --append OUTPUT -o eth0 -d ff02::1:ff/104 -j ACCEPT
2023-10-28T00:50:58Z DEBUG [firewall] iptables --append INPUT -i eth0 -d 172.29.0.0/16 -j ACCEPT
2023-10-28T00:50:58Z INFO [firewall] enabled successfully
2023-10-28T00:50:59Z INFO [storage] merging by most recent 17689 hardcoded servers and 17689 servers read from /gluetun/servers.json
2023-10-28T00:50:59Z INFO Alpine version: 3.18.4
2023-10-28T00:50:59Z INFO OpenVPN 2.5 version: 2.5.8
2023-10-28T00:50:59Z INFO OpenVPN 2.6 version: 2.6.5
2023-10-28T00:50:59Z INFO Unbound version: 1.17.1
2023-10-28T00:50:59Z INFO IPtables version: v1.8.9
2023-10-28T00:50:59Z INFO Settings summary:
[ ... ]
### Share your configuration
```yml
version: "3"
services:
gluetun:
image: qmcgaw/gluetun
container_name: gluetun
dns:
- 127.0.0.1
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
ports:
volumes:
- /usr/local/docker/gluetun/gluetun_config:/gluetun
environment:
- HEALTH_SERVER_ADDRESS=0.0.0.0:9999
- VPN_SERVICE_PROVIDER=ivpn
- VPN_TYPE=wireguard
- SERVER_COUNTRIES="Canada,United States"
- WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
- WIREGUARD_ADDRESSES=172.25.72.56/32
- VPN_ENDPOINT_PORT=2049
- UPDATER_PERIOD=1h
- HTTPPROXY=on
- HTTPPROXY_STEALTH=on
- DOT=off
- DNS_KEEP_NAMESERVER=on
- FIREWALL_DEBUG=on
# - FIREWALL_OUTBOUND_SUBNETS=192.168.1.90/32
unbound:
image: cdrocker/unbound
container_name: unbound
network_mode: "service:gluetun"
I found a solution to this issue that does not involve the use of FIREWALL_OUTBOUND_SUBNETS
(or forking this project).
See here for more analysis on the issue described above with an Unbound option noted (interface-automatic: yes
) which provides return of UDP requests: https://github.com/NLnetLabs/unbound/issues/960
Leaving this open as possible consideration for feature request and/or including with: https://github.com/qdm12/gluetun/issues/1410