Feature request: Support hostnames on VPN_ENDPOINT_IP

[fishnux]

What's the feature 🧐

EDIT by @qdm12 - copy-pasting from #404 since activity picked up more in this issue:

Resolve the hostname of the VPN server at start, this is especially useful for custom openvpn configuration file (#223).

• Env variable to enable this, as this add a security hole in the firewall
• Allow DNS through firewall out of tunnel at start only, then block it
• Only allow the DNS Resolution for that particular server hostname to avoid leaking DNS queries. To do so we should have a custom DNS forwarding implementation, so that's blocked by Feature request: DNS over HTTPS in Go to replace Unbound #137

[ahmaddxb]

I also required this option

[qdm12]

For now just use docker run --rm alpine:3.15 nslookup yourvpnserver.com to translate it to an IP address.

The current situation is gluetun doesn't do any network interaction until the VPN is connected to avoid leaking anything. I put special attention to this and to have the firewall setup as quickly as possible too.

Now this issue and others such as querying VPN provider web API to obtain Wireguard keys need to access internet before the VPN is up so it will ultimately be an option, but I can't say how long it will take me to get to it. Thanks for your understanding and of course let's keep this issue opened!

[misery]

Same here to connect to my local wireguard server at home. I'm using DDNS for this.
Maybe add an extra option like WIREGUARD_ENDPOINT_ALLOW_DNS=1 to explicitly let the user decide that it could leak the address.

[misery]

@qdm12 Is there any work around to use ddns for own wireguard server? Any automatic shell script that could fetch the new IP and send it to the control server?
Every night the connection is broken.

[TMD20]

I'm using this as a intermediate vpn

services:
  ipgen:
    image: wbitt/network-multitool:alpine-extra
    container_name: ipgen
    networks:
      - mynetwork
    command:  ["bin/bash","-c","while true;do dig europe.all.vpn.airdns.org +short |nc -l 4000;done"]

Change the entry point to this on the vpn service

    entrypoint:
          ["/bin/sh", "-c" , export VPN_ENDPOINT_IP=$$(timeout  0.1 nc ipgen 4000|shuf -n 1)&&/gluetun-entrypoint]

I imagine with this if the connection failed the healthtest, maybe it would remake the connection.
However I just configure this today.

It at least able to grab the IP on initial connect

[pranjaljain0]

I found a way. If anyone wants help can reach out. I will post it.
Thanks

[TMD20]

On 2023-03-01 16:25, Pranjal Jain wrote: I found a way. If anyone wants help can reach out. I will post it. Thanks -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you commented.Message ID: ***@***.***> Links: ------ [1] #788 (comment) [2] https://github.com/notifications/unsubscribe-auth/A2CBVZWX2VSDYCIIYRRH3RLWZ7EGZANCNFSM5LS454MA

I thought this was already implemented But It might just be for airvpn only

[pranjaljain0]

Yes I tried it for wireguard custom and it wasnt working

[pranjaljain0]

What I did was started a nginx container and made a TCP/UDP proxy_pass and then in gluetun I used the localhost IP

[vdrover]

Would love this feature.

[pCoder3000]

i tried this: was not successful, i suspect it is because the container does not allow connections to the network without vpn.

enviroment:
- VPN_SERVICE_PROVIDER=custom
- VPN_TYPE=wireguard
- VPN_ENDPOINT_IP=$(nslookup x-xxx.ptoserver.com | grep Address | tail -1 | awk '{print $NF}' )
- VPN_ENDPOINT_PORT=51820
- DNS_ADDRESS=1.1.1.1
- WIREGUARD_PUBLIC_KEY=xxx
- WIREGUARD_PRIVATE_KEY=xxx
- WIREGUARD_ADDRESSES=1.2.3.4/32

[vdrover]

@pCoder3000 that would have been awesome otherwise!

[pCoder3000]

did someone tryed it in the new release?

[eiqnepm]

Just came across this issue because one of my providers doesn't provide IP addresses, they automatically determine the nearest server each time you connect using a hostname.

Maybe add an extra option like WIREGUARD_ENDPOINT_ALLOW_DNS=1 to explicitly let the user decide that it could leak the address.

Probably easier to create one more environment variable called VPN_ENDPOINT_HOSTNAME, which when used implicitly enables DNS resolution that hostname.

[danriedl]

BIG +1
I'm using gluetun together with home-assistant in a truenas (truecharts) app-deployment.
It is connecting to my dad's router (it runs the WireGuard server), where he has a dynamic IP from his ISP.
Therefore, I have to redeploy the helm chart every time he gets a new IP, which freaks me out.

[raphamotta]

What I did was started a nginx container and made a TCP/UDP proxy_pass and then in gluetun I used the localhost IP

Could you please give more details about that?

EDIT:

Ok I got it, I did a stream on nginx proxy manager:

7890 - port of a fixed IP server (I use an free OCI server)
6882 - port of wireguard DDNS server (in my case, my raspberry pi at home)

server {
  listen 7890 udp;
listen [::]:7890 udp;

  proxy_pass wireguard_DDNS_server:6882;


}

[gurabli]

One more vote for this, using custom wireguard (my own) and need ddns.

[JoshBeer]

+1 vote for this. I'm baffled this is not a feature yet. So many usecases with dynamic IPs where you just need to use DDNS and therefore have to resort to a hostname.

[Kreakdude]

+1

My vpn provider, Ivacy, lets me download some wireguard files and they come with a couple values labeled dns so I wonder if those could be used with some optional env vars? Just a wild guess, I haven't successfully got anything working yet.

[alphadijkstra]

+1
I am in dire need of this feature as well.

@raphamotta I tried doing the same. My Nginx Proxy Manager, running through docker, runs on ip 192.168.0.25 and routes port 5182 to domain.com:51820. However I am unable to succesfully connect. I am sure the Wireguard server works correctly. But just can't route/set up the connection. In docker I set the Nginx ports open for 5182 and even 51820. But to no avail.
I've been struggling hard with this. Any tips? Am I missing some firewall settings? I use ipfire.

[MulverineX]

@alphadijkstra have you tried using the resolved IP address? (Instead of domain.com) Is using that a problem due to a lack of a static IP? This solved it for me since I use OVPN and they have static IP addresses for their nodes.

[alphadijkstra]

@MulverineX

have you tried using the resolved IP address?

Using the resolved IP works within gluetun. But that would break as soon as the Wireguard host changes IP (dynamic IP). That is why this gluetun feature is quite important to me.

[sj14]

It was also somewhat tricky for me to get it running, so here is my example (but it's from Kubernetes, I hope it's still helpful for some people).
I've added the google endpoint for debugging, so I could see if it's a problem with my network or the configuration.

Show Manifests

---
apiVersion: v1
kind: Namespace
metadata:
  name: wireguard
  labels:
    name: wireguard
---
apiVersion: v1
kind: Service
metadata:
  name: vpn
  namespace: wireguard
spec:
  ports:
    - name: httpproxy
      port: 8888
      protocol: TCP
      targetPort: 8888
    - name: shadowsockstcp
      port: 8388
      protocol: TCP
      targetPort: 8388
    - name: shadowsocksudp
      port: 8388
      protocol: UDP
      targetPort: 8388
  selector:
    app: wireguard
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: wireguard
  name: vpn
  namespace: wireguard
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wireguard
  template:
    metadata:
      labels:
        app: wireguard
      namespace: wireguard
    spec:
      containers:
        - name: debug
          image: curlimages/curl
          command: ["sleep"]
          args: ["infinity"]
          resources:
            requests:
              memory: 64Mi
              cpu: 10m
            limits:
              memory: 256Mi
              cpu: 200m
        - name: vpn
          image: qmcgaw/gluetun:v3.35.0
          imagePullPolicy: IfNotPresent
          env:
            - name: HEALTH_TARGET_ADDRESS
              value: 192.168.0.1:80
            - name: VPN_SERVICE_PROVIDER
              value: custom
            - name: VPN_TYPE
              value: wireguard
            - name: VPN_ENDPOINT_IP
              value: 10.102.159.86 # dyndns proxy service, use hostname when https://github.com/qdm12/gluetun/issues/788 is fixed
            - name: VPN_ENDPOINT_PORT
              value: "53280"
            - name: WIREGUARD_PUBLIC_KEY
              value: <CHANGE_ME>
            - name: WIREGUARD_PRESHARED_KEY
              value: <CHANGE_ME>
            - name: WIREGUARD_PRIVATE_KEY
              value: <CHANGE_ME>
            - name: WIREGUARD_ADDRESSES
              value: 10.200.200.1/24
          securityContext:
            capabilities:
              add:
                - NET_ADMIN
            privileged: true
          volumeMounts:
            - mountPath: /gluetun
              name: gluetun
          resources:
            requests:
              memory: 512Mi
              cpu: 10m
            limits:
              memory: 768Mi
              cpu: 200m
      volumes:
        - hostPath:
            path: /dev/net/tun
          name: mydevice0
        - name: gluetun
          emptyDir:
            sizeLimit: 500Mi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: dns
  name: dyndns-proxy
  namespace: wireguard
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dns
  template:
    metadata:
      labels:
        app: dns
      namespace: wireguard
    spec:
      containers:
        - name: debug
          image: curlimages/curl
          command: ["sleep"]
          args: ["infinity"]
          resources:
            requests:
              memory: 64Mi
              cpu: 10m
            limits:
              memory: 256Mi
              cpu: 200m
        - name: dyndns-proxy
          image: nginx:1.25
          volumeMounts:
          - mountPath: /etc/nginx
            readOnly: true
            name: nginx-conf
          resources:
            requests:
              memory: 64Mi
              cpu: 10m
            limits:
              memory: 256Mi
              cpu: 200m
      volumes:
        - name: nginx-conf
          configMap:
            name: nginx-conf # place ConfigMap `nginx-conf` in /etc/nginx
            items:
              - key: nginx.conf
                path: nginx.conf
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
  namespace: wireguard
data:
  nginx.conf: |
    # Variable to allow dns refresh (see https://serverfault.com/a/593003)
    events {}
    stream {
      server {
        resolver 8.8.8.8;
        listen 53280 udp;
        set $url "<DYNAMIC_DNS_HOST>:53280";
        proxy_pass $url;
      }
      server {
        resolver 8.8.8.8;
        listen 53000;
        set $url "google.com:80";
        proxy_pass $url;
      }
    }
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: wireguard
spec:
  type: ClusterIP
  clusterIP: 10.102.159.86
  ports:
  - name: google
    port: 53000
    targetPort: 53000
    protocol: TCP
  - name: dyndns
    port: 53280
    targetPort: 53280
    protocol: UDP
  selector:
    app: dns

[MulverineX]

Investigation stage for this bug is pretty much already taken care of, the dev just hasn't started work on it yet. Looks like it's getting closer but it'll probably still be several months before we see an alpha or something for this

[MulverineX]

@MulverineX

have you tried using the resolved IP address?

Using the resolved IP works within gluetun. But that would break as soon as the Wireguard host changes IP (dynamic IP). That is why this gluetun feature is quite important to me.

@alphadijkstra yeah you're probably just going to have to setup a hacky automation to check for changes in dig, to update the config accordingly and restart the gluetun container.

[emanuelbaltaretu]

+1 From me as well, still haven't got any luck for implementing the custom mentioned solution here, until a solution is released guess i will manually change ip's

[kaumudpa]

+1 - Using Wireguard behing Nginx.

[kaumudpa]

@qdm12, Sorry for asking this, just wanted to know if someone is working on this and if yes what kind ETA can we expect?