This section provides information about Bypass Rules.
About Bypass Rules
As you may know, Untangle's applications run in what we call the UVM - the Untangle Virtual Machine. There are some instances in which certain types of traffic should not or cannot be properly scanned by the UVM; in these cases we must tell Untangle not to scan that traffic. We use Bypass Rules to accomplish this. Taking a look at the image on the right, you can see a rough example of how the process works - incoming traffic is "pushed up" into the UVM, where depending on your particular settings it will be scanned by one or more applications. After it is scanned and perhaps filtered, the resulting traffic is "pushed out" onto the correct interface where it will be delivered to its recipient.
A good example of traffic to bypass would be VoIP; while we can scan it without issue it is time sensitive and there's no real reason to waste the resources. If we add a Bypass Rule, the traffic will be routed by the kernel and won't be seen by the UVM. We bypass VoIP traffic by default, however we have run into situations where certain sites just will not work unless traffic to them is bypassed.
Remember, if you're bypassing traffic is is not scanned at all, even by the virus scanners. You should bypass only traffic you do not need to scan.
There are two sections on the Bypass Rules page - Bypass Rules where you can add your own, and System Bypass Rules where we've included a few. We recommend leaving the System Bypass Rules enabled for normal operation.
Creating Bypass Rules
If you need to create Bypass Rules, navigate to Config > Networking > Advanced > Bypass Rules. We have System Bypass Rules on the bottom that can be enabled or disabled; you can add your own at the top under User Bypass Rules. Much like Port Forwards, you'll use the qualifiers to build rules that will match the traffic you want to bypass. Here is a list of qualifiers:
|Destination Address||IP Matcher||The Destination IP of the traffic.|
|Destination Port||Port Matcher||The Destination Port of the traffic.|
|Destined Local|| This will match on any IP the Untangle holds, including aliases.|
Only recommended if your WAN interface(s) are Dynamic.
|Protocol||Checkboxes||The protocol that should be forwarded - check all that apply.|
|Source Interface||Radio Buttons||The Source Interface of the traffic - choose only one.|
|Source Address||IP Matcher||The Source Address of the traffic.|
|Source MAC Address||XX:XX:XX:XX:XX:XX||The MAC Address of the source of the traffic.|
Example Bypass Rule
Untangle has some built-in rules to help you bypass common traffic types, however we'll provide an example here with for you to understand how to build your own rules:
- Destination Address: 192.0.2.7
- Protocol: TCP
This is almost the same as our example Port Forward rule, so hopefully it should look familiar. Say your users are having a problem connecting to a web site at 192.0.2.7. You've tried turning off all the rack applications, but they are still having problems with the site. In this case that site may be put together in such a way that we are unable to scan its traffic without causing issues, so we can try adding a bypass rule so traffic to that site is delivered without scanning.
A fairly simple rule, but let's take it a step at a time. The Destination Address qualifier says "If the traffic is destined for 192.0.2.7", while Protocol says to match only on TCP. So if we have Alfred at work behind an Untangle trying to connect to Betty's web server, in this case he would enter 192.0.2.7 in his browser - the IP of the target web server. Once this traffic hits the Untangle it matches all of the qualifiers we set up in the rule, so the traffic is passed to the web server without being scanned, allowing the transaction to operate without issue.