While testing the new Gateway URL Filtering feature in NSX-T 3.2 I noticed an area where you can add a custom response message to any denied page. With a small hack, I found that you can make this function more usable by inserting some HTML code into the response instead of plain text (as is the intention of the product). Here’s how to do it!
Setup
First you need to install and license NSX-T 3.2 or higher and configure URL Filtering on your Gateway Firewall. There are many other blogs (example) that can help with this, or you can refer to the official VMware documentation.
Once you have your Gateway rules defined, you specify a policy as to which action to apply to a URL category such as Accept, Reject, or Reject With Response.
For testing purposes in my environment I have created a L7 Access Profile to Reject Gambling sites, Reject with Response Dating sites, and to allow all other sites (note, you need the allow all in order for the metrics to show up in the dashboard).

Take note of the information message in blue – this is where we will edit the default response.
Configure the Custom Response
By default, when a category is accessed with the “Reject With Response” policy, the user is presented with a fairly boring page that does not meet with any corporate branding standards, or have functionality such as a button to raise a support ticket for an exception.

Change the Message
- Navigate to Security / Gateway Firewall / Settings / URL Filtering
- Edit the Response message and Save
- Select Preview Page to take a look


Insert Custom Code
Within this Response Message box I thought I would try inserting some HTML code to see what happens. It does work, but note that you are limited to 500 characters which seriously impacts what kind of response code you can insert.
Here’s an example to prove the concept:
<h3 style="text-align: center;"><span style="color: #ff0000;"><strong>YOU ARE BUSTED!</strong></span></h3>
<div style="width: 480px;">
<div style="width: 480px;"><iframe src="https://giphy.com/embed/CJyRX8btFziYLt3WAT/video" width="480" height="270" frameborder="0"></iframe></div>
</div>

Redirect the Page
Of course the most useful thing to do would be to reload the entire page with content hosted elsewhere. You could create your own custom page with corporate branding, links to Internet usage policies, buttons to raise a service desk ticket for an exception etc.
In my case I am using a secure browsing product called Garrison which provides hardware-based isolation for browsing of highly sensitive/secure web sites. In this way no malicious content can ever be copied to the user’s endpoint. To achieve the redirection:
- Create a L7 Access Profile for these sites and instead of selecting URL Category you select Custom URL.

- Select the three vertical dots next to the Attribute Name/Values box and select Custom URL
- Enter the FQDN of the site that you want redirected (Yes, I know it says URL, but if you add https://sitename.com it will not accept it).

4. Add more sites following the same method. You can also add them directly inside the box.

Once you have your profile defined, head over to the Gateway Firewall settings to change the Response Message. Enter the following HTML redirect:
<meta http-equiv="Refresh" content="0; url='https://mysite.com'" />

When a site matching the policy is accessed, the entire page will now reload with the redirected site.

Closing Thoughts
While the Gateway URL Filtering function is a welcome addition to NSX, the basic redirect page while informative is not in alignment with enterprise requirements for branding and functionality and needs some customisation. Luckily the custom response message setting accepts HTML code so you have a limited ability (500 characters) to customise the look and feel of the redirect landing page.
By redirecting the entire landing page to an external site you have the ability to be fully in control of what the user sees. In the example above I have shown a use case where a user is able to browse all publicly and internally available websites except for a select few which according to a policy will get redirected to a more secure hardware-based offline browsing method.
Awesome work! Thanks for sharing!