ANSWERED Port Forward In Unifi

[flat4 82]

Well written and thank you for taking the time to post this

[P.Bear 5]

On 9/25/2024 at 12:13 PM, fisken said:

Here’s how I solved it:

[...]

Hello,

Thanks, it works.
The first rule creates the needed iptables rules in the FORWARD chain: 

-A UBIOS_WAN_IN_USER -d 10.0.1.20/32 -p tcp -m tcp --dport 40778 -m limit --limit 50/sec --limit-burst 100 -j NFLOG --nflog-prefix  "[WAN_IN-RET-20001] DESCR=\"ACCEPT traffic to QbT container\"" --nflog-threshold 16
-A UBIOS_WAN_IN_USER -d 10.0.1.20/32 -p tcp -m tcp --dport 40778 -m comment --comment 00000000004294987297 -j RETURN
-A UBIOS_WAN_IN_USER -d 10.0.1.20/32 -p udp -m udp --dport 40778 -m limit --limit 50/sec --limit-burst 100 -j NFLOG --nflog-prefix  "[WAN_IN-RET-20001] DESCR=\"ACCEPT traffic to QbT container\"" --nflog-threshold 16
-A UBIOS_WAN_IN_USER -d 10.0.1.20/32 -p udp -m udp --dport 40778 -m comment --comment 00000000008589954593 -j RETURN

Rmq: The chain UBIOS_WAN_IN_USER is actually a chain called inside the chain UBIOS_FORWARD_IN_USER , which is called inside the chain UBIOS_FORWARD_USER_HOOK , which is called inside the chain UBIOS_FORWARD_JUMP, which is called inside the chain FORWARD

The second rule creates the others needed iptables rules in the PREROUTING chain:

-A UBIOS_PREROUTING_USER_HOOK -d 10.160.55.241/32 -i wgclt4 -p tcp -m tcp --dport 40778 -m comment --comment 00000000004294967297 -j DNAT --to-destination 10.0.1.20
-A UBIOS_PREROUTING_USER_HOOK -d 10.160.55.241/32 -i wgclt4 -p udp -m udp --dport 40778 -m comment --comment 00000000008589934593 -j DNAT --to-destination 10.0.1.20

Rmq: The chain UBIOS_PREROUTING_USER_HOOK is actually a chain called inside the chain UBIOS_PREROUTING_JUMP, which is called inside the chain PREROUTING


I'll keep my manual rules to specific filtering as the countries, since it's still not possible through the web interface. 😡
Also for the ipv6 rules.

But it’s a mess with UNIFI.
To configure a PORT FORWARD from the WAN (or WAN2), we have to go to the Security/Port Forwarding tab. But now that we can finally configure a portforward on other interfaces than the WAN, we have to go into Routing/NAT. 
What’s the logic?!?

It remains to hope now that UNFI realizes we are in 2024, and hires people who understand IPv6! We would finally have ipv6 support with our VPN's. And when ipv6 will be supported, if it happens one day, have put the port foward in Routing/NAT will make even less sense..

 

[Mytob 2]

On 9/25/2024 at 11:13 AM, fisken said:

Here’s how I solved it:

 

1. Setup VPN Interface with Policy-Based Routing:

 

   •   First, I set up WireGuard as the VPN client on my Unifi gateway. Many VPN providers allow you to download a WireGuard config that can be uploaded into Unifi.

   •   Once the VPN is configured, you can create a Policy-Based Route to specify which devices or networks should use the VPN for outbound traffic. This step ensures your internal devices route traffic through the VPN tunnel.

 

2. Solution: Custom Firewall and NAT Rules:

 

To make port forwarding work, I had to set up both a custom firewall rule and a Destination NAT rule.

 

Step-by-Step Setup:

 

   •   Firewall Rule:

   1.   Go to Firewall & Security → Create a new rule under “Internet In”.

   2.   Action: Set to “Accept”.

   3.   Protocol: Select TCP/UDP (or any specific protocol you need).

   4.   Source: Set to Any. Since the traffic is coming from the internet via your VPN, it’s important to allow any source.

   5.   Destination: This should be the internal IP of the device you want to forward traffic to (e.g., 192.168.1.xxx).

   6.   Destination Port: Set the specific port you’re forwarding.

   7.   Save the rule.

   •   NAT Rule (Destination NAT):

   1.   Go to Network Settings and create a Destination NAT rule.

   2.   Set the Interface to your WireGuard VPN interface.

   3.   Destination Address: Set this to the internal IP address from the VPN tunnel (the IP assigned to you by your VPN provider within the VPN network, e.g., 10.x.x.x).

   4.   Translated IP Address: Set this to the local IP of the device in your network (e.g., 192.168.1.xxx).

   5.   Ports: Match the Destination Port to the port you are forwarding.

Thanks for that! Prob a dumb question but is the IP for destination address the one in the config file?

Also somewhat off topic but has anyone has issues with AirVPN and WG on the Unifi Dream Machine? Finding alot of sites just timeout for no obvious reason. Works fine with the WG client on the local PC though.

[BogusBogey 0]

On 9/25/2024 at 12:13 PM, fisken said:

Here’s how I solved it:
...

Any idea how we can fix the problem of the changing IP address (the one assigned to you by your VPN provider within the VPN network)?
Perhaps using a DDNS script?

[Mytob 2]

1 hour ago, BogusBogey said:

Any idea how we can fix the problem of the changing IP address (the one assigned to you by your VPN provider within the VPN network)?
Perhaps using a DDNS script?

The ip address is the one in the config file. This is unchanging unless you want to change region or specific server. So if I connect to NL area then every time I disconnect and reconnect I have a chance of getting a different exit server but the ip address in that I have to put in the field is no different.

[BogusBogey 0]

16 hours ago, Mytob said:

The ip address is the one in the config file. This is unchanging unless you want to change region or specific server. So if I connect to NL area then every time I disconnect and reconnect I have a chance of getting a different exit server but the ip address in that I have to put in the field is no different.

No sorry, I mean the Tunnel IP address. There's indeed the exit/country server, but that server has to know where to send your traffic to, so you get an IP address.

[P.Bear 5]

1 hour ago, BogusBogey said:

No sorry, I mean the Tunnel IP address. There's indeed the exit/country server, but that server has to know where to send your traffic to, so you get an IP address.

But this ip does not change. 🤔
It's assigned to you at the same time as an ipv6 and your public key, when you register a new device in your customer area on the website.

[BogusBogey 0]

2 hours ago, P.Bear said:

But this ip does not change. 🤔
It's assigned to you at the same time as an ipv6 and your public key, when you register a new device in your customer area on the website.

Oooh, now that makes sense. I did upload a new configuration file (there isn’t any IP address in it, visibly that is, probably encrypted in the key(s)) and when I generated the file I did select my Unifi. Before this I used the config file on the Unifi that I also use on my laptop. So that explains the IP address change. 
Cool, so that’s all sorted! Thank you @P.Bear 👍

 

[BogusBogey 0]

On 10/23/2024 at 10:29 AM, P.Bear said:

But this ip does not change. 🤔
It's assigned to you at the same time as an ipv6 and your public key, when you register a new device in your customer area on the website.

Unfortunately it does. After reading your post I checked and I thought it stayed the same, but after the connection had reset (I had to unplug the ethernet cable just for a few seconds) and later it turned out the IP address had changed. Not very strange but for our purpose here rather unwelcome. I guess it's back to the terminal and use the full lines.

[P.Bear 5]

On 10/27/2024 at 10:38 PM, BogusBogey said:

On 10/23/2024 at 10:29 AM, P.Bear said:

But this ip does not change. 🤔
It's assigned to you at the same time as an ipv6 and your public key, when you register a new device in your customer area on the website.

Unfortunately it does. After reading your post I checked and I thought it stayed the same, but after the connection had reset (I had to unplug the ethernet cable just for a few seconds) and later it turned out the IP address had changed. Not very strange but for our purpose here rather unwelcome. I guess it's back to the terminal and use the full lines.

Frankly, it makes no sense to me. It means that the ip has changed in your account on the website and, more importantly, that you've had to re-upload the new conf file (or change the conf manually) to the UDM Network/VPN/VPN Client ? 
Why would the ip assigned to you by AirVPN suddenly change because your internet connection or UDM router reset ?! Again, that makes no sense.

[BogusBogey 0]

1 hour ago, P.Bear said:

Frankly, it makes no sense to me. It means that the ip has changed in your account on the website and, more importantly, that you've had to re-upload the new conf file (or change the conf manually) to the UDM Network/VPN/VPN Client ? 
Why would the ip assigned to you by AirVPN suddenly change because your internet connection or UDM router reset ?! Again, that makes no sense.

Well I’m not an expert and I was thinking that those IP address were assigned by DHCP? Just like at home with my ISP: the IP address doesn’t change (often) but it’s certainly not fixed. 
But where do you get/find the IP address, it’s not in the conf files that I have generated?

[P.Bear 5]

1 hour ago, BogusBogey said:

But where do you get/find the IP address, it’s not in the conf files that I have generated?

Yes it is in the file and it's fixed. 

So when you say "I had to unplug the ethernet cable just for a few seconds) and later it turned out the IP address had changed":
First, how did you notice the IP had changed ?
And second, you then had to modify your VPN client config and/or update a new generated config file to match the new ip/32 , right ?

[BogusBogey 0]

50 minutes ago, P.Bear said:

Yes it is in the file and it's fixed. 

Ok. Only when I look in the files that I get, I do not see any IP addresses. Aren't you referring to the IP address that's from a particular server/country you want to connect to?
 

50 minutes ago, P.Bear said:

So when you say "I had to unplug the ethernet cable just for a few seconds) and later it turned out the IP address had changed":
First, how did you notice the IP had changed ?

I unplugged the cable, not to test or something. I had to paint a wall, so I had to move my server. 😀
I noticed the IP address had changed, because when I later checked Transmission, it hadn't completed downloading (it barely downloaded anything). So when I opened Transmission preferences > network tab > peer listening port, it showed "Port is closed".
Back to Unifi:VPN>VPN Client -- the Tunnel IP did no longer match the the destination IP in Unify:Routing>NAT>Destination
 

50 minutes ago, P.Bear said:

And second, you then had to modify your VPN client config and/or update a new generated config file to match the new ip/32 , right ?

Nope. When I changed the destination IP address of Unify:Routing>NAT>Destination to the same as the Unifi:VPN>VPN Client Tunnel IP, the peer listening port of Transmission changed to "Port is open".

Edit: ooooh, I now see. With wireguard the IP address is added, with OpenVPN not!
So I guess Wireguard would make a more stable solution?
 

AirVPN_Netherlands_UDP-443-Entry3.ovpn

[P.Bear 5]

Haaa ok. Yes I definitely recommend Wireguard. Your ip won't change anymore (you will see it in the conf file this time) but also because you'll get better speeds

PS: It's my fault, I realize now that in your screenshot it says OpenVPN and I hadn't noticed. So I was convinced you were using WG 😓

[BogusBogey 0]

On 11/1/2024 at 3:51 PM, P.Bear said:

Haaa ok. Yes I definitely recommend Wireguard. Your ip won't change anymore (you will see it in the conf file this time) but also because you'll get better speeds

PS: It's my fault, I realize now that in your screenshot it says OpenVPN and I hadn't noticed. So I was convinced you were using WG 😓

No worries, it's not your fault. The original solution offered by @fisken was with WireGuard and I had to use OpenVPN instead because I assumed... well you get my drift.
Anyway, with Wireguard it runs pretty good and indeed it's much faster. Thank you @fisken for the solution and thank you @P.Bear for your patience 😉

[bbqsquirrel 2]

On 9/25/2024 at 3:13 AM, fisken said:

Here’s how I solved it:

 

1. Setup VPN Interface with Policy-Based Routing:

 

   •   First, I set up WireGuard as the VPN client on my Unifi gateway. Many VPN providers allow you to download a WireGuard config that can be uploaded into Unifi.

   •   Once the VPN is configured, you can create a Policy-Based Route to specify which devices or networks should use the VPN for outbound traffic. This step ensures your internal devices route traffic through the VPN tunnel.

 

2. Solution: Custom Firewall and NAT Rules:

 

To make port forwarding work, I had to set up both a custom firewall rule and a Destination NAT rule.

 

Step-by-Step Setup:

 

   •   Firewall Rule:

   1.   Go to Firewall & Security → Create a new rule under “Internet In”.

   2.   Action: Set to “Accept”.

   3.   Protocol: Select TCP/UDP (or any specific protocol you need).

   4.   Source: Set to Any. Since the traffic is coming from the internet via your VPN, it’s important to allow any source.

   5.   Destination: This should be the internal IP of the device you want to forward traffic to (e.g., 192.168.1.xxx).

   6.   Destination Port: Set the specific port you’re forwarding.

   7.   Save the rule.

   •   NAT Rule (Destination NAT):

   1.   Go to Network Settings and create a Destination NAT rule.

   2.   Set the Interface to your WireGuard VPN interface.

   3.   Destination Address: Set this to the internal IP address from the VPN tunnel (the IP assigned to you by your VPN provider within the VPN network, e.g., 10.x.x.x).

   4.   Translated IP Address: Set this to the local IP of the device in your network (e.g., 192.168.1.xxx).

   5.   Ports: Match the Destination Port to the port you are forwarding.

Did this solution break with the new Network update and new firewall? I my torrent client shows blocked port despite following these directions. In the new firewall I just did source: external zone any with destination of internal, client local IP and matching source and destination ports with the port enabled in AirVPN.  Not sure why not working 

[Mytob 2]

My device has not been offered the update yet so I can’t say unfortunately.

[P.Bear 5]

On 2/23/2025 at 8:34 AM, bbqsquirrel said:

On 9/25/2024 at 12:13 PM, fisken said:

Step-by-Step Setup:

 

   •   Firewall Rule:

   1.   Go to Firewall & Security → Create a new rule under “Internet In”.

   2.   Action: Set to “Accept”.

   3.   Protocol: Select TCP/UDP (or any specific protocol you need).

   4.   Source: Set to Any. Since the traffic is coming from the internet via your VPN, it’s important to allow any source.

   5.   Destination: This should be the internal IP of the device you want to forward traffic to (e.g., 192.168.1.xxx).

   6.   Destination Port: Set the specific port you’re forwarding.

   7.   Save the rule.

   •   NAT Rule (Destination NAT):

   1.   Go to Network Settings and create a Destination NAT rule.

   2.   Set the Interface to your WireGuard VPN interface.

   3.   Destination Address: Set this to the internal IP address from the VPN tunnel (the IP assigned to you by your VPN provider within the VPN network, e.g., 10.x.x.x).

   4.   Translated IP Address: Set this to the local IP of the device in your network (e.g., 192.168.1.xxx).

   5.   Ports: Match the Destination Port to the port you are forwarding.

Did this solution break with the new Network update and new firewall? I my torrent client shows blocked port despite following these directions. In the new firewall I just did source: external zone any with destination of internal, client local IP and matching source and destination ports with the port enabled in AirVPN.  Not sure why not working 

If you've switched to the zone-based firewall and are starting from scratch, you need to make sure that you have a rule in the External/DMZ box (DMZ or whatever the name of the zone where your QbT or other server is located) that allow traffic through on the port in question. This corresponds to FireWall Rule 1 to 7 above ^^
It works for me.

[bbqsquirrel 2]

On 2/26/2025 at 11:18 AM, P.Bear said:

If you've switched to the zone-based firewall and are starting from scratch, you need to make sure that you have a rule in the External/DMZ box (DMZ or whatever the name of the zone where your QbT or other server is located) that allow traffic through on the port in question. This corresponds to FireWall Rule 1 to 7 above ^^
It works for me.

I have the following and allow return traffic is checked. Still show closed port

 

[P.Bear 5]

1 hour ago, bbqsquirrel said:

I have the following and allow return traffic is checked. Still show closed port

 

The source port must be ANY, for torrent (and for virtually all services) because it will be often selected randomly from the dynamic port range.

If you check the box Syslog logging in your rule, you can see the logs in /var/log/ulog/syslogemu.log
I find this very useful. When I switched to ZB firewall, I had created “general” rules for certain zone crossings, with an Allow (or Block) ANY/ANY and had enabled logging. That way I could see in the logs what was passing (or not) and understand if I needed to create a specific rule. This was particularly useful for IoT/External.

[Staff 10114]

Additional article which resolved any problem for a couple of customers:
https://community.ui.com/questions/Port-Forwarding-from-VPN-Interface/7099072b-d3d6-46a6-a3f7-e403f6c00849#answer/17f3676b-c144-4beb-a1e7-9313716945c9

Kind regards
 

[bbqsquirrel 2]

Thanks for everyone's input. I realized the problem ended up being me not paying attention to the features AirVPN provides. In the Client Area, make sure you define a "VPN Device" for the device you're trying to port forward to. Then in the port forward section in the client area, make sure you have the same device selected for the forwarded port. Finally, when you're doing your config generator, make sure you also have the proper device selected when generating your .conf file.

That was the missing piece for me after following fisken's guide. Before I was using just the "default" device and having multiple clients connected under "default" was throwing something off. Just adding it here in case it helps someone in the fture.