Hi !
We use UDP forwarder in our case because we want to have the buffer available on the RAK Gateways (only support UDP when using auto recovery mode).
We did securise with VPN between the GW and server with wireguard, the GW client is well connected to the server VPN which is the same IP than the LNS/forwarder. (all on docker/container)
If we close the 1700 it is not working anymore, I believe it is due to the fact that all server run on container/docker.
How do you secure 1700 ? Do you think there is a possibility to hack or use a kind of brute force to kill the udp forwarder server ?
I don’t like to let a port open on a server, apart the VPN one…
Kind regards,
Joseph EyesOT.com
Sorry I think a little bit of your explanation is lost in translation. Is your issue that port 1700 on your server is open on both the VPN interface and the WAN interface? And you want it only open on the VPN interface? Naturally closing port 1700 on the container / server itself will cause the communication to fail as that is the port the UDP forwarder sends to.
Typically it’s okay to leave port 1700 open but I agree it’s always better to close them when you can, and it shouldn’t be hard to do here. Assuming your server has a VPN interface and a WAN interface, you could set the 1700 port to only be open on the VPN interface. You can do this in your docker-compose.yml by setting the port of your gateway bridge to:
ports:
- "192.168.1.3:1700:1700/udp"
Where 192.168.1.3 is the IP of the server on the VPN interface. That way your server is only listening to that port on the VPN interface and not the WAN interface. Source: https://stackoverflow.com/questions/45109398/how-can-i-make-docker-compose-bind-the-containers-only-on-defined-network-instea
Your other option is to configure the firewall on the server to only accept packets going to port 1700 if they originate from IPs over the VPN.
Am I understanding your issue correctly?
Thanks a lot !
Sorry, my english is a bit bad I believe.
By closing 1700 port, I wanted to say to close from firewall point of view.
Here is my yml
chirpstack-gateway-bridge:
image: chirpstack/chirpstack-gateway-bridge:4
restart: unless-stopped
ports:
- 1700:1700/udp
My vpn subnet is 10.9.0.1/24, my clients (GW) 10.9.0.xx
My docker subnets are the following
So you mean that it could work by modifying the yml ?
ports:
- 10.9.0.1:1700/udp
or
- 172.22.0.2:1700/udp
I’m trying to understand since 6 months why there was communication between VPN container and UDP forwarder container, but you found…
Hmm, what is the IP of the host of these containers on the VPN? Is it 10.9.0.1? Or is that just your subnet block 10.9.0.1/24? I believe you should have the IP in your .yml be the container hosts IP on that interface, and typically x.x.x.1 is reserved for gateway not servers but honestly I am not super familiar with VPNs.
So I think it should be:
ports:
- "10.9.0.x:1700:1700/udp"
Edit: From a quick google, I think you are right and since wireguard is running on the host itself you should use the IP 10.9.0.1.
It works !
My VPN is working on docker also…
I used the IP bridge 172.17.0.1 and it works ! No more port 1700 in the wild ! 
But on the GW itself I had to change the lora server to 172.17.0.1 too.
Thanks Liam 
1 Like
