I've run into this problem before and there's a couple things happening in this scenario.
First, The Management interface does not play by the same rules as other interfaces on the FW. By default it will not pass or receive traffic from any other interface on the device due to the "Management-Only" setting.
Second, the way that Cisco implements the Management interface causes a routing loop with the ASA. You would like to route all traffic to the management network through the L3 switch on the Inside, but the ASA sees the Management network as directly connected via the Management interface
You would like the traffic to take the following path:
IPS > L3 Switch > ASA Inside > Internet > ASA Outside > L3 Switch > IPS
Unfortunately, the path it is actually taking looks like this:
IPS > L3 Switch > ASA Inside > Internet > ASA Outside > Bit Bucket
Any packet sent from the IPS to the internet is returned to the ASA Outside interface, at which point the routing table is checked and it sees that the management network is directly connected via the Management interface. Since the Management interface will not receive traffic from another interface by default, the bits hit the floor.
Unfortunately, the best way to resolve this issue is to abandon using the Management interface to manage the firewall and instead use the Inside interface. If you remove the IP address of the Management interface (but still keep the port enabled for the IPS module), that will remove the Management network from the ASA routing table. This will allow the traffic to take the correct path back to the L3 switch on the Inside when it returns from the Internet.
I hope this helps
You are correct, if all the ASA sees is an HTTPS request, then the TCP payload is encrypted, which prevents the ASA's URL filtering (or any other TCP payload inspection).
Typically, url filtering is done by an http reverse-proxy or load-balancer (like Cisco's ACE/CSM, F5 LTM, or Citrix Netscaler to name a few). The devices I mentioned can also offload SSL encryption from your web server pool as well.
Offloading SSL before you perform payload scrubbing / inspection has some significant advantages. By off-loading your encryption at a load-balancer, the IDS / IPS / Firewall can also see the raw HTTP traffic, which means it can spot application-layer attacks and it generally gives you better protection, if that's a priority.
Best Answer
On an ASA, you can block individual URLs in two different ways. The first way is using FQDN, which basically causes the ASA to resolve the hostname in DNS on a scheduled basis and update the ACL with the results of the lookup. So you create an ACL entry the denies traffic to the FQDN, and it will be updated with the DNS answers all the time.
The second way is to block the URL using regex patterns in
class-maps, tied to apolicy-map. This method will only work if the communication is over port 80.In contrast, using Firepower, the URL license gives you a much more capable solution which is able to block URLs by category. One of the benefits to this method is that Cisco Talos is always providing updates to the URL database, so you can block entire genres of URLs with one click.
Now, you mention,
On the Firepower sensor, run the command
show managersto see if the sensor is hooked up to the Management Center. If it's not hooked up, then you won't be able to control the sensor at all (on a 5515x), since the sensor receives its instructions from the Management Center. If it is connected to a manager, then HTTPS to the manager and login. If not, then follow the documentation to get the sensor connected to your FMC.