gluetun icon indicating copy to clipboard operation
gluetun copied to clipboard

Bug: No UDP to LAN without FIREWALL_OUTBOUND_SUBNETS

Open ezekieldas opened this issue 1 year ago • 1 comments

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"

ezekieldas avatar Oct 28 '23 00:10 ezekieldas

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

ezekieldas avatar Oct 30 '23 21:10 ezekieldas