Problem with Simple UDP Port Forward

Hi - I am hoping someone can help me. I am using the current LEDE version. I have tried this on two different routers (it is not a router issue). I use Luci for firewall configuration and make no other firewall changes other than two port forwards - 1 for SSH remote access TCP port 2222 and the other for UDP port 11948 for an OpenVPN Server running on my network.

I am having no issue with TCP ports as they scan and open up fine. However, I can't seem to open up a UDP port. I know this because my client cannot access my OpenVPN Server plus my port scan tool shows 11948 as closed.

My firewall rule after entering in Luci is:

config redirect
option enabled '1'
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'udp'
option dest_ip 'ip address of my open vpn server'
option dest_port '11948'
option name 'Allow VPN'

Pretty basic. Again, have made no other changes to the standard firewall rules that load as default other than a TCP port forward that is working.

Hoping someone can help.

Thanks.

@tally

No idea if this matters, but you might try removing the space from the name of the DNAT redirect (make it "Allow-VPN")... just in case that space is causing the rule to error out.

Assuming that doesn't help...
Is this port forward happening on the primary router (WAN port connected to your ISP)? I assume so, but just in case, remember that the port forwards must happen on the internet facing router or they will obviously not work from the internet.

Is the OpenVPN server on the same physical device as your primary router, or is it a different piece of hardware? Have you verified that the OpenVPN server is running on the port you specified and that any associated firewalls on that device are set appropriately? If the service is not running, or if there are secondary firewalls interfering (such as one on a normal computer or a second router), the port scan will come back as closed, even the firewall has forwarding configured properly.

Start with a local LAN port scan to make sure that the OpenVPN server IP shows the port as open and then try to connect directly with the LAN IP address (not your WAN address). If that doesn't work, try debugging the OpenVPN server as it may be the issue.

Keep in mind, the question about the OpenVPN device is critical -- if the server is running on a different device (relative to the internet router), make sure that the IP address you're using is the LAN IP of that server, not the OpenVPN server address set in the config file (which, by the way, must be a different subnet than your main LAN if you're running tun mode). On the other hand, if it is running on the primary internet router, things work a bit differently. Try making it an open port to the router rather than a DNAT redirect rule. Something like this:

config rule
	option target 'ACCEPT'
	option proto 'udp'
	option dest_port '11948'
	option name 'Allow-VPN'
	option src '*'

The case above assumes the OpenVPN server is running on the same router as the internet, with a source wildcard so it will work from the LAN or the WAN.

@psherman Thanks so much for the reply.

The option name is in my firewall rule correct - I retyped it and missed the "-" / it says Allow-VPN.

The OpenVPN Server is on a separate device on the same subnet within my LAN.

When I scan the router ipaddress with nmap to check if the port is open on the router or not - I receive this response:

PORT STATE SERVICE

11948/udp closed unknown

Note that I am new to firewall setup. Shouldn't the scan (via the rule I setup) yield that port being open on the router (which is facing the internet) - in effect allowing activity from an openvpn client (at a different location outside my LAN) to pass its data over the internet through my router on that open port?

I also deleted my rule and inserted yours. I still cannot reach my openvpn server. I also scanned my router again with "nmap -sU -p 11948 192.168.1.1" within my LAN. It still shows that the port is closed. What is odd is that when I scan my other firewall open TCP port (2222 with the same rule but TCP proto specified), it does show the port open with the rule enabled and then the port closed with the rule disabled.

I may be looking at this incorrectly; but I am first attempting to troubleshoot at step 1, which is to make sure the firewall rule is working and port 11948 is actually open on my router when that rule is enabled; and it appears not to be working correctly no matter what UDP rule i specify - yet the same works properly with TCP.

In fact, I will bet if I change my OpenVPN server to run under a TCP port (more inefficient), it will work. I did not want to do that however as I want to run under UDP. Any further thoughts? Thanks again.

@tally - If you aren't seeing your OpenVPN server showing the port open, you should start there and work out towards the internet.

I'll take a few guesses here, but it would be best if you provided specifics about your network.

What is the LAN IP address of your router? And what about the IP address of your OpenVPN server? Is the OpenVPN server running on a traditional computer (i.e. Mac, Linux, Windows), or is it on say another router or a Raspberry Pi or something like that? What OS is it running? Have you verified that the OpenVPN server is running properly from the startup messages/logs on the OpenVPN server device? How about any firewalls on that device -- have you checked to make sure the right port is open there? Or better yet, have you just tried to connect using an OpenVPN client (with the client configuration pointing to your internal LAN IP for the OpenVPN server. This needs to work first or the rest is kind of pointless (and much harder to diagnose).

You did an nmap port scan on 192.168.1.1 -- for many people, this is the router. You need to do a port scan on the IP address of your OpenVPN server. If, however, that really is the OpenVPN server system, then the fact that you don't see an open port there points to the fact that the OpenVPN server and/or the firewall on that device is not properly configured.

BTW, since you have the OpenVPN server on another device, you should revert back to the firewall rule you had previously... but this is of secondary concern until you can prove that everything internally is working.

@psherman - I thought I would post back on what my problem was and the solution I stumbled upon. Under port forwards in my firewall rules I have a rule to open up my router on port 2222 for remote ssh. I had that rule first and the firewall rule to open up the openvpn port 11948 second. When I moved the openvpn up as the first port forward rule, then it worked and that was the solution. I have no reason why this is the case. I can tell you this also happened on another network I was working on attempting to open an entirely different port where it was also not working until I moved the rule up in the chain ahead of my ssh rule.

Is this a bug or am I missing something? At any rate, I thought I would post back as this might help someone else having an issue like this.

@tally - Wow.. I never would have guessed that one. Glad you got it working! I have no idea why the rule order for port forwarding would matter, but maybe there is a nuance in the specifics of the firewall config in this case.

Are they both port forwards (i.e. through the router to another host on your network), both port 'opens' (destination is the router itself - the 'local' zone)? Or one of each?

Out of curiosity, did you try this with LuCI, command line, or both? In some cases, you can explicitly set the rule order in LuCI, but certain times this may not be an option -- I'd be curious if the necessary rule order happens automatically with LuCI, if you can manually adjust via LuCI, or if the rule order is purely related to the order of creation and then you'd have to go in and tweak via the command line. I'd be curious if it is obvious when looking firewall config file how it would behave within LuCI.

@psherman - yes both are port forwards. On one, the destination is the router itself (the SSH rule) and the other the destination is a specific device within my LAN for my open vpn server. I used Luci to set the rules up then just shift the order using Luci itself. The rule order in Luci is automatic - that is the first rule you type in is the first, the second is the second, etc. You shift order by using an up or down arrow; and then the order itself is changed in your config file.

I cannot really pin down why this is an issue. Now that I think about it. I setup different router (same Lan) replacing an older router a few days ago and typed the rules into Luci again. The same issue occurred with open vpn not working; and this time I had to shift the openvpn firewall rule down one (below the ssh rule) for it to work!

Maybe the problem is within Luci itself and how it creates the rules. However, when I look at the config files after I type the rules into Luci, everything looks correct. I just know it works when I shift the rule order. Very odd.

@tally - the reason I was asking about your port-opening needs and process is that there may be an optimal way to open ports when if comes to the Firewall > Traffic Rules vs the Firewall > Port Forwards, and I was wondering if the two 'sections' of the firewall rules were ordered properly in your config file (port forwards vs traffic rules).

More specifically, typically when opening a port where the destination is the router itself, it is often preferred to use the Traffic Rules section. And along the same lines, when opening a port from the WAN to a machine on your LAN that is not your router, Port Forwards is usually the correct method. There are some exceptions to this advice, but in general, opening ports in the 'wrong' firewall section can cause some of these types of issues.

I am very familiar with the LuCI interface and how it has the arrows to allow a specific ordering of rules. The other reason I was asking is because the order both matters and doesn't matter.

  1. It matters -- in that the rules are processed in the order they are listed. If your first rule was "drop all traffic," nothing else gets through and the following rules do nothing. But if your first rule is "allow [x] traffic" and then your 2nd rule is "drop all traffic", then you know that it will allow [x] traffic and block all else.

  2. It does't matter -- in that, properly crafted rules for simple tasks like port forwarding should not interfere with each other, regardless of the order. It seems like something in one or both of the rules might be misconfigured or overly broad such that the rules are conflicting in a specific order. And for unrelated port forwards, it shouldn't matter.

Could you post your firewall config? or just the two rules in question? I'd love to see what you've got on those -- I think that they can be further optimized.