ANSWERED Port Forward In Unifi

[Mytob 2]

14 hours ago, P.Bear said:

@Mytob do you use the wireguard protocol or the OpenVPN ?

So let's say your qBt server IP is 10.0.12.9, the port you want to forward is 4321 and the interface of the Wireguard client that you created is the wgclt3

1) You have to forward the port with a rule in the chain PREROUTING of the table nat:

iptables -t nat -I PREROUTING -i wgclt3 -p tcp --dport 4321 -j DNAT --to-destination 10.0.12.9
iptables -t nat -I PREROUTING -i wgclt3 -p udp --dport 4321 -j DNAT --to-destination 10.0.12.9

With WG I noticed that I had to add a rule in the forward chain to let the packets go through. (I don't know why, maybe it is the same with the OpenVPN because of something changed in the recent releases of the unifi OS).
2) So you add the following rule:

iptables -I FORWARD -i wgclt3 -p tcp --dport 4321 -d 10.0.12.9 -j ACCEPT
iptables -I FORWARD -i wgclt3 -p udp --dport 4321 -d 10.0.12.9 -j ACCEPT

Rmq:
a) I use INSERT to add my rules so I'm sure it's it placed at the top of the chains and proceed before everything elese.
b) I also noticed UDP packets coming from the airvpn server. It comes from the port used to connect on it (1637) and those are DROP by the firewall. The host's resolution changes from time to time. So I'm not sure how to deal with this problem. I'm considering opening a ticket to verify if this is a normal behavior, as I wonder why I get such UDP requests.
I could add a rule like:
iptables -I INPUT -i eth8 -p udp --sport 1637 -j ACCEPT
But it's too permissive. 🤔

Thanks very much for the info Have been using OpenVPN without issue apart from the port forwards. Will have a go tomorrow and see what happens!

[zapoteknico 8]

My UDM finally restarted working and connected to AIRVPN so I am back but still with the issue that ports are not forwarded.
I was wondering if someone would be able to create a step by step guide to add the config via SSH as I am not very used to do that with commands (and I am sure many aren't).
I know i might be asking a lot, but such guide would help so many people other than benefit the entire AIRVPN Community allowing many Ubiquity users to also join the AIR VPN Community..
Thank you 

[Mytob 2]

On 11/19/2023 at 8:18 AM, P.Bear said:

@Mytob do you use the wireguard protocol or the OpenVPN ?

So let's say your qBt server IP is 10.0.12.9, the port you want to forward is 4321 and the interface of the Wireguard client that you created is the wgclt3

1) You have to forward the port with a rule in the chain PREROUTING of the table nat:

iptables -t nat -I PREROUTING -i wgclt3 -p tcp --dport 4321 -j DNAT --to-destination 10.0.12.9
iptables -t nat -I PREROUTING -i wgclt3 -p udp --dport 4321 -j DNAT --to-destination 10.0.12.9

With WG I noticed that I had to add a rule in the forward chain to let the packets go through. (I don't know why, maybe it is the same with the OpenVPN because of something changed in the recent releases of the unifi OS).
2) So you add the following rule:

iptables -I FORWARD -i wgclt3 -p tcp --dport 4321 -d 10.0.12.9 -j ACCEPT
iptables -I FORWARD -i wgclt3 -p udp --dport 4321 -d 10.0.12.9 -j ACCEPT

Rmq:
a) I use INSERT to add my rules so I'm sure it's it placed at the top of the chains and proceed before everything elese.
b) I also noticed UDP packets coming from the airvpn server. It comes from the port used to connect on it (1637) and those are DROP by the firewall. The host's resolution changes from time to time. So I'm not sure how to deal with this problem. I'm considering opening a ticket to verify if this is a normal behavior, as I wonder why I get such UDP requests.
I could add a rule like:
iptables -I INPUT -i eth8 -p udp --sport 1637 -j ACCEPT
But it's too permissive. 🤔

So just tried what you have posted with my own settings and as before I just get connection refused. Have tried turning off windows firewall just incase but no difference.The only thing I cant verify is the tunnel name s I cant work out how to find it 😃 I assume it should not have changed from the last attempt as I have not recreated it?

[P.Bear 5]

10 hours ago, Mytob said:

The only thing I cant verify is the tunnel name s I cant work out how to find it 😃 I assume it should not have changed from the last attempt as I have not recreated it?

I assume you use wireguard VPN client. From the UDM CLI, run the command:

ifconfig | grep -A1 wgclt

It will give you every WG tunnel interface and the ip associated. This ip is the tunnel IP that you can also find in the VPN client configuration through the web interface of the UDM. So you can identify the wgclt interface used for your AirVPN connection. This is the one you must use for your iptables rules.

(From the UDM CLI) give the output of :

iptables -t nat -S PREROUTING
iptables -S FORWARD

[Mytob 2]

On 11/23/2023 at 6:46 AM, P.Bear said:

I assume you use wireguard VPN client. From the UDM CLI, run the command:

ifconfig | grep -A1 wgclt

It will give you every WG tunnel interface and the ip associated. This ip is the tunnel IP that you can also find in the VPN client configuration through the web interface of the UDM. So you can identify the wgclt interface used for your AirVPN connection. This is the one you must use for your iptables rules.

(From the UDM CLI) give the output of :

iptables -t nat -S PREROUTING
iptables -S FORWARD

Thanks for the info! Have just tried again and can confirm it works under WireGuard but for some reason it seems to break DuckDuckGo and I have no idea why. Tried all the normal things like clearing the cache / rebooting the PC but no luck. Not sure if its the server I was connected to maybe but somthing to play areound with when I have a bit of time =)

[B3NJAMIN 3]

On 11/19/2023 at 9:18 AM, P.Bear said:

@Mytob do you use the wireguard protocol or the OpenVPN ?

So let's say your qBt server IP is 10.0.12.9, the port you want to forward is 4321 and the interface of the Wireguard client that you created is the wgclt3

1) You have to forward the port with a rule in the chain PREROUTING of the table nat:

iptables -t nat -I PREROUTING -i wgclt3 -p tcp --dport 4321 -j DNAT --to-destination 10.0.12.9
iptables -t nat -I PREROUTING -i wgclt3 -p udp --dport 4321 -j DNAT --to-destination 10.0.12.9

With WG I noticed that I had to add a rule in the forward chain to let the packets go through. (I don't know why, maybe it is the same with the OpenVPN because of something changed in the recent releases of the unifi OS).
2) So you add the following rule:

iptables -I FORWARD -i wgclt3 -p tcp --dport 4321 -d 10.0.12.9 -j ACCEPT
iptables -I FORWARD -i wgclt3 -p udp --dport 4321 -d 10.0.12.9 -j ACCEPT

Rmq:
a) I use INSERT to add my rules so I'm sure it's it placed at the top of the chains and proceed before everything elese.
b) I also noticed UDP packets coming from the airvpn server. It comes from the port used to connect on it (1637) and those are DROP by the firewall. The host's resolution changes from time to time. So I'm not sure how to deal with this problem. I'm considering opening a ticket to verify if this is a normal behavior, as I wonder why I get such UDP requests.
I could add a rule like:
iptables -I INPUT -i eth8 -p udp --sport 1637 -j ACCEPT
But it's too permissive. 🤔

Hi,
I have the same problem.

i can add the prerouting but when i want to add the forward rule i get a error

iptables -t nat -A PREROUTING -i tunovpnc2 -p tcp --dport 54930 -j DNAT --to-destination 192.168.30.135

iptables -A FORWARD -i tunovpnc2 -p tcp --dport 54930 -d 192.168.30.135 -j ACCEPT
iptables v1.8.7 (legacy): Couldn't load target `ACCEPT ':No such file or directory


i'm running Network 8.1.113

[B3NJAMIN 3]

This night I couldn't sleep and I've been searching a bit about iptables, I finally got it working


iptables -t nat -I PREROUTING -i tunovpnc2 -p tcp --dport 54930 -j DNAT --to-destination 192.168.30.135:54930
iptables -I FORWARD -d 192.168.30.135/32 -i tunovpnc2 -p tcp --dport 54930 -j ACCEPT

[P.Bear 5]

And be aware that sometimes UDM scripts reset iptables chains as it would like. So from time to time you have to check and reintroduce the rules.
Personally, I made a script in python (before it was in bash) that checks iptables rules and reinjects the rules if needed. The script runs periodically in crontab.

[B3NJAMIN 3]

thanks for the tip.
I haven't had my UDM for long, I'm still learning 🙂

Could you perhaps give me an example of how to do that?

[P.Bear 5]

You mean with python ?

I've created different python lists, for each iptables and ip6tables chains. In each list I've put all the rules that I want to add.

So the python script checks the rules in each chain and compares with the corresponding python list and then corrects what needs to be corrected.
(The script also creates some required ipsets and be careful not to add duplicate rules, which iptables allows without warning..).
The script runs every 30 minutes.

By the way with the iptables of the UDM includes the geoip module. So you can block countries per port/services, which the UDM interface does not allow! (With the UDM interface you can block countries, in IN, in OUT, or both, but it’s for the whole WAN connection, we can’t do it on a service basis). So I take the opportunity to do it via an iptables rules.
For example I block some countries on the qBt port of the airvpn:

iptables -A FORWARD -d 10.0.12.12/32 -i wgclt4 -p udp -m udp --dport 45781 -m geoip --source-country CN,RU,BY,DZ,CF,GA,GH,CI,ZA  -j BLOCK_BAD_COUNTRIES_QBT

 

[B3NJAMIN 3]

Thank you for the explanation.
But I can't seem to figure out how to get started with Python, I still have to do some research there.

[BogusBogey 0]

On 4/11/2024 at 8:18 PM, P.Bear said:

-m geoip --source-country CN,RU,BY,DZ,CF,GA,GH,CI,ZA  -j BLOCK_BAD_COUNTRIES_QBT

Can you share what's happening in/with BLOCK_BAD_COUNTRIES_QBT?

[P.Bear 5]

Hello,

I DROP. But I log at the same time, with a related log-prefix so if I have to do a search one day it’s easier.
 

root@UDM-SE-Home-FR:~# iptables -S BLOCK_BAD_COUNTRIES_QBT
-N BLOCK_BAD_COUNTRIES_QBT
-A BLOCK_BAD_COUNTRIES_QBT -j LOG --log-prefix "Block QBT bad countries: "
-A BLOCK_BAD_COUNTRIES_QBT -j DROP

[foobyairvpn 0]

On 11/19/2023 at 8:18 AM, P.Bear said:

@Mytob do you use the wireguard protocol or the OpenVPN ?

So let's say your qBt server IP is 10.0.12.9, the port you want to forward is 4321 and the interface of the Wireguard client that you created is the wgclt3

1) You have to forward the port with a rule in the chain PREROUTING of the table nat:

iptables -t nat -I PREROUTING -i wgclt3 -p tcp --dport 4321 -j DNAT --to-destination 10.0.12.9
iptables -t nat -I PREROUTING -i wgclt3 -p udp --dport 4321 -j DNAT --to-destination 10.0.12.9

With WG I noticed that I had to add a rule in the forward chain to let the packets go through. (I don't know why, maybe it is the same with the OpenVPN because of something changed in the recent releases of the unifi OS).
2) So you add the following rule:

iptables -I FORWARD -i wgclt3 -p tcp --dport 4321 -d 10.0.12.9 -j ACCEPT
iptables -I FORWARD -i wgclt3 -p udp --dport 4321 -d 10.0.12.9 -j ACCEPT

Rmq:
a) I use INSERT to add my rules so I'm sure it's it placed at the top of the chains and proceed before everything elese.
b) I also noticed UDP packets coming from the airvpn server. It comes from the port used to connect on it (1637) and those are DROP by the firewall. The host's resolution changes from time to time. So I'm not sure how to deal with this problem. I'm considering opening a ticket to verify if this is a normal behavior, as I wonder why I get such UDP requests.
I could add a rule like:
iptables -I INPUT -i eth8 -p udp --sport 1637 -j ACCEPT
But it's too permissive. 🤔

Just wanted to say this worked for me, so thanks for the reminder. 

As always peeps you've got to allow it into prerouting as above, but then iptables doesnt forward that prerouting on unless you do the 2nd rule.

My only question would be, does the usual iptables-save /etc/iptables/rules.v4 work or does ubnt save that somewhere else?

[P.Bear 5]

@foobyairvpn I don't have an ubnt but for the UDM, it does not. I don't know where and how it saves the fw rules.
Check from time to time if your personal rules do not disappear. If that’s the case, I’m afraid you have to set up a little crontab script to put them back as soon as they disappear, like I did.

[nan0tEch 1]

So to recap this should work? @P.Bear
 

iptables -t nat -I PREROUTING -i wgclt1 -p tcp --dport 54321 -j DNAT --to-destination 192.168.10.51
iptables -t nat -I PREROUTING -i wgclt1 -p udp --dport 54321 -j DNAT --to-destination 192.168.10.51

iptables -I FORWARD -i wgclt1 -p tcp --dport 54321 -d 192.168.10.51 -j ACCEPT
iptables -I FORWARD -i wgclt1 -p udp --dport 54321 -d 192.168.10.51 -j ACCEPT

iptables -A FORWARD -d 192.168.10.51/32 -i wgclt1 -p tcp -m tcp --dport 54321 -m geoip --source-country CN,RU,BY,DZ,CF,GA,GH,CI,ZA  -j BLOCK_BAD_COUNTRIES_QBT
iptables -A FORWARD -d 192.168.10.51/32 -i wgclt1 -p udp -m udp --dport 54321 -m geoip --source-country CN,RU,BY,DZ,CF,GA,GH,CI,ZA  -j BLOCK_BAD_COUNTRIES_QBT

iptables -N BLOCK_BAD_COUNTRIES_QBT
iptables -A BLOCK_BAD_COUNTRIES_QBT -j LOG --log-prefix "Block QBT bad countries: "
iptables -A BLOCK_BAD_COUNTRIES_QBT -j DROP

[P.Bear 5]

@nan0tEch Hello,

Yes it seems good to me. (So 192.168.10.51 must be the ip of the Qbt container/vm/server and wgclt1 is the WG interface corresponding to the one connected to AirVPN).

Just be sure to DROP before you ACCEPT.
So when you list your FORWARD rules (iptables -S FORWARD), those 2 lines:

iptables -A FORWARD -d 192.168.10.51/32 -i wgclt1 -p tcp -m tcp --dport 54321 -m geoip --source-country CN,RU,BY,DZ,CF,GA,GH,CI,ZA  -j BLOCK_BAD_COUNTRIES_QBT
iptables -A FORWARD -d 192.168.10.51/32 -i wgclt1 -p udp -m udp --dport 54321 -m geoip --source-country CN,RU,BY,DZ,CF,GA,GH,CI,ZA  -j BLOCK_BAD_COUNTRIES_QBT

must appear before those:

iptables -I FORWARD -i wgclt1 -p tcp --dport 54321 -d 192.168.10.51 -j ACCEPT
iptables -I FORWARD -i wgclt1 -p udp --dport 54321 -d 192.168.10.51 -j ACCEPT

Otherwise it would accept without checking the country source.
So, if you write those 4 rules in this order, change "iptables -A" for a "iptables -I" because -I will always INSERT at the beginning of the rules.


 

[nan0tEch 1]

@P.Bear Thx for your input. Coming from pfsense+ to the udm pro i miss out on the full controle of all the settings like DNS, firewall and port-forwarding. iptables is new for me, seems like a long progression.

[P.Bear 5]

@nan0tEch Yes I come from pfsense too. My pfsense box is now at my parent's home in another country and I connect to it from my UDM with Wireguard.

I miss a lot of functionalities too. We shouldn’t have to get our hands dirty (iptables). In fact, it’s the UDM/unifi that is really bad at the firewall level. 
They added Wireguard client support well after all their competitors in the market. And they still don’t support the site-to-site in Wireguard, nor the Wireguard in ipv6. In 2024 ... 😕

[flat4 87]

On 7/9/2024 at 3:52 AM, P.Bear said:

@nan0tEch Yes I come from pfsense too. My pfsense box is now at my parent's home in another country and I connect to it from my UDM with Wireguard.

I miss a lot of functionalities too. We shouldn’t have to get our hands dirty (iptables). In fact, it’s the UDM/unifi that is really bad at the firewall level. 
They added Wireguard client support well after all their competitors in the market. And they still don’t support the site-to-site in Wireguard, nor the Wireguard in ipv6. In 2024 ... 😕

I love UNIFI hardware but what you stated about the firewall is the only reason that pFsense continues to be my edge device. 

[P.Bear 5]

56 minutes ago, flat4 said:

I love UNIFI hardware but what you stated about the firewall is the only reason that pFsense continues to be my edge device. 

I hesitated a long time. But I needed a UDM to manage the cameras (and a nvr).
For the AP’s I was using the manager into a docker container but it was less handy. 

i could have put the UDM behind the pf box but it would mean double nat, with all the problems that go with. 
 

[BogusBogey 0]

@P.Bear Is it possible to use the Unifi interface for these rules, specifically the NAT masquerade?
Something like this:

(The above doesn't work by the way, maybe I do something wrong or it won't work at all?)
 

[Mytob 2]

Not that I am aware of currently. They did put out a new update lately which I have not fully explored but as far as I’m aware it still does not allow for it.

[P.Bear 5]

Hello, same @Mytob I don't think so but I haven’t had the chance to test these new features yet. 
What we would need is just to be able to choose one of the WG (or OpenVPN) interfaces in the security/port fowarding menu.

[fisken 4]

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.