Hi @NetworkMonkey101,
Hope you are well! Even though you are probably aware of much of what I will write, I will explain based on the off chance that you are not, and just that other people may come here to learn or get an answer to a related question.
I’m not sure whether you are using Smoothwall as a Web Proxy, firewall, or both. As Smoothwall is available both as a cloud deployment and on-premise deployment, may I ask which one you are using? I can make a deduction it is on-premise based on the fact you are migrating to a Cisco FTD. I guess if you had Smoothwall in the cloud it would be possible you had looked at a Cloud Web Proxy such as Umbrella, so as to not re-design the fundamental traffic flow, but again this would depend on the features you are currently using on Smoothwall and the desired design. I guess it’s also cheaper to use existing NGFW functionality if the need for a dedicated proxy or advanced web inspection and web filter features aren’t required/worth.
Can I ask if you managing your FTDs via an FMC or using FDM?
Based on the fact you are looking to move to a Cisco FTD from Smoothwall, I am making a guess—which could very easily be wrong—that you are migrating from using Smoothwall filter (Web Proxy) only (not just Smoothwall firewall) and perhaps already have firewalling deployed at your FTD? Either that, or you've already sussed out how to migrate the firewalling between Smoothwall and the FTDs.
It's worth a mention that Smoothwall *was* primarily a solution designed for the education sector as a proxy service that is catered towards safeguarding. If using Smoothwall as a web proxy I’ll add that the web content filtering for Smoothwall and its available categories are a fair amount different than the FTDs capability. This is more from a business/stakeholder discussion and sign off perspective. Are they happy that not all types of filtering on Smoothwall can be moved like-for-like to the FTD? It depends on what industry/organisation you are working for and the context of the users for whom this is providing filtering for. Overall Smoothwall has more content categories, and granularity with filtering, but I'd say lacks the cybersecurity features and intelligence with classifying malicious destinations compared to Cisco Talos. I will say that is just my opinion, but one I am confident on, having worked with both products. Whether or not this is useful to you depends again on the design and how much effort you've currently investigated on migrating to/from these products.
The URL filtering implementation on the FTD, with regard to matching identities for the application of the right rules, will depend if you are currently leveraging Active Directory, Entra, and ISE, as a means of identity matching in your organisation, and whether or not you are using that in Smoothwall. If not, and you want to base the rule matching based on IP address then that will make the implementation a lot easier.
I/you will also need to know not just if your Smoothwall is acting as a firewall or proxy, but also, if it is deployed as a transparent proxy or explicit proxy. FTDs can't run as a proxy per-se, so there will be additional work that needs to be done to remove Smoothwall agents from the machine, or alternatively, removing the WinINET or WinHTTP settings on client devices if that is how they are currently forwarding. Again, depends on what is being used on Smoothwall. Also, if in an explicit proxy deployment, how you migrate clients from Smoothwall to the FTD based on this will depend on whether you apply the settings via Group Policy (or Intune) if on a Windows environment. I did have a look at your previous posts to save a bit of back and forth - it looks like you have ISE and perhaps have already integrated that with the FTD.
You will of course need the URL License. It is not needed to use manual URL filtering, i.e. specifying individual URLs in ACP rules. But it is needed for the content categorisation which is what I am assuming you wish to use. Again, I realise this is probably already in place.
I haven't explained things quite as clearly as I would've liked, so please let me know if you are finding these questions a bit all over the place and need more clarity.
You will probably need to look at an SSL decryption policy, as you do not want users to just be blocked from a website without returning a block page and message. You need this configured so that clients don't get certificate errors (which they will unless they are browsing to a website using HTTP). Which model of FTD are you running? The CPU needs to be able to deal with the SSL decryption. You will also need to integrate this with your internal CA server. It's so that when the FMC tries to return its own block page, the certificate is trusted by the client and in the trusted root certificate store. Otherwise clients will start to get 'not secure' messages.
If you are doing URL filtering based on IP addresses you will just require the URL Filtering rules within the ACP policy that globally leverages and maps the SSL decryption policy. If you are filtering or matching clients based on user groups from ISE you will need to create an Identity Policy as well. ISE integration will allow the IP to user mappings to be consumed by the FTD via the PxGrid integration with ISE for use in the rules. You could also use SGTs that are applied by ISE should that be of relevance. There are other options for integration, such as a Microsoft TS Server agent, but the configuration guides for setting up Realms, etc., should provide help here and infer the best option for your environment.
You should also modify your Access Control Policy's advanced global settings in preparation to start using URL Filtering. There are some good guides on this.
Generally, proxies operate on an allow all basis and filter out content categories, etc., that should be blocked. You may want to think about how these policies are going to be migrated from Smoothwall to the FTD, and whether you want to do the same or reverse this logic to a block all. This depends on your environment of course, but generally an allow all is still the way to go. If your Smoothwall is doing file blocking and analysis then you may consider if your FTD has a malware (threat license also required) license and if you plan on implementing that.
Finally, take a look at the Integrations screen and ensure your URL Filtering is setup and the caching and lookups are set according to the guides. The FTDs perform cloud lookups to Cisco Talos in order to classify URLs to the correct categories and receive the right updates. You want to adjust caching based on your platform and activity.
I apologise for the long wall of completely unstructured text. Hopefully this gives some useful information. Again, any information you can provide about your design would help me with answers. Hopefully your migration is a smooth one!
