NAT'ing



  • I am running pfSense 2.4.1 and am trying to setup simple 1:1 NAT. I have failed horribly! Watched every video I could find on youtube along with most everything posted here and nothing works. Even my son that is a Raytheon network engineer is stumped (although he is not familiar with pfSense).

    My ISP (Charter Spectrum) has given me a block of 32 IPs, 29 usable.
    The modems "LAN" uses x.x.x.97.
    Radio links use x.x.x.99 & x.x.x.100.
    pfSense box is x.x.x.104 with a netmask of 27 (255.255.255.224).

    I have setup a VIP for x.x.x.110, x.x.x.110 NAT'd to 192.168.1.100 along with the appropriate WAN firewall rule. It should be that simple. It was with < version 2 of pfSense except I used Proxy ARP instead of an IP Alias.

    Once I setup the 1:1 NAT, I can access everything on the inside from external but nothing gets out from internal except I can ping anything from the inside. Web browsing internally fails, steaming fails (Netflix), etc. DNS seems to be ok internally, since when I do  pings from internal, names are resolved to IPs and the RT of the pings are successful. When internal-to-external fails, I can go to System Logs/Firewall and I get the infamous "Default deny rule IPv4 (1000000103)" and/or "Default deny rule IPv4 (1000000104)". I have tried the "Easy Rule" add but it still fails. Acts like the LAN rules are being ignored which is totally bizzare! I even bounce the pfSense state tables after every change.

    I claim to have tried everything and have found a need to double my xanax intake  ;)

    Is there a way someone could point me to a posting/instruction/video I might have missed or give me some sort of hint what might be the issue? I know how difficult it is trying to visualize such without being there. I am a SW engineer having done communication coding myself (35 years now, yep, an old fart but can learn new tricks!) and thought I had a pretty good knowledge of the intricacies of networking. Hell, I can still translate a wireshark hex dump into binary in my head so I am not too far gone… yet...

    Any help would be greatly appreciated!!!
    Sig



  • Anyone? I know it has just been a day but surely someone has run into an instance where it appeared LAN rules appear to be ignored. Is this simply a "free feature" of pfSense? I have a rule on the LAN to allow everything but that seems to be ignored as well. I have worked on this for weeks. I am pretty sure I am no fool and am almost convinced this is a problem/feature with pfSense. No conspiracy theorist either but maybe Netgate wants anything other than the most basic features blocked or disabled.

    One discrepancy, my internal network is 172.17.2.1/24, not 192.168.1.1 as in the original post.

    Fixing to post screen shots of my setup so please, someone throw me a bone here…
    Sig



  • Now the pics…













  • Rebel Alliance Global Moderator

    "appeared LAN rules appear to be ignored."

    Why would devices on the lan be talking to pfsense to talk to other devices on the same lan?  I don't see any point to your lan rules with dest of IPs on the lan.. What do you think those are going to accomplish?



  • After enabling x.x.x.110, could not even post anything due to the LAN blocking everything.

    Lastly I have tried just about every permutation of WAN/LAN rules, using CARP, Proxy ARP, etc.

    If this is a Netgate thing where a license is required, someone just tell me. Not a big deal. Really!!!! Just need to know…

    Sig



  • @johnpoz:

    "appeared LAN rules appear to be ignored."

    Why would devices on the lan be talking to pfsense to talk to other devices on the same lan?  I don't see any point to your lan rules with dest of IPs on the lan.. What do you think those are going to accomplish?

    I am simply grasping at straws with the LAN rules since it seems the "blockage" is on the LAN side. Mostly they are a result of doing the add "Easy Rule" and with a slight mod to allow more than just the specific IP/Port.

    I also have the following rule at the bottom. This should allow everything but still get the "deny". Any ideas???

    Sig



  • Rebel Alliance Global Moderator

    Yea that rule on the bottom is the default lan rule.  other than defaults to lan net as source… Since unless you have downstream routers your never going to see anything on lan from other than lan net.

    You don't seem to understand how rules are evaluated?

    As traffic enters an interface top down, first rule to trigger wins, no other rules evaluated.

    So again lets ask how would you have traffic from lan to lan that pfsense would see??

    If you are seeing blocks on pfsense lan from lan, that would scream asymmetrical.. Ie pfsense didn't send the packet to the device on lan, but lan is trying to answer through pfsense.  Please post these firewall blocks your seeing.



  • I posted the System Logs/Firewall blocks above but here they are again. LAN-to-LAN traffic is unimpeded. I can bring up any radio interface which is 172.17.2.10-14 with no trouble even with 1-1 NAT enabled.

    You sound like my son, he tells me I don't understand networking  ::), although I am somewhat baffled by the statement

    If you are seeing blocks on pfsense lan from lan, that would scream asymmetrical.. Ie pfsense didn't send the packet to the device on lan, but lan is trying to answer through pfsense.  Please post these firewall blocks your seeing.

    By observing the blocks, it appears pfSense is trying to send directly from the LAN to the public IP space. This is exactly the case if I select to log the rules which let all traffic flow in both directions.

    I REALLY appreciate the time to look at my problem. Keeping my fingers crossed we can find a solution!!!
    Sig



  • Rebel Alliance Global Moderator

    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_"blocked"_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





  • Rebel Alliance Global Moderator

    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







  • Rebel Alliance Global Moderator

    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



  • Rebel Alliance Global Moderator

    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


  • Netgate

    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


  • Netgate

    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


  • Netgate

    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


  • Netgate

    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.


  • Rebel Alliance Global Moderator

    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

    config-firewall.semiautoarms.com-20180306134944.txt


  • Netgate

    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


  • Rebel Alliance Global Moderator

    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.



  • I started to just leave your statements alone. However, you are doing the present/future readers of this post an injustice by stating such. So, yes, if enticing me was your goal, congratulations! However, no "social justice" participation trophy will be awarded as a result…

    Lets keep in mind that more than likely there was NOTHING wrong…

    There WAS something wrong. I had been working on this for weeks and know enough about networking that I am 100% sure an issue existed (and might AGAIN add, can be reproduced). My son, which is an NE himself, even acknowledged there was a problem. No, he is not a pfSense SME but for one NE to claim premadonna status over another just discredits yourself. That is sad!

    For all we know his wan went down and reset states

    uuhhh, NO. This statement is a total farce! My WAN would have to be in a constant state of instability. You're kidding, right?

    One statement sound to me like he was trying to get nat reflection to work.

    WHAT THE HELL! NAT reflection for those that are too lazy to google it is nothing more than a mapping for LAN entities to be able to resolve a WAN IP that actually exist within the LAN without hitting the WAN itself. Sorry but I don't host google's DNS servers, amazon.com or even ebay.com. I could not even recall the HUNDREDS of public names/IPs I was tried resolving over the last few weeks. I did NOTHING with NAT reflection. The friggin 1:1 NAT would not work so why would I have been messing with NAT reflection, Jesus…

    You know, I HAD a pretty high opinion of you guys. However, that opinion is a mere dwarf of the star it once was. I really don't get it. Can't fathom what the motivation might be for wanting to discredit people that hit this forum immediately. I let it roll off the first time but to do it again, nah.
    Since I am no psychologist, this is only a guess but one of two thing are in play here. Either, you are actually sitting in your momma's basement and get your jollies off on flaming folks on this and other forums OR you are actual NE's that have been passed over and over and over again for promotion and simply have a thorn up your ass the size of Rhode Island because of it (and socially inept as well)

    You guys keep on keepin on. The contribution you could actually be making, to make someones life a little less miserable, really makes me sad. It really does...


  • Netgate

    Specific steps to duplicate would go a long way to receiving more cooperation.

    The number of times someone comes here saying they found a bug is probably 1000 misconfigurations/misunderstandings to every 1 actual problem found. And those problems are almost never in simple things like NAT.

    Apologies for soliciting actual details. Too bad you're too busy to provide them.


  • Rebel Alliance Global Moderator

    what???

    Dude you have yet to show something wrong… Sorry but that is FACT!!!  A firewall will block out of state traffic... All the blocks you were showing were out of state.. They were not SYN blocks..

    Calling it anything other than PEBKAC is what would be out of line here... Sorry been here 10 years...  If I had a nickel for every time someone said is this a bug... And bought cryptocoin with it I would be on my island with the yacht with its helicopter in the bay sipping a cold drink with my toes in the water and my ass in the sand.

    Vs still here listening to people ask what is wrong, but can not provide any details to show the problem..

    When you want to show us an actual problem that can not be explained by simple PEBKAC.. Then happy to help..  But sorry someone that would put a rule on interface that could never happen... Like you had shows clearly you do not understand how any of this actually works..

    For future readers..  What exactly was not working here?  Other than you seeing some out of state blocks in your log?  Nat reflection??

    Where is the state showing pfsense sent traffic to IP address 123 via 1:1 nat and then blocked the SA back??