Ihave a single client on my Isolated network running NextCloud. I have setup port forwarding rules under NAT to port 443 to that particular client and this works fine when trying to access it externally.
However as soon as I enable my Express VPN client in pfSense I am no longer able to access my NextCloud instance. I have setup some policy based routing on my IoT network (there are some clients I want to route through ExpressVPN) but I have no rules on my Isolated network to make use of that VPN.
How can I port forward NAT traffic on a public IP of the main router to a server behind the NAT of the second? So for instance port 95 on a public IP assigned to the main router forwards to 10.12.1.102 on the other router.
I have never tried to use SIP via an outbound OpenVPN with port forwarding. Not really sure if that would work. The way I usually see it done is by running OpenVPN on FreePBX and because the phones are connecting directly to the server, no ports need to be forwarded.
my quick look tells me you're perhaps not creating a firewall rule on the correct interface. You've got a port forward rule for airvpn_wan_WG_0 but you're not showing a corresponding firewall rule for that interface for port forwarding. when you create the port foreward rule use the filter rule association option at the bottom of the port forward rule setup to create new associated filter rule. this will automatically put the necessary firewall rule on the correct interface.
also you're using an alias for NAT IP for the port forward rule. this should be the IP of the device running the server. I see no reason for an alias as it should be just one local IP, e.g. 192.168.2.22.
again, no reason for an alias for destination ports and NAT ports as AirVPN port forward rules can only forward 1 port each.
FWIW, I had a similar problem when I first set up Air port forwarding in dd-wrt to allow incoming connections to a wireguard server. Ultimately I solved it with an "ip rule..." (in linuxspeak) command in the wireguard interface's up script, and the corresponding removal of the rule in the downscript. The rule details routed all packets with the source port in question (dest port when Air routed incoming so source for replies) via the routing table associated with the VPN tunnel used for the forwarding. That tunnel had a separate routing table because Policy Based Routing (PBR) was in use.
If that's all gobbledygook, you have my sympathies. Let's just say that I had to study up on routing tables, the rule table, PBR, and the ip command to get there, and I burned plenty of hours. And after all that, it may not be at all the best way to solve the problem! But the kludge that it is seems to be working on several routers and has been for over a year. Hope you get lucky and find something easier!
There was somewhere a post about a similar problem, and maybe it was on this forum, pfsense or opnsense. I can't find it though. As far as I remember, the problem was with the autogenerated firewall rule. It didn't have proper gateway (or something similar) in advanced options. You can't modify auto-generated rules, so you need turn off auto-generated rule in port forwarding rule, setup it up manually and ensure gateway (or a similar option) is properly set.
PS. sorry for the vague post, but I hope this at least gives you some pointers where to look.
also you're using an alias for NAT IP for the port forward rule. this should be the IP of the device running the server. I see no reason for an alias as it should be just one local IP, e.g. 192.168.2.22.
There was somewhere a post about a similar problem, and maybe it was on this forum, pfsense or opnsense. I can't find it though. As far as I remember, the problem was with the autogenerated firewall rule. It didn't have proper gateway (or something similar) in advanced options. You can't modify auto-generated rules, so you need turn off auto-generated rule in port forwarding rule, setup it up manually and ensure gateway (or a similar option) is properly set.
PS. sorry for the vague post, but I hope this at least gives you some pointers where to look.
I did see some posts changing the rules from automatic to hybrid/manual, Mine is set to manual as I really don't want rules being made that I didn't explicetly make myself. That said, I really want to try and replicate this issue on Opnsense, just not looking forward to the few hours of slowly duplicating all the settings over to find that it's still not working because of a setting I'm doing, but I guess there's only one way to find out
The issue is that OpenVPN Access Server does not support working behind a proxy server so some features are currently not working. As we only have 1 external IP and we have no possibilities to add some extra, i try to find a way to get OpenVPN AS working and hosting some website's (on other servers) at the same time.
I was thinking, maybe i can "route" traffic to
vpn.company.com (443) directly from pfSense (dns based port forwarding or something???) to the OpenVPN AS and all other traffic (port 443) to the Nginx proxy server. This would make the network looking like this:
DNS-based port forwarding isn't a thing. The transport layer has no idea about DNS names. The only way to do something like that is with an application-layer (aware) proxy and, of course, an application-layer protocol that uses host names, like HTTP.
With just a single IP address, you'll need a dedicated TCP port for OpenVPN (and probably one for UDP, too). Forwarding that to the AS should be no problem on the pfSense. You can change OpenVPN's TCP or UDP ports during installation or afterwards: -server-resources/advanced-option-settings-on-the-command-line/
Another approach would be policy-based forwarding, depending on the source address of an external packet. That way, you could theoretically forward known VPN clients to the OVPN AS and the rest of the Internet to your web servers. I don't think that's practical, however.
What are your current firewall rules on the USG? I have not worked with a USG, but I feel as though even with port forwarding setup, you may need to have a firewall rule set to allow external traffic to pass to your internal subnet.
Just as an update for this. i ended up adding the PFsense box as an Edge router and gave it back its existing Wan IP. I just happened to have an unused WAN IP (ISP gives blocks of 5). So I gave the Unifi Gateway one. setup the static routes and bingo. VPN back up and the Unifi & PFsense coexist peacefully.
possible maybe something has changed on the linux box you are connecting to? Im using vultr and that is still working. Although i have to admit i have not updated the OS on that box for a long time ...
Im on a trip again and I reinstalled my laptop a while ago and i dont have the key with me right now to login to the linux box if you need those (which are basically the same as yours above anyway)...
Cheers! Interesting about the openvpn back to your network, i tried it with wireguard but didn't have any luck. Might give it another shot with openvpn although i have started using tailscale which works really well (except for the radios as its wireguard based and doesn't support UDP broadcast)
Port forwarding has no impact on speed itself. It just gives you a potentially wider pool of peers you can connect to, which indirectly helps with speed only because you can possibly connect to more sources.
If PIA is configured to forward you a port and it is also enabled on the VPN client within the container, then the last step is to configure deluge to listen on that port. With both the vpn and torrent client running in the same container, everything you need to touch is also within the container.
Should have gotten into the Logs in the first place. Rookie mistake. Looks like DelugeVPN is smart enough to assign new IP/Port Forward for VPN. Ports are good. So the speed is not a port issue.
image920482 60.3 KB
Now I am trying to forward some ports through the VPN tunnel, like RDP for instance. I tried it before with openvpn client installed directly on windows VM. I was able to forward rdp directly to the VPN IP of the windows VM. Trying the same with forwarding the port to openvpn client on openwrt in order to forward this port further already on this device and that fails.
What is interesting that I have full communication working between vpn server and vpn client: ping etc. I can also telnet the ports that I have opened on the vpn client IP from the vpn server, but port forwarding doesnt work.
Ok, so then the blurred out bit in the screenshot above should be the unRAID IP. @Luigi408, let us know if this NAT port forward rule in pfSense fixes it. If not we need to look at the unRAID side of things.
Thanks for your help. I previously did do the port forwarding on my pfSense and that didn't work. I have it exactly as you do @teladog01. I already had UPnP enabled on my pfSense as well. These settings did nothing at all to open up the port to allow the Channels DVR unRaid docker to work with Remote Access.
I also think it could be the unRaid server and the Channel Docker not working correctly. All my other Docker apps (such as Plex) work fine over my network. They can automatically assign ports on my pfSense through UPnP. The only thing I had to do with my Plex was add a private-domain: "plex.direct" to my DNS resolver setting (DNS rebinding) to make it work internally. (I reinstalled the Channels DVR docker and redid all my settings, but it installs that way anyways without the port showing up like all the other Dockers).
I noticed that the Channels DVR doesn't have a port assigned to it like my other Dockers (as shown in the picture). Could this possibly be the issue why I can't port forward successfully? This is the only thing I can think of right now.
After a port has been forwarded, a user outside of the local network can navigate to a domain name, DDNS hostname, or external IP address, append the port number that was forwarded and access that service.
3a8082e126