Port forwarding on VPN to test machine isn't working
-
@untouchedwagons
So you should at least see the packets also on the internal interface with that. However, as mentioned, with that rule on the OpenVPN tab allowing any, the access to the webserver will fail.Consider it is required that the destination address in the port forwarding is unique. Since it is hidden in your image, I cannot verify.
-
I think the allow everything rule in the openvpn tab is for the openvpn server I have set up. If I disable that rule and on my phone VPN into my router my phone can't access anything.
Here is a picture of the port forward rule with the destination IP fixed.
-
@untouchedwagons
The OpenVPN tab is an interface group indeed. It includes all OpenVPN instances running on pfSense.
Rules on interface group tabs have priority over rules on the included interfaces.So either you have to change the rule set there so that the allow rule is not applied or assign an additional interface to the server where you may add the appropriate rules and remove the OpenVPN rules.
-
Okay I assigned an interface to my openvpn server and moved the rule in the OpenVPN Tab to the interface I created. I also renamed the VPN client interface to VPN_Client to make it easier to track. However I still can't access the web server through the VPN. Does the firewall rule get applied before or after the port forward rule?
-
I checked the states page and I saw this listing in the table. It seems like the connection is getting through the router, I'll check to see if maybe my web server has some sort of firewall of its own running.
[Edit] There doesn't appear to be a firewall in the way, but I'm not 100% sure.
-
@untouchedwagons said in Port forwarding on VPN to test machine isn't working:
Okay I assigned an interface to my openvpn server and moved the rule in the OpenVPN Tab to the interface I created. However I still can't access the web server through the VPN.
I was not expected that you succeed yet by doing these changes. As I already mentioned above, there might be another problem else, since you don't see packets at the internal interface.
These changes only affect response packets from the server. When a rule on the OpenVPN tab or a floating is applied to the incoming packets, pfSense direct responses out to the default gateway and so the communication will fail, cause the incoming interface is not unique in such rules and cannot be determined.You can find details of the Ordering of NAT and Firewall Processing in the pfSense docs.
@untouchedwagons said in Port forwarding on VPN to test machine isn't working:
I checked the states page and I saw this listing in the table. It seems like the connection is getting through the router, I'll check to see if maybe my web server has some sort of firewall of its own running.
So there must be any firewall rule allowing it.
I'd recommend to to set unique descriptions and enable logging for all appropriate firewall rules, all on the VPN tabs and all floating. Also disable pfBlockerNG and proxy if you're running.
After you can see in the firewall log which rule is applied to the traffic, either blocking or passing it.Also the Packet Capture on pfSense is the tool of choice to definitely narrow down such problems.
As I already stated, do a capture on both interfaces, the VPN and the internal one facing to the web server, best both simultaneously, and try to access the port from the internet. Ensure that you type "http://" in front of the IP, not "https"!
If you see the packets on the VPN but not on the internal interface, as you stated above, they don't pass pfSense. So there is no need to play around with the web servers firewall at this point.
Better to provide the capture results here so other can analyze it. -
I tested my current setup on my phone while using a different VPN setup and it seems to be working: http://104.254.90.235:45578/ I don't understand why it won't work on my desktop computer.
-
@untouchedwagons
You cannot access your internal web server by using that public IP from inside your network. This would only work with an additional NAT rule. -
It's not actually essential for me to be able to access the web server from my LAN but I don't understand, my VPN Client interface doesn't have the IP of 104.254.90.235 so how does my router decide to do anything but send the connection out the WAN interface?
-
@untouchedwagons
The problem is not the destination address, but the route back the response packets have to take to your LAN PC.Consider that a network communication always consists of two parts, request and respond. If your PC requests the IP 104.254.90.235 it sends its packet to pfSense, cause this is the default gateway. Accordingly to its routing table pfSense forwards the packet to the WAN gateway, but translates the source IP in the packet into its own WAN IP. The request packet will take its way through the internet and reach your VPN provider who owns 104.254.90.235. Now the provider forwards it over the vpn to your pfSense, where it is forwarded again to your web server.
The destination IP in the packet changes two times on the way, once at the vpn provider, who changes it into your virtual vpn IP and a second time on your pfSense, to forward it to the web server. But the source IP in the packet is still your WAN IP, when the it arrives on your web server. So the server send his respond to your own WAN address, which is directed to pfSense though, but pfSense is not expecting it on the internal interface, but on the WAN.
So you have a controversy. The packet is destined to pfSense though, but it doesn't match to its state table. In the end pfSense will drop the packet and the connection fail.Besides of natting, either the destination or the source, it may also work if you edit your rule and enable the sloppy state behavior.
-
Okay I understand. I tried the sloppy state behaviour tweak and it didn't work, but that's okay. As long as the forwarding works for everyone else once I get this set up proper, that'll be good enough.
Thanks