NAT or NO NAT?

[TheGoob]

Morning

So I am at my wits end. I have an FPR1010 w/ 8 STATIC IP’s (6 usable).

My WAN FPR IP is x.x.x.182.

I have available, .177 to .181. I am using x.x.x.177 as an IP dedicated to a server on LAN 192.268.5.42.

Without NAT, NOTHING gets through and no data transmitted, to be expected. 
WITH NAT, and with my ACL’s, I can connect to those ACL’s as well as, well, um everything? 
So I played a little game. I kept my NAT on (and this occurs as auto NAT and manual NAT) but removed EVERY ACL pertaining to my x.x.x.177 and 192.168.5.42 and with NO ACL’s I still got in?!?! Is this because NAT, auto or manual, bypasses ACL’s? Is this a glitch or am I missing something. How am I connecting to everything with NO ACL?  So to bypass my little issue I have STATIC NAT WAN .177 to LAN 192.168.5.42 ( ANY and ANY on ports) and the. At the software level on my server I am using iptables. This seems, not so secure.

[Rob Ingram]

@TheGoob can you please provide a screenshot of your NAT and ACL (ACP) configuration please.

What OS are you running on your FPR1010, FTD or ASA?

[Milos_Jovanovic]

Hi @TheGoob,

There are 2 things to consider when deploying public services (of course, there are much more, but I'm simplifying) - one is NAT, and secodn one is ACL. NAT is simply stating if device is reachable over Internet or not, while ACL is the one defining which services will be accessible, and everything else should be blocked.

This is almost true, unless you haven't configured any ACLs on your FW. In that case, security level  gets in effect - it is always allowed to access security zone with lower level, if reaching it from a zone with higher security level. If you have defined your server zone with e.g. 20, while WAN zone with 30, it will always be possible to reach everything in server zone from WAN zone.

You should check your zone levels with "show nameif", and your ACL assignments with "show run access-group", to confirm that proper configuration is in place.

Kind regards,

Milos

[TheGoob]

First, I am running the FTD and will show screenshot in a minute but to the 2nd poster... PLEASE don't tell me I am an idiot and this is telling me what I think it is telling me; that all my levels are 0.

> show nameif
Interface     Name     Security
Ethernet1/1     outside       0
Ethernet1/2     inside_2     0
Ethernet1/3     inside_3     0
Ethernet1/4     inside_4     0
Ethernet1/5     inside_5     0
Ethernet1/6     inside_6     0
Ethernet1/7     inside_7     0
Ethernet1/8     inside_8     0
Management1/1     diagnostic    0
BVI1 inside 0

and ;

> show running-config access-group
access-group NGFW_ONBOX_ACL global

[Milos_Jovanovic]

You are running FTD, and principles over there are bit different I assumed it was ASA, thus my explanation from before.

All zones have same security level, and only one ACL (global one) is applied to all zones.

@Rob Ingram alredy replied what is going on.

Kind regards,

Milos

[TheGoob]

Hopefully these are viewable...On THIS, as seen in the ACL only SSH is open, and yet I can connect to http://x.x.x.181:80 and it loads. IP's are different than original post as I have THAT one disabled, but this does the same thing; lets every port in.

My NAT is literally inside 192.168.5.43 to outside x.x.x.181

My ACL is only allowing in SSH Port 177 from outside (x.x.x.181) to inside (192.168.5.43)

[Rob Ingram]

@TheGoob remove the source ports on your Access Control rules, the source port would be dynamic - so the leave the source ports as "any"

FYI, you've a default allow rule....so that would explain why you can connect with no explicit allow rules. Change the deafult rule to deny and create more explict rules to permit the traffic.

[TheGoob]

I mean, how funny. I see it everyday and notice it but until you mention it, it seems obvious and ridiculous that I left it "allow" as a default rule. 

In regards to ACL's; Would all and any ACL source port be left blank? What conditions would it be inputted? For Port forwarding?

I will get back momentarily with results. Thank you

[TheGoob]

Well at this stage I will definitely say it is something I am doing wrong. I did indeed change default rule to BLOCK and then removed Source Port and it definitely stopped anything from getting into the server but now I can not SSH in.  Does NAT placement as well as auto/manual possibly have a hand in this? If I am doing direct nat from a WAN IP to a LAN IP would that be manual, above inside_2, as I have it?

[TheGoob]

I don't know why but I feel that, in my situation, BLOCK default rule is overruling everything!

[Milos_Jovanovic · Accepted solution]

You need to built your ACL top-down - to allow what you need on top, and to deny everything else. By looking at your ACL, I see that you've restricted traffic from zones (e.g. inside to inside) so please bare in mind that there is a logical AND condition between statements (if src_zone=inside AND dst_zone=inside AND ...). Most likely, your other traffic is not being permitted by anything before, thus falling to default Block_ALL rule.

Kind regards,

Milos

[TheGoob]

The “TRUST” ACL’s inside to inside and inside to outside are what is blocking my traffic?

as you mention; (non verbatim)

inside to inside trust

inside to outside trust

incoming mail allow

incoming ssh allow

incoming ssh allow 

block all

This is causing everything to be blocked because of placement?

[TheGoob]

Alright, got it to work as we intended. Earlier this morning after changing what we talked about I ignorantly did LAN to LAN, not WAN to LAN ACL. Anyway, it seems to be working. IO am now going to implement the other servers and what not and verify works before "solved". But this is awesome, thank you.

Regardless of that, and I did this after I verified your way worked, I reinstated the SOURCE Port, and it stopped working. How would a set source to a set destination port not work? I understand Port Forwarding source 88 to destination 22, would a source port be used in that scenario? Just weird source and destination causing it to not work. Regardless, I have source port to any and it works.

[Rob Ingram]

@TheGoob because the source port is dynamic you would write an inbound rule with just the required destination port (and host IP), the source port would be left as "any".

You can verify this from the CLI using system "support firewall-engine-debug" set a filter on the destination IP or source IP, generate traffic and watch the connections, you can confirm the source ports.

[TheGoob]

Fair enough. Awesome guys, thank you!