Troubleshooting services behind DTTS® in pfSense

CAUTION! This article assumes that blocked domain traffic has already been ruled out as the cause of app connectivity issues.

By design, the DTTS™ security feature prevents mis-behaving apps, malware and circumvention tools from reaching out to the internet by preventing outbound DNS-less traffic. However, on occasion services utilize DNS-less traffic for which “enablers’’ are required: Enablers on pfSense

Is the issue caused by DTTS™?

If no domain traffic is being blocked, to quickly identify if DTTS™ is the cause of an app not functioning properly, you can use a temporary bypass rule in pfSense for the IP of the device hosting the application or service.

The example rule circled in the image below allows all TCP/UDP connections from the device with an IP of 192.168.11.222 to all destinations. If the app still does work on a device behind this bypass rule, then you know it’s not related to DTTS™.


CAUTION! Never leave a bypass rule like this enabled. It causes the entered Source to bypass all filtering and security provided by adam:ONE.
Tip - to disable the rule:
Click on the ∅ prohibit symbol (right side of rule), and then -> Apply Changes

How to find the blocked IP address needed for the Enabler

Enablers are inherently dangerous as they bypass the protection of adam:ONE, so it’s important to limit the IP and Port ranges to what’s absolutely necessary. Often the app or service provider will publish the necessary firewall configurations, but if not, you can use the dynamic logs found in the pfSense GUI to discover the IP/Port/Protocols as follows:

Status -> System Logs -> Firewall -> Dynamic View

  1. Narrow down the search results by using the Advanced Log Filter:

-> funnel icon (at the top right) -> expand the filter by clicking on the + symbol (right side of Advanced Filter Log bar)

  1. Add the source IP of the device hosting the app or service you are troubleshooting

  2. Now repeatedly restart or refresh the app service and look for a repeated connection being blocked by DTTS™ each time the service tries to reconnect. Take note of the:

  • IP(s)
  • Port(s)
  • Protocol (UDP or TCP)
  1. As an added precaution, use a “whois” type lookup tool to determine whether the blocked IP belongs to the actual service provider or to the CDN used by the application. Examples:
  • from a command prompt or terminal window, enter whois 17.1.2.3

Or use a browser application like https://bgp.he.net/ and enter the IP in field provided some point.