Simple Port Forwarding

swmspam · Oct 29, 2018, 1:07 AM

I have read the Troubleshooting Port Forwards and followed the steps. I am watching the firewall logs (status/system logs/firewall), the states (diagnostics/states) and the logs on the client machine. I have not used tcpdump because the situation has not reached that level.

An HTTP web server was installed on a temporary test LAN client operating on port 26001. the web server is visible using LAN clients using LAN IP:26001 address. The firewall on the client was configured to allow NAT "edge traversal" inbound packets.

Starting with the Port Forwards RTFM procedure, the system/advanced/Firewall&NAT configuration was set to Pure NAT with the checkmarks enabled. Then a NAT port forwards was setup using the instructions and an auto-generated firewall rule generated. Screenshots attached.

However, the web server cannot be reached from the outside using WAN IP:26001 address. The firewall log (status/system logs/firewall) clearly shows the incoming request from WAN with a green checkmark (pass) using TCP on port 26001 with the proper destination LAN address.

The diagnostics/state does NOT show any activity on port 26001. The client machines log does NOT show any incoming hits.

Why does the firewall log show the incoming requests but it never passes into a state?

johnpoz · Oct 29, 2018, 1:12 AM

198.19.19.16

Really?
CIDR: 198.18.0.0/15
NetName: SPECIAL-IPV4-BENCHMARK-TESTING-IANA-RESERVED

WHY???

So your problem is NAT reflection and not port forwarding.. Pure NAT and reflection has ZERO to do with testing from outside.. If you have ran through the troubleshooting guide you would show us the sniffs you took of traffic hitting your wan, and not going out your lan interface you forwarded it to..

Where your wan rules - what on your floating?

swmspam · Oct 29, 2018, 5:57 PM

Sincere thanks for your (very) fast response!

Pure NAT and reflection has ZERO to do with testing from outside

The NAT Reflection was set to "disabled" on the rule, and voila! Some entries appeared in the state table. I cleared the state table at 08:45:30 and gave the server another external hit. You can see the latest firewall entry (incoming port 26189) and corresponding state table entry.

However, the client machine firewall and server logs did not register traffic.

The WAN and floating rules are attached. The LAN firewall rules are the basic "Default allow LAN to any rule" and "Anti-Lockout Rule".

p.s. doing a tcpdump to look at what's coming out of the LAN port. There is a lot of VPN testing going on, so I need to wait for the network to be quiet for a moment.

swmspam · Oct 29, 2018, 6:00 PM

Here is the packet capture setup to look for any traffic on port 26001. The WAN captured the incoming request. I cleared the states prior to the test. The incoming request registered a new state entry. However, nothing is recorded on the LAN capture.

Below is the WAN capture sniffing for port 26001

Below is the LAN capture sniffing for port 26001

Below is the state table filtered for 26001

Below is an example Packet Capture setup menu for port 26001

From "Troubleshooting Port Forwards":

If the traffic is seen on the WAN interface, switch to the inside interface and perform a similar capture. If the traffic is not leaving the inside interface, there is a NAT or firewall rule configuration problem.

I suspect this is a BKAC rule configuration problem.

Grimson · Oct 29, 2018, 10:22 PM

Deactivate your floating rules for testing.

Edit: Also 198.18.0.0/15 is in the list for bogon networks so pfSense is blocking it with the "Block bogon networks" rule. Don't be an idiot and use RFC1918 addresses for internal hosts.

swmspam · Oct 30, 2018, 12:19 AM

Thank you!

Moderator, please close this thread and suffix the thread title to "- SOLVED".

The problem was a floating WAN rule from pfblocker FireholLevel1.

Don't be an idiot

I don't believe personal insults are warranted for such matters, especially considering the current climate of online hostility.

johnpoz · Oct 30, 2018, 7:36 AM

Why should the thread be closed? You can mark it solved yourself.. Other users might have questions and or comments.. I for one have a comment to the personal insult remark..

If you took that as personal - sorry but your in idiot ;) @Grimson was making a comment to using such an IP range for your internal networks vs using the called for and standard rfc1918 space is pointless.. Such a statement is not making any sort of personal attack.. Its pointing out that your going to shoot yourself in the foot using such a range.. And even called out the fact that it is listed as bogon ;)

As to the current climate of online activity... Some people need freaking stop being 13 year old girls on their first period would be my comment to that ;) Come on people the whole world is not out to get you.. Here is the HARD part about online communication in text - people are HORRIBLE at interpreting tone in text.. So DON'T - take the words at face value.. words to exchange info to HELP YOU!! Using such an IP range is moronic at best... So his phrasing of of don't be an idiot is quite appropriate.. He didn't call you an idiot - he was calling the use of such a range idiotic...