Configuring a block of IPs from an ISP, 5508 with FMC.

[itsupport]

 I am attempting to configure an ASA-5508-X firewall. It is running Firepower Thread Defence 6.2.0.2, managed by a Firepower Management Console, running FMC 6.2.0.2. Both devices are runing the latest patches.

My ISP provides a 50/50Mb fibre service, delivered via CAT5. It is connected to GE1/1. IP is 110.999.999.178/30 (Obfuscated). I have a static default route set to 110.999.999.177. This all works as expected.

My ISP also provides a block of 16 IPs, 203.999.999.0  to 203.999.999.15. (Obviously I cannot use the network and broadcast IPS). I wish to use a couple of these to publish a couple of internal websites, terminate site-site VPNs, SMTP email, and once Cisco finish writing thier firmware, Anyconnect clients. At the moment, I am having some sporadic connectivity issues, so i would also like to be able to ping some of these IPs.

So far, I have not configured this subnet anywhere, and I have had limited success in using the 14 IPS. I have one set up to allow temporary access into a machine on te LAN via RDP, and have published two web sites. What I cannot figure out is how to allow pings to work, or how to specify one of these IPs as a site-site VPN connection. The VPN setup only allows me to choose an IP on an existing security zone, which seems to require an interface.

Should I set up one of the physical interfaces with an IP in this block? Maybe GE1/4 203.999.999.14/28? Can I use a subinterface, off GE1/1? Somehow set another virtual subnet up somehow?

[#2]

Hello.

So your ISP provides two separate public IP ranges:

1. a /30 for a point-to-point link to the ISP's upstream router where:

10.999.99.178 is currently assigned to your ASA 5500-X firewall and .177 is the "next hop" ISP router on the far side of the point-to-point link.

2. a /28 which represents your usable pool of public IP addresses: 203.999.999.0/28 where the usable range is 203.999.999.1 - 203.999.999.14 (.15 is the "broadcast address").

The upstream router has routing logic in place that states "To reach 203.999.999.0/28 send traffic to a next hop of 10.999.99.178"

The traditional configuration for the aforementioned public IP allocation would be to do something like this:

ISP RTR ----- Customer Internet Edge RTR----Customer ASA ---  Customer LAN

I have attached a .jpg diagram illustrating the traditional configuration. 

This is the way I have always done it, and the traditional setup provides some additional flexibility.

For example, you could introduce a "public" or "dirty" switch between your internet edge router and the ASA firewall.  All devices on the public facing switch would be assigned IPs from the 203.999.999.0/28 subnet.  This would be useful if you had more than one firewall and each firewall needed to be assigned a public IP address (faliover cluster).   The firewall(s) could still NAT or "answer" for other IPs in the 203.999.999.0/28 range.

That said, some IT people ask "Why do I need an extra device in the path? Why can't I economize and have the /30 subnet terminate directly on the outside (untrusted) NIC of my firewall?"

There are several alternate topologies that would work.

You could also have a third NIC and assign the 203.999.999.0/28 network to the third NIC.

But the setup you have where the ASA is "answering" for the 203.999.999.0/28 network for one-to-one NAT rules also should work

You stated that you have a static or "one to one" NAT rule and associated firewall rule that map the public IP 203.999.999.X to a private IP of say 192.168.999.X" that allows you to connect via Microsoft RDP to a specific host on your private LAN and that this logic is tested and working.

I think that the issue where you cannot ping devices that have one-to-one NATs with "mapped IPs" in the 203.999.999.X range is probably related to allowing ICMP echos and replies through the firewall.  This can be accomplished by enable ICMP inspection in the global service policy:

policy-map global_policy
   class inspection_default
   inspect icmp

Also see: https://www.speaknetworks.com/enable-icmp-inspection-to-allow-ping-traffic-passing-asa/

Do let me know if the above recommendation corrects the problem you are having.

[#3]

As stated above, I think the PING issue has to do with allowing ICMP traffic inbound throught he ASA.  However,   I do not think you can have the 203.999.999.X network act as a IPSEC site-to-site VPN endpoint where the ASA itself is a tunnel endpoint, unless the ASA is assigned an IP from the 203.999.999.x range.    

That said, if you have a completely separate VPN tunnel termination device sitting "behind" the ASA, there should be a convoluted way to setup a one-to-one STATIC NAT mapping for that vpn tunnel endpoint device, and allow the appropriate protocols through the firewall for the device in question with firewall rules. 

[itsupport]

This device is running Firepower Threat Defence, configured by a Firepower Management Console. My understanding is that CLI configuration is not supported.

[Marvin Rhoads]

You can do the inspect bit in FTD by using a Flexconfig.

This was enabled by default in FTD 6.0 but got disabled in 6.1 and 6.2. There is discussion and a BugID on it:

https://supportforums.cisco.com/discussion/13240471/traceroute-through-ftd-sensor

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb40875

It was supposed to be fixed in 6.2.0.2 but I have not had a chance to confirm that.

Also, the earlier posting about requiring the IP address to be assigned to an interface is true regarding site-site VPN. You can only use the non-connected pool like you have for NAT purposes - not for connections to the ASA itself such as are used by VPN.

[itsupport]

OK, thanks for the guidance so far. Can someone expand or post a link on how to "use Flex config to add inspects"?.  

I tried adding the System Defined, Default_Inspection_Protocol_Enable, to a new Flexconfig policy, however it seemed to do nothing. 

[Marvin Rhoads]

Did you first add icmp to the object?

Objects > Object Management > FlexConfig > Text Object > enableInspectProtocolList.

From there, choose your target device and add an override to the default list for icmp.

Save and deploy and re-test.

Paul Stewart has a closely related example over on his blog here:

http://www.packetu.com/2017/07/17/flexconfig-firepower-threat-defense/

It includes command line verifcation steps.

[itsupport]

FYI.

I logged a call with TAC, and managed to get an acceptable workaround. The 5508 itself is not responding to ICMP, however this traffic is being NATTED to the host machine behind it, the same one I am connecting to via RDP.

I had tried to forward ICMP in a NAT rule, however the FMC refused, responding with a message "This has to be TCP or UDP only", or similar. From this, I had concluded that a static NAT of ICMP was not possible. Turns out it IS, the trick was to create a NAT rule without specifying a port. It seems this NATs everything, even ICMP, which cannot be NATTED individually. An appropriate access policy can then be used to only allow RDP and ICMP.

Simple enough when you know!