IntelliShun tries two tests to determine if the bridge is working correctly. First it sends a special “magic packet” and watches for the magic packet to pass over the bridge. If it sees its own magic packet, it then declares that the bridge is ready for operation. If it is unable to see its magic packet, it tries to detect any packets passing over the bridge at all.
Scenario 1: No packets passing over the bridge at all.
If no packets at all are detected over the bridge, then either the bridge is not inline with the perimeter circuit or the bridge is inline on an inactive circuit. If your network has multiple internet circuits in an active-passive setting, the bridge might be on the inactive circuit. If this is how you intend the bridge to be deployed or will rearrange the deployment later, click “ignore”. By selecting “ignore” you are indicating that you don’t expect packets to be passing over the bridge, yet. This will also cause an alert “untested bridge configuration” message to display on the IntelliShun web UI until someday when you click “accept”.
Scenario 2: Packets are passing over the bridge, but InitelliShun didn’t see the magic packet because IntelliShun cabling is bridging two internal segments.
If the magic packet is not detected but other non-broadcast, TCP traffic is detected, then the bridge may not be connected at the perimeter. We call this the “Fax Machine” scenario because the bridge is cabled in such a way that it is bridging two internal LAN segments. If you think this might be the case, you should verify that the bridge is cabled in correctly and click “retry”. Clicking “accept” or “ignore” will end the test as described, above.
Scenario 3: Packets are passing over the bridge, but IntelliShun didn’t see the magic packet because of egress filters.
Another scenario where the magic packet is not detected involves egress filters. Some network managers or firewall administrators will use egress filters or proxy servers to block unauthorized internet traffic from leaving the network. In this case, the magic packet may have been discarded by the firewall or the proxy server. The magic packet is a UDP packet with a destination IP address of ‘api.riskanalytics.com’ and a destination port of 1776. If you have egress filters or a proxy server, you can check their logs to see if they are discarding the magic packet. Then, you can fix this by whitelisting api.riskanalytics.com and retry. If you are certain that the cabling is correct and the magic packet is being dropped on purpose, clicking “accept” or “ignore” will end the test as described, above.