NAT'ing
-
And every one of those blocks is NON SYN packet, Shows that it is out of state..
https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection
You not understanding the rules is clear.. In what scenario would a lan rule with Destination of 172.17.2.x make sense… Yet you have a bunch of them... In NO scenario will pfsense see traffic from 172.17.2.A to 172.17.2.B.... Yet you have rules on your lan with destination IP of 172.17.2 .10, .11, .12, etc.. They are completely utterly pointless!!! Never will such a scenario happen.
-
Ok, I do agree. LAN Ruleset deleted as attached. Also, the SystemLogs/Firewall logs after x.x.x.110 1-1 NAT enabled and LAN ruleset deleted.
After such, no traffic in or out.Now I have to ask, where do we go from here. I do appreciate the help. REALLY! However, belittling and questioning my ability to understand basic networking principles gets no one nowhere. I came to this forum for guidance. I have managed/lead a significant number of SW engineers in my time and have found mentoring and simplifying a task to the lowest common denominator will yield the greatest effort for the task at hand in addition to the most respect from others.
Lastly, there are no simple "how-to" wrt 1-1 NAT of public-to-private IPs without throwing in VLAN, etc. If someone could provide simple step-by-step instructions to what needs to be done, I would be happy to give it a shot and will add, extremely capable of following such instructions. My guess has been that this is a common paradigm and mostly goes so smooth, no additional instructions are need. Maybe I am wrong. Just begging for help. Yes, maybe I have some nonsense rules on the LAN as a result of applying the "Easy Rule" tactic but it is NOT a reflection of my knowledge or what I am capable of comprehending. I can waste peoples time by debating wired and wireless network theory and topology if need be but that gets me nowhere and provides current/future users of this forum nothing they can apply to a problem they are trying to solve.
This is what I started with…
-
Under "Firewall/Virtual IPs", setup a VIP for each public IP I have been assigned, eg. x.x.x.105, x.x.x.106, etc
-
Under "Firewall/NAT/1:1", setup each public IP to map to the desired private IP, eg. x.x.x.110 to 172.17.2.100, etc
-
Under "Firewall/Rules/WAN" assign a rule that specifies the "Destination" to correlate with my private IPs, eg. Protocol=IPV4*, Source=, Port=, Destination=172.17.2.100, Port=, Gateway=, Queue=none
Then, I should be ready to roll but no such luck. Please tell me the step I am missing or implementing incorrectly.
Thanks
Sig
-
-
So I see ACK and syn,ack being blocked by default. So your states are not being created it would seem.. Or the syn is getting to your server from a different path. If pfsense did not put in its state table the syn that it sent on from the 1:1 nat, then yes the answers would be blocked because they are out of state… Which is what your showing.
So lets dive into how your actually connected with this public IP space that your putting vips on in pfsense that you wan to 1:1 nat to IPs behind.
Are you seeing the states being created in pfsense state table when it does the 1:1 nat?
-
State tables attached. The answer seems to be yes. The 1:1 NAT is shown and it does appear that everything should be working fine. That has been what is so perplexing. I have bounced the pfSense box, ethe two radios in bridge mode between the pfSense box and the Charter modem along with the Charter modem itself more times than I can count. I even have an IBoot device connected to the Charter modem just in case the modem gets flakey (I know that information is of no consequence for the problem).
As far as the way public IPs are handed over, is as follows:
Charter's modems LAN is set to x.x.x.97 and my IP space runs to x.x.x.126. Hence I have 29 usable IPs. I have included a traceroute snapshot as well. The "* * * *" are my two radios between the pfSense box and Charters modem. Since Charter refuses to allow me even read access to the modem, I can only speculate that the WAN address is 96.34.119.117. This assumption is based solely on various traceroutes I have done since establishing the service. I usually just hit Google's public DNS of 8.8.8.8 as you can see in the screen shot…
Again, thanks for the efforts. I would even be willing to allow you remote access to the pfSense box if you like so you can verify I have things setup properly.
Sig
-
I do not see any inbound states in those state tables..
Those are all outbound where your clients created connects to outbound sites..
You have a vip… public.X -- I hit it from the outside source 1.2.3.4:highport to port 80 http.. I hit public.X:80 this gets sent to 172.17.2.X:80.... where is that state?
When you stated "Web browsing internally fails," You mean your on 172.17.2.A and your trying to hit publicIP:http and get redirected back into 172.17.2.B??
-
Sorry, the attached shows some inbound states and it appears they are being routed correctly
I will have to wait until tonight since DoD blocks RDP, SSH, etc. I will do such and post it tonight.
One tidbit of information. One of the IT guys I work with here, that is familiar with pfSense, suggested I enable the service "UPnP & NAT-PMP". He started rattling off about pfSenses network propagation (EIGRP) and lack there of, STP, OSPF, etc. Some of which I was familiar with and some not :-\ Bottom line, he said pfSense is by no means a "turn key" firewall solution and does take some detailed networking expertise and troubleshooting to find issues if they don't "click" upon initial configuration. His words, not mine. Personally, I have always had great luck with it until now. Always considered the Cisco/Dell/etc worshipers to be somewhat, narrow minded. Really pisses my son off since he is a die hard Cisco/Juniper/KG fan…
More info coming tonight
Sig
-
Who is this idiot? UPnP - yeah don't let him near your shit!! Would be my suggestion… Clearly he is retarded and doesn't work in security or networking if he would ever suggest turning on UPnP.. Zero reason for that.. Did he suggest you enable that on an isolated vlan with restrictions so your game console could open up the nonsense ports that the makers are too lazy to correctly document? ;)
Sounds like to me he was just rattling off some buzz words to try impress you with his so called "knowledge"..
Oh you mean that pfsense doesn't support a Cisco proprietary routing protocol.. eigrp… So while it was kind of released in 2013 and there is a package for openbsd I do believe that would allow to add it this protocol. I do not think this is available for freebsd.. If there is a freebsd package then it would be possible I would think to get this added to pfsense. But to be honest there are other routing protocols you would most likely use like just bgp..
STP.. you mean the layer 2 spanning tree protocol that has ZERO to do with a Layer 3 firewall? Which btw is really deprecated and all really rstp or 802.1d, and or 802.1q-2014 which now has most of 802.1d and 802.1aq in it, etc..
OSPF.. ok you want to use that then clickity clickity install the Quagga package, or OpenBGPD or frr all 3 which support ospf..
I didn't see any inbound states I could look again... But sure looked like all outbound to 443 from your 172.17.2 devices. Please highlight what you think is an inbound state..
I have been working with firewalls since before there were even states... They were just packet filters.. I have used over the years Juniper, Cisco, Checkpoint, Palo, etc.. pretty much every firewall you can think of.. And when it comes to turnkey get working right out of the box.. Pfsense is pretty as close as you could get... If you do need to get fancy with it with stuff like routing protocols and such then sure it can do that too.. In what scenario would you want to use STP on it? While sure you can bridge some interfaces on it if you need to for some oddball configuration... You shouldn't be doing freaking layer 2 on your Layer 3 firewall/router ;)
-
I love it!!! ;D
Sorry, I just had to forward your reply to him. It was just too good… He almost fell out of his chair ;D Yeah, there is a lot of throwing around of "buzz"/"acronyms" in the DoD world. When you work for the "man", seems the more acronyms you can spell, the more important you are... pitiful... I need to stop, have to watch what I say :-X
The WAN-LAN right in the middle is what I was interpreting as "inbound" However, everything I interpret as inbound is in a TIME_WAIT state and never any further.
More tonight.
Sig -
TIME_WAIT was opened then closed. You'll need to run a packet capture, try a connection, download it into wireshark, and see what's really going on.
-
Don't know if my Linux server will still boot. Might be able to dig up an old Java app I wrote a few years ago that executed tshark, did packet captures and translate the hex to ASCII. Thinking it would run on a Windows box but don't remember…
Sig
-
Wireshark does the heavy lifting.
Maybe the packet capture display right in pfSense will shed some light.
-
Ok guys, came in this afternoon and 1:1 NAT is working perfect. The only change I made today was removing every rule on the LAN with the exception of the defaults. I experimented a little and sure enough, any rule I put on the LAN which contains the specific LAN address I am running 1:1 NAT, sends pfSense into a flaming tail spin WRT traffic on that IP. Even switched over to my 32bit (2.3.5 box) and the same thing happens.
So, the chastising by johnpoz about the useless LAN rules actually prompted me to remove all but those defaults today. You guys DID IT!!! In a round-about-way that is. I hope anyone who runs across this posting in the future gets something out of it.
NO IP SPECIFIC LAN RULES WHEN DOING SIMPLE 1:1 NAT ON THAT IP
It really was that simple!!! Thanks so much guys. GREAT firewall product with a GREAT community supporting it…
Best regards 8)
Sig -
Rules on LAN have nothing to do with 1:1 NAT. LAN passes traffic outbound. 1:1 NAT might translate the same on its way out WAN.
The only thing you might have been doing is bad policy routing.
Glad it's working.
-
I wholeheartedly agree that LAN rules should NOT affect 1:1 NAT. However, on pfSense 2.4.1 & 2.3.5 it does. Try experimenting with it some. You should see the exact behavior. I can replicate the behavior every time. May just be what we refer to as an "undocumented feature" ;)
I still can't thank you folks enough for the help. I had been struggling with this for several weeks and was at my wits-end!
BLESS YOU BOTH!!!
Sig -
No, it doesn't. (Try experimenting with it some… Umm.)
The traffic is either passed on LAN or it is not.
IF you are trying to do NAT reflection then you do need to be sure traffic is passed on LAN to the NAT destination address on LAN which makes no sense except when NAT reflection is involved.
-
Yeah lan rules have nothing to do with whatever your problem was..
-
Peace bro's. Just stating my observations. As a peace offering my config is attached with the public "IPs" changed to protect the innocent. You can see for yourself how extremely simple my configuration is. Almost everything is as it was at installation complete and reboot…
(Try experimenting with it some… Umm.)
Yes, it is called "regression testing". Someone, somewhere has a lab (or even a virtual environment) with the ability to load such up and test it. I would hope!
IF you are trying to do NAT reflection then you do need to be sure traffic is passed on LAN to the NAT destination address on LAN which makes no sense except when NAT reflection is involved.
NAT reflection is set to "System Default" which equates to YES as can be seen in the config.
Look, I get it. You get folks all the time that make outlandish claims which may or may not be relevant to a perceived problem they are experiencing. I am no Network Engineer and don't claim to be. Not even a novice at it. But once in that blue moon, someone will come along with something that should not happen or be related to the reported problem. Is it not worth investigation before execution of the defendant? Sometimes? Maybe?
I am not saying the issue and ultimate resolution are related nor that the two are mutually inclusive, just, as Joe Friday would say, I am providing "just the facts ma'am"!Sig
-
The way to accomplish that is to develop a specific set of steps from a default configuration that produces the result you think is unexpected.
I work will pfSense all day every day for a living and have a lab of at least 8 pfSense devices at-the-ready to prove or disprove things like this (see my sig - that lab always exists and then some). But I will not waste time on wild goose chases, so define the steps necessary to duplicate your phenomenon.
What you are stating is incorrect. 1:1 NAT is completely irrelevant to LAN rules unless, maybe, NAT reflection is involved.
Since you don't even know what that is, I can only presume that is not the case.
I might find time to look at that config this weekend.
-
What you are stating is incorrect. 1:1 NAT is completely irrelevant to LAN rules unless, maybe, NAT reflection is involved.
How is my statement incorrect? I thought I was stating exactly that except that I did not realize, NAT reflection could be a contributing factor. I think we are in violent agreement. But I am getting old and my perception can be skewed… sometimes!
As far as development of a set of use case steps from the default configuration, no thanks. I am a software engineer, not a systems engineer! Although the line of demarcation does get blurry occasionally. I have a 3 hour commute to work everyday, work 10 hours and try to sleep for at least 7, binge watching "Supernatural" in the couple of hours I have at home each weeknight. The weekends are spent building custom firearms for folks breathing down my neck since I have a 6 month backlog that has turned into 9.
AGAIN, thanks for the direction, advice and time taken to even address my issue!!!
Sig -
Lets keep in mind that more than likely there was NOTHING wrong… Those blocks where out of state traffic, look all of it to be outbound to me..
For all we know his wan went down and reset states and so yeah going to see SA and A blocks on the lan..
One statement sound to me like he was trying to get nat reflection to work. Which yeah is not going to unless setup, and to be honest is not needed in 999/1000 cases.. if not alll 1000.. Its a hack to be sure and should be avoided anyway.
