opening ports on firewall
-
@Derelict I have checked this list a couple times now. Didn't see anything standing out.
-
Alright, your NAT rules look correct, might want to make the protocol both TCP/UDP, and not just TCP.
Your WAN rules are incorrect. Your FIRST set of 443 and 80 allow traffic to just your firewall, not another LAN machine. If you move these two new bottom rules to the very TOP of your firewall rule list, the traffic should move like you are expecting/hoping.
Firewall rules are evaluated top down, first to match wins. That's why nothing is hitting 10.0.0.5, 80 and 443 are bouncing around inside the firewall itself, due to the first 2 top rules.
Jeff
-
I don't know what didn't see anything standing out means. Did you see the SYN arrive or not?
If you packet capture on WAN for port 32900 and test from the outside, you should see the SYN packet arrive.
If you see it, then move your capture to the inside interface for port 32400, you should see the SYN packet sent to 10.0.0.37.
If there is no response, look at the server (10.0.0.37) and see why.
-
@akuma1x said in opening ports on firewall:
Alright, your NAT rules look correct, might want to make the protocol both TCP/UDP, and not just TCP.
Pet peeve of mine. You shouldn't just randomly forward traffic. You should know if you need TCP, UDP, or both and forward what is required.
If he pcaps filtering on just the port, it will show both.
-
@Derelict I didn't do the packet capture on the WAN, the troubleshooting list.
How do I setup packet capturing on the WAN? is this something I can setup on my pfsense machine or what is the best method?
-
diagnostic menu, packet capture.. put in the port your wanting to check, wan and click start... Then send the test traffic to that port.
-
Diagnostics > Packet Capture:
Interface: WAN
Port: 32900Start, Test, Stop, Evaluate.
-
@akuma1x said in opening ports on firewall:
Alright, your NAT rules look correct, might want to make the protocol both TCP/UDP, and not just TCP.
Your WAN rules are incorrect. Your FIRST set of 443 and 80 allow traffic to just your firewall, not another LAN machine. If you move these two new bottom rules to the very TOP of your firewall rule list, the traffic should move like you are expecting/hoping.
Firewall rules are evaluated top down, first to match wins. That's why nothing is hitting 10.0.0.5, 80 and 443 are bouncing around inside the firewall itself, due to the first 2 top rules.
Jeff
Using the HA Proxy and not NAT the machine directly I don't think I need the firewall rule to the web server directly on the WAN. I have the NAT for port 80 and 443 disabled along with those firewall rules. I can put 2 new rules to wan to the webserver and see if that works.
-
Using HAproxy is a completely different thing. In that case you would need rules passing traffic to the frontend(s).
-
And we still don't have a 30 second sniff of wan..
-
The first two WAN rules should probably be "WAN Address" instead of "This Firewall".
Just a guess.
-
I have the wan packets capture what do you wan me to post here?
-
Just enough to show the traffic is hitting WAN.
If it is, then a pcap for the proper traffic on LAN.
-
Does this satisfy the wan is seeing port 80. My WAN IP is x.x.176.180
-
No. That's an outbound connection from your WAN address.
-
Its not that hard dude..
Can you see me .org
It shows closed because I don't have anything listening or forwarded.. But you can see the traffic gets there.
-
I am not seeing packets on port 80.
Looks like my isp is blocking or something else is blocking unless I am missing something else.
I have my cable modem plugged directly into my vmware server that is hosting the pfsense vm.
-
Just off the phone with suddenlink. Residential accounts are not able to open port 80. The same level of service for a business account for the same 1Gbps account is approximately 3x the cost. That is not reasonable.
-
What is the model of your cable modem? It is in bridge mode.. Correct?
-
Quick google search says suddenlink pretty much sucks for this. Sorry.
That's why we pcap. Nothing like making sure the traffic is actually on the wire before proceeding with additional troubleshooting.
