PFSense rewriting all traffic?
-
@dgarner those look normal - not sure why any reason to hide rfc1918 space? Are those public IPs you obfuscated? Are you routing public IP space to behind pfsense? If so there would be no need for any port forwards.
If they are rfc1918, as long as that .10 address isn't pfsense address, then those should work unless you had blocking in floating, or in wan that blocked?
When troubleshooting port forwards.. Normally couple of minutes running through the troubleshooting guide will find the source of the problem right away.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/nat-port-forwards.html
spaghetti against the wall trying to make this work. Haha.
Never a good idea ;) just makes a mess.. I taste my spaghetti to know if its the proper al dente hahah
-
@johnpoz No, I'm just hyper paranoid. :)
So, in recap, I have shifted NAT IP from LAN Address to Individual host with port and rules in place to support it, NAT reflection is on Pure NAT and DNS Split is enabled and set up along with DHCP entries to match -- and all machines use PFSense as primary DNS nameserver, including the machine in question.
Woohoo -- sorta. All of these have led to finally resolving on LAN side -- ... still not WAN from my phone, though? Hmm.
At least we're getting closer.
-
@dgarner said in PFSense rewriting all traffic?:
still not WAN from my phone, though? Hmm.
First step for me would be to actually validate traffic hits your wan from outside via sniff, can you see me . org is good place to test tcp traffic from outside.
Then sniff on the lan side interface while doing the test traffic, does pfsense send it on? That would point to maybe a firewall issue on where your forwarding too? Pure nat would nat the source IP, which wouldn't be a local IP. With split dns the IP would be local so maybe the host your sending too allows its own network, but not remote networks, etc.
-
@johnpoz Great point. Thank you for the reminder.
Ports still remain closed to the outside world.
-
@dgarner I would suggest we look at your forward that is not working, and your wan rules for this port.. If tcp send some traffic via say can you see me.. You should be able to track down the problem in couple of minutes..
-
@johnpoz So, this may be curious?
So, there is definitely something listening on all ports previously mentioned, not sure why it says closed and not filtered so much, but will build to it.
I've showed you P/F, but here is rule for 80.
Destination is blank and not able to be edited - this is perhaps the main thing I could think of, but why would I not be able to edit it, if that is required to point to a specific host.. I guess another question would be, why it's not done automatically, so much.. but for our purposes ..
Is this perhaps why and how do I edit it, if it's locked out?
-
@dgarner this is wrong that is for sure
That sure isn't the IP address of this caesar box is it? Your port forward should be to that IP on your lan, some rfc1918 address... Or you proxy your running, it sure isn't going to be pfsense lan IP.
-
@johnpoz omg, gahh..
These are auto-generated rule matches for NAT P/F ... Why are they not matching exactly or editable?
I guess the job for tonight is to delete all these rules and add them manually with correct IP ... :$ -
@dgarner in your port forward set the destination, and then yes the firewall rule would be auto created.. If your port forward is set to lan address, then yeah that is what the the firewall rule would be.. Pfsense tries to keep you from shooting yourself in the foot in a lot of ways.. But in the long run its still just going to do what you tell it to do.
-
@johnpoz I mean, this makes sense and I am thankful it attempted to.
Perhaps this was created during the initial rule set up and does not automatically update.So, if I may ask you one or two more questions I hope.. lol.
If I delete the associated rule and ask it to create a new rule, will that one reflect the IP?Instead of having to manually create all new rules for everything, perhaps I could delete the rules and have them regenerate.
-
@dgarner if your firewall rule is associated with the port forward, then it would update, or be removed if you deleted the port forward. But if the firewall is not associated then no it wouldn't update nor would it be removed on removal of the port forward.
By default pfsense would auto create an associated rule for you when you create the forward. But when you start throwing spaghetti about - who knows that happened.
edit: here I created a forward to my lan address.. Then I corrected it just in the port forward, as you can see the wan firewall rule was updated all on its own
Then when I delete the forward, the wan firewall rule goes away as well.
This should be default when you create a port forward
-
@johnpoz Strange ... I autogenerated new rules, which fixed that issue.
Still nod dice. Hmm.
Port closed, site unreachable.
-
@dgarner that rule to 50000 shows a state.. So pfsense sent on the traffic at least.
Here is what I always tell users having issues with port forwards - sniff!
So you can prove to yourself that pfsense is doing what it is suppose to do.. So you stop looking at pfsense as the problem.. Pfsense has one job here.. To pass on traffic to where your forwarding.. If it does that, its job is done.. And well yes return traffic.. But all of that can be seen with simple sniffing
Go to can you see me.. Send traffic to your port 50000, while you sniff - you see it hit your wan, then sniff on lan side where this 10.0.0.x address is.. Do you see pfsense send it on to that IP.. Does that IP send back an answer to pfsense? Is it a RST? Do you not see an answer?
If you do not see an answer - firewall on the host, or pfsense not the gateway. Or something wrong with proxy on that host.. If you see a RST back - then that host said to go away.. And there is nothing pfsense can do about any of those - other than maybe if you source nat the traffic to circumvent firewall on the host your sending traffic to by making it look like the traffic came from pfsense IP on that network - but that is not a good idea normally.
