About the Fox Service

The NiagaraNetwork’s Fox Service holds configuration for the local station’s Fox settings. (This varies from most other services, which are found instead under the station’s ServiceContainer.)

Figure 69. FoxService in property sheet of NiagaraNetwork

Included are properties for the TCP port number assigned to the Fox server, authentication method used, and various timeout/trace settings. If the host platform is configured for SSL (recommended if AX-3.7 or later), often you change a few related properties from defaults. See Fox Service properties for more details.

Authentication is required when establishing any Fox connection to/from the station:

If opening a station in Workbench, you must enter a valid station username and password for it in the station login dialog (otherwise it does not open).
If accessing a station in a browser as a user, where you also must enter valid user credentials (log in).
If adding a NiagaraStation to a station’s NiagaraNetwork, you must configure username and password properties under its Client Connection slot (otherwise it remains “down”). Often, you enter the username and password of a specific “service-type” user account in that station. You also specify the software port used by that station’s Fox server.
Often in a multi-station job, in each station you create a user specifically for station-to-station communications, typically with “admin write” privileges. This is the “service-type” account that you reference when you edit a NiagaraStation’s Client Connection properties, entering its username and password. For related details, refer to the section “Multi-station security notes” in the User Guide.

The Fox Service also has a Server Connections container slot with a default ServerConnectionsSummary view. Client connections to the station’s Fox server are dynamically modeled as “SessionN” child components. The summary view allows you to see all current connections, and if necessary, perform a right-click Force Disconnect action on one or more connected users.

Fox Service properties

Figure 70 shows the Fox Service expanded in the NiagaraNetwork property sheet of an AX-3.7u1 or later station.

Figure 70. Fox Service properties in property sheet of an AX-3.7 NiagaraNetwork

Fox Service properties are described as follows:

Port

Specifies the TCP port used by Fox server (default is 1911).
Fox Enabled

Default (before AX-3.8) is true. Must be true for Fox communications to occur on the port above.
If station communications are needed between any other NiagaraAX host that is not configured or capable of AX-3.7 or later SSL (such as any JACE-2), set this at true. Note that in AX-3.8, a “new station” using defaults has this property set to false. See FoxService defaults (new station) changed in AX-3.8.
Foxs Port

Specifies the TCP port used by Foxs (secure socket-layer) server, where default is 4911.
This and other Foxs properties below apply only if the station’s host is configured and licensed for SSL/TLS, including installed certificate(s).
Foxs Enabled

Default (before AX-3.8) is false. Must be true for Foxs communications to occur on the port above.
In AX-3.8, a “new station” using defaults has this property set to true. See FoxService defaults (new station) changed in AX-3.8.
Foxs Only

Default (before AX-3.8) is false. If true, and Fox Enabled and Foxs Enabled are both true, Fox connection attempts are redirected as Foxs connections. Such a configuration is different from setting Fox Enabled false and Foxs true. In that case, only Foxs connection attempts work; Fox connection attempts are ignored.
If station communications are needed between any other NiagaraAX host that is not configured or capable of AX-3.7 or later SSL (such as a JACE-2), set this at false. Note in AX-3.8, a “new station” using defaults has this property set to true. See FoxService defaults (new station) changed in AX-3.8.
Foxs Min Protocol

Specifies which standard protocol the Foxs server supports for client connections, where the default is SSLv3+TLSv1 (both, the default). Other choices are SSLv3 (only) or TLSv1 (only).
Foxs Certificate

The “alias” for the server certificate in the host platform’s “key store” to use for any Foxs connection. The default is the “tridium” self-signed certificate, which is automatically created when SSL is first loaded (by presence of certain modules and proper host licensing). If other certificates are in the host platform’s key store, you can use the drop-down control to select another one instead.
Authentication Policy

These policy options apply to how password authentication is handled by the default NiagaraAX User Service or any other service when establishing a client connection using the Fox protocol. Property choices (when using AX-3.7u1) are as follows:
- Digest
  
  This option uses password hashing. This is the recommended setting when using the default User Service.
- Basic
  
  This option does not use encryption, therefor the user password is passed in clear text. Typically, Basic is used only if using LDAP.
Prior to AX-3.7u1 (in AX-3.7), the “Digest” choice was “Digest MD5”, which equates to “legacy encryption”. This was strengthened to SCRAM-SHA (Salted Challenge Response Authentication Mechanism) in AX-3.7u1 and later. Any station upgraded from AX-3.7 will automatically upgrade from “Digest MD5” to “Digest”. This also relates to a new FoxService property, “Legacy Authentication”, described below.Additionally, a third “Transactional” choice for Authentication Policy (available in prior AX-3.7) is no longer available, as products that were designed to use it were discontinued.
Legacy Authentication

(AX-3.7u1 or later only) Applies to password authentication when establishing a connection with a remote Fox client (either another station or Workbench). Choices are as follows:
- Strict
  
  (Recommended, and default) Remote client must be able to handle passwords using SCRAM-SHA, requiring it to be running AX-3.7u1 or later. Clients running earlier “pre-2013” NiagaraAX releases are considered “legacy clients”, and will be unable to connect.
- Relaxed Until (date)
  
  Allows a legacy client to connect to this station using Basic authentication, but only until the specified date. After that date, this setting behaves the same as if set to Strict.
- Always Relaxed
  
  Always allows a legacy client to connect to this station using Basic authentication. Be especially careful if setting to this value—see the Note and Caution below!
Both “Relaxed” choices are intended for temporary usage only during a system upgrade to one of the “security update” releases. For example, after upgrading a Supervisor, you could set its Legacy Authentication to relaxed only until all its subordinate JACEs have also been upgraded. This would allow those stations to continue to communicate to the Supervisor until upgraded. Strict is the most secure option. After a system-wide upgrade, set this to Strict in the FoxService of all stations!For related details, refer to “Upgrade considerations” in NiagaraAX 2013 Security Updates.
Unless set to “Strict”, either “Relaxed” option is effectively the same as setting the FoxService property Authentication Policy to “Basic” for any legacy connection attempt, as this is the only “common ground” authentication between a legacy Fox client (Workbench or another station) and this update release station. Thus, passwords for client connections to this station are passed in clear text (if a legacy client). Obviously, this is not a desired operating state. For this reason, you should seldom (if ever) set the Legacy Authentication property to “Always Relaxed”.
Request Timeout

Time to wait for a response before assuming a connection is dead (default is 1minute).
Socket Option Timeout

Time to wait on a socket read before assuming the connection is dead (default is 1minute).
Socket Tcp No Delay

Used to disable “Nagle’s algorithm”, found to cause issues with delayed acknowledgements that occurred in TCP socket communications between Fox clients and servers. The default (and typically recommended) value is true, disabling Nagle’s algorithm.
On the Workbench side, there is a line in the system.properties file you can enter to adjust this setting: “niagara.fox.tcpNoDelay=true”.
Keep Alive Interval

Interval between keep alive messages (default is 5 seconds). The keep alive should be well below the request timeout and socket option timeout.
Max Server Sessions

Maximum number of Fox/Foxs server connections before client connections error with busy. Default is 100.
Multicast Enabled

Default is true. Allows UDP multicasting initiated by the station, necessary for a discovery from this station. Note this is different than Workbench UDP mulitcast support, which can be optionally disabled via an entry in the Workbench host’s system.properties file.
Enable Announcement

Either true (default) or false. Enables support of UDP multicast announcement messages received by the station, in support of learn/discover.
Multicast Time To Live

Number of hops to make before a multicast message expires (default is 4).
Server Connections

Provides status information about current Workbench client connections to the local station (does not reflect station-to-station Fox connections).
Trace Session States

Either true or false (default). Debug usage for tracing session state changes.
Trace Read Frame

Either true or false (default). Debug usage for dumping frames being read from the wire.
Trace Write Frame

Either true or false (default). Debug usage for dumping frames being written to the wire.
Trace Multicast

Either true or false (default). Debug usage for tracing multicast messaging.
Tunneling Enabled

If enabled, allows the station to perform as a Fox “tunnel” (i.e. proxy server) through which Workbench sessions can be established to other Niagara hosts, typically unreachable otherwise. A special tunnel ORD syntax is used from the client Workbench to reach target stations through the Fox tunnel. Usage requires the proxy server (typically the Supervisor host) to be licensed for Fox tunneling. For more details, see “About Fox Tunneling” in the engineering notes document Fox Tunneling and HTTP Tunneling. Note this property does not affect platform tunneling, introduced in AX-3.5.
Only Tunnel Known Stations

An added security option that affects Fox tunneling, HTTP tunneling, and platform tunneling. Applies only if the station is configured as a tunnel (proxy server).
- If left at the default (false) value, a tunnel connection is permitted to any target IP address given in the tunnel ORD, or in the case of platform tunneling, to any “Tunnel to” IP address entered in the Workbench “Open Platform” dialog.
- If set to true, Fox, HTTP, and platform tunneling is permitted only to a station that exists in the proxy server’s NiagaraNetwork, where tunnel ORD (Fox) or URL (HTTP) syntax uses the target station’s name instead of IP address. For platform tunneling, the target “Tunnel to” in the Workbench “Open Platform” dialog also requires the station name.
  
  For example, going through 10.10.8.9 to reach target station “demoStation” at 10.10.5.4
  - instead of (Fox) tunnel at ip:10.10.8.9│fox:/10.10.5.4
  - now (Fox) tunnel at ip:10.10.8.9│fox:/demoStation
  or
  - instead of (HTTP) tunnel at http://10.10.8.9/tunnel/10.10.5.4
  - now (HTTP) tunnel at http://10.10.8.9/tunnel/demoStation
  or
  - instead of platform tunnel at “Host” = 10.10.8.9, “Tunnel to” = 10.10.5.4
  - now platform tunnel at “Host” = 10.10.8.9, “Tunnel to” = demoStation
Again, note that if this property is set to true, that the target NiagaraStation name must be used in the Fox tunnel ORD, HTTP URL, or Workbench “Open Platform” dialog—and not IP address.

FoxService defaults (new station) changed in AX-3.8

To encourage stronger security, any new station made using defaults from the New Station wizard in AX-3.8 Workbench is created with both its FoxService and WebService configured for “SSL only”, or more accurately, with selected properties set as shown in Figure 71.

Figure 71. FoxService and WebService “New station” defaults in AX-3.8

As shown above when using the New Station Wizard, if needed you can change the default “Foxs Port” and “Https Port” values from defaults (4911 and 443, respectively). Or, you can simply clear the default “Use secure connections” checkbox.

If you do the latter, the dialog changes to let you specify the (non-SSL) “Fox Port” and “Http Port” from defaults if needed (1911 and 80, respectively). Then the new station created has all Boolean properties above (circled in Figure 71) reversed for “non-SSL” usage: Fox Enabled=true, Foxs Enabled=false, and Foxs Only=false; in the WebService: Http Enabled=true, Https Enabled=false, Https Only=false. Essentially, this is how the New Station wizard works in AX-3.7u1 and prior releases.

In some cases, such as when making a station for a JACE-2/4/5 series controller, which does not support Fox SSL or Foxs (even if AX-3.7 or later), it makes sense to clear the “Use secure connections” option in the New Station wizard. Alternatively, you can simply edit the properties shown in Figure 71 as needed after the station is created, with its config.bog file opened in Workbench (offline).

For related details, see the sections “New Station wizard” and “WebService” in the NiagaraAX User Guide. For more details on SSL in NiagaraAX, refer to the NiagaraAX SSL Connectivity Guide.