How many SonicPoints can I add to a TZ 170 SP?

What does ‘Allow Interface Trust’ mean for a zone?

When this box is checked, all interfaces added to the zone will automatically have security policy written to allow all systems connected to each interface to talk to each other – if checked, you will see these policies show up in the firewall access rules policy intersection for that zone (for example: ‘LAN > LAN’). These polices can be adjusted as needed, or deleted completely.

I created some zones, but they do not show up in the rules matrix – why?

Zones will not display in the access rules matrix unless an interface has been explicitly bound to the zone. Once an interface has been added to a zone, it will then show up in the matrix, and you can then write rules to/from this zone.

How many SonicPoints can I add to a TZ 170 SP?

You can add up to two SonicPoints to the OPT interface, once the OPT interface is added to a Wireless zone. Please note that the TZ 170 SP must be running SonicOS 2.6 Enhanced or newer to support SonicPoints.

Can I put SonicPoints in the LAN or WAN zone?

No, you cannot. In order for SonicPoints to be acquired, provisioned, and controlled by the TZ 170 SP, they must be placed into a Wireless zone. The WAN and LAN zones also do not have the WiFiSec and WGS enforcement tabs, as the Wireless zones do. While a SonicPoint can be configured to run in standalone mode and could conceivably be hand-programmed and attached to the LAN zone, you’d lose WiFiSec and WGS capabilities for the wireless users associating with that SonicPoint.

Can I connect a third-party wireless access point to the TZ 170 SP?

Yes and no – it’s not possible to connect a non-SonicWALL access point to a Wireless zone, as the TZ 170 SP will not communicate with third-party access points, and will block all wireless traffic attempting to connect through it from that access point. However, it is possible to hook a third-party access point to any zone not marked as a wireless zone, but you will not be able to enforce WiFiSec or WGS for any wireless user connecting through that access point.

What is ‘Consistent NAT’?

This is a new feature in SonicOS 2.5 Enhanced and newer. The control for this feature, which is located on the ‘Firewall > VoIP’ page, should be left unchecked by default. The Consistent NAT option modifies the SonicWALL's standard NAT behavior when handling outbound UDP traffic in order to provide higher levels of compatibility with a small handful of certain peer-to-peer applications such as some online games and Apple's ‘iChat’ application. Consistent NAT uses an MD5 hashing method to consistently assign the same remapped (i.e. Network Address Translated) public IP address and public UDP port pair to each internal private IP address and private UDP port pair. For example:

Private (LAN) IP: 192.168.168.10 --> Consistent Remapped Public (WAN) IP Address: 64.41.140.167

Private (LAN) UDP Port: 50650 --> Consistent Remapped Public (WAN) UDP Port: 40004

Private (LAN) IP: 192.168.168.10 --> Consistent Remapped Public (WAN) IP Address: 64.41.140.167

Private (LAN) UDP Port: 50655 --> Consistent Remapped Public (WAN) UDP Port: 40745

Private (LAN) IP: 192.168.168.20 --> Consistent Remapped Public (WAN) IP Address: 64.41.140.167

Private (LAN) UDP Port: 50650 --> Consistent Remapped Public (WAN) UDP Port: 54621

Private (LAN) IP: 192.168.168.10 --> Consistent Remapped Public (WAN) IP Address: 64.41.140.167

Private (LAN) UDP Port: 50650 --> Consistent Remapped Public (WAN) UDP Port: 49724

With Consistent NAT, all subsequent requests from either host 192.168.168.10 or 192.168.168.20 using the same Private UDP ports as illustrated above would result in the use of the same, predictable remapped Private UDP ports. Without Consistent NAT, the remapped port would change with every subsequent request, providing no consistency, and no predictability. Most UDP based applications are perfectly compatible with the latter, and do not require Consistent NAT.