Faulty documentation on Port Forwarding??
-
Hello,
A simple project - forward all traffic to ports 443 and 8080 to an internal server.
Internal IP scans verify that the ports are open.
Followed PFSense instructions to forward ports.
Go to FIREWALL -> NAT
Verify PORT FORWARD is selected
Click on PLUS sign to add a new entry
DISABLE RULE and No RDR - Not checked
Interface - WAN
Protocol - TCP/UDP
SOURCE - Any
Source Port Range - 8080
Destination Port Range - 8080
Redirect Target IP - 192.168.4.20
Redirect Target Port - 8080
XMLRPC - not checked
NAT Reflection - not checked
Filter RULE Add - yes to automatically create a firewall rule
SAVE
APPLY
End..
Scan for open port from my outside IP address (static) and the port shows closed…
I have removed and added this port forward several times... slowly and methodically based on instructions given by PFSense docs and it still does not work.
This should have taken 5 minutes to accomplish and now it has been hours.
Anyone to help out a little would be greatly appreciated.... PFSense moderators possibly?
Thank you for any help you can give
-
Change source port to "any".
-
Checked for Source Port - ANY … verified and re-scanned ... no luck on open ports for 443 or 8080...
-
When you created your NAT rule did you have Filter rule association set to "Rule NAT"? In other words, what are the parameters of the rule that was created in the WAN tab after you created the NAT rule?
The associated WAN rule to your NAT should be IPv4 TCP/UDP, *, *, 192.168.4.20, 8080, *, none, blank.
-
WAN Rule is as follows:
PROTO - TCP/UDP
SOURCE *
PORT *
DESTINATION - 192.168.4.20
PORT - 8080
GATEWAY *
QUEUE - None
SCHEDULE - Blank
-
Looks like your rules are correct, should work. So a port scan on the LAN reveals 192.168.4.20:8080 open and a remote scan of your WAN adapter doesn't show port 8080 open, is that correct?
Presume you don't have another port 8080 rule or a rule that in some way conflicts with these rules. You might also try going to STATES and reset your states, then rescan the Wan port.
-
You are correct on the LAN scan results are positive and WAN scan is negative (port not open)… I will look for STATES ... Must be part of the Web interface tabs... :)
-
and is it possible that 8080 is blocked inbound to your wan.. Is your wan behind a NAT? quite often I find users put pfsense behind a NAT.. either because their "modem" as they call them doesn't allow bridge mode.. Or they don't know any better.. And wonder why their forwards don't work.
Does your pfsense wan start with public IP, or 192.168.x.x, 10.x.x.x or 172.16-31.x.x – if so its behind a NAT and you will have to forward 8080 on that device to your pfsense wan IP.
Its also possible your isp blocks 8080 - this is a common alternative port for http, as well as common port for proxy, etc.
I would do a sniff on your pfsense wan - generate some traffic to your port from outside.. Do you see it? If not its being blocked upstream from pfsense or your not hitting the correct public IP, etc.
You are correct it should take all of about 30 seconds to create a forward.
Real easy way to generate traffic from outside is canyouseeme.org
-
Hello,
NOTE** - The desired port is 443 - My bad earlier posting 8080 – Sorry
The PFSense does not start with a WAN and therefore I know it is just a public IP on the outside.
I have reloaded the PFSense firewall, created the NAT and it generated the Rule.
I just do not understand why this is so difficult...The customer MUST have this operational by tonight!
Current config:
Router Internal address structure: 192.168.1.1 / 20 (255.255.240.0)
Machine IP that has the service running - 192.168.4.20
NAT Config - WAN, TCP, * , * , WAN Address, 443, 192.168.4.20, 443 (HTTPS)
I can ping, and connect to the 192.168.4.20 system from a workstation that is 192.168.1.x
My subnetting is fine based on that.
Any ideas????Thank you
-
And again – have you verified the traffic actually hits your wan? It takes 2 freaking seconds to do.. Until you know the packets are getting to pfsense.. There is nothing to do.
A /20 for lan -- really? Why? That is just going to be a broadcast nightmare..
And what does english have to with 8080 or 443 -- you clearly stated you needed both! So again validate the traffic gets there no matter what port you need.
And lets not forget host firewalls? It quite common for host firewall to allow traffic from internal network ie your 192.168.1.0/20 but not from external network. And then traffic even if forwarded from pfsense to your lan box would be shown as closed because your host firewall did not allow it.
Follow the packets - validate hits your wan, then validate that it leaves your lan, then validate it hits your lan box.. This troubleshooting takes all of 30 seconds. Until you do this your just what?? Spinning your wheels. A port forward in pfsense is literately click click.. And if it takes more than 30 seconds to do there is something wrong - when there is something wrong, what do you do?? You troubleshoot it ;)
https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
-
I know the traffic hits my WAN due to the fact that the router that we removed was passing traffic to the desired host before it crapped out.
No ports are being forwarded
Host firewall is not turned on as verified by the first statement.
You are correct that it should be click, click, click to set this up.
To get the customer up and running I went out and purchased a Netgear FVS318, put it on the network, click, click, click and the ports are now forwarding correctly…. 5 minutes from open the box to working.
This is not what I want as the FVS318 caps the speed at 18Mbps for download from the ISP... this is just temporary until I can get the PFSense to work correctly. With the PFSense the customers ISP connection is fully utilized at 75Mbps.
So, now that we have verified that the traffic is hitting the WAN and able to get to the host at 192.168.4.20 and the ports are active.... any other ideas of why PFSense will not work correctly?
-
"I know the traffic hits my WAN due to the fact that the router that we removed was passing traffic to the desired host before it crapped out."
That is not validation by any means of the imagination..
I have linked you to the troubleshooting guide - I would suggest you follow it. So did you enable logging on your rule? Do you see that traffic being allowed or denied?
–
3. If you're still having problems, edit the firewall rule that passes traffic for the NAT entry, and enable logging. Save and Apply Changes. Then try to access it again from the outside. Check your firewall logs to see if the traffic shows as being permitted or denied.How did you set the lan IP to /20 -- when you first setup or after? Are you using automatic or manual outbound nats?
Let see your firewall rules and nat rules - do you have something before your firewall or nat? That could be causing an issue - post your rules!
Are you listening on the ports you want to forward with something else - like the webgui via 443? Or openvpn setup to listen on 443?
How about simple test with just /24 as your network?
So is internet working from this client your trying to forward to via pfsense?
-
WAN rules? Do you have any block rule on WAN? Seriously, this shouldn't be hard to troubleshoot, there aren't many points of failure
