This is a mirror image of remote.accns.com, with some added security enhancements, load-balancing, and scalability improvements implemented under the hood.  It also leverages a dynamic pool of IP address instead of the static MAC-address-to-IP allocation we have on remote.accns.com.  Devices can expect to get a  NAT'd DHCP tunnel IP address when tunneling to the ipsec.accns.com server.  This tunnel IP is used by the Accelerated View site to send remote commands to the device, and for accessing the device via the Terminal on Unit link in Accelerated View.

To utilize this tunnel instead of the default remote.accns.com tunnel, make the following config changes to the aView tunnel in the config settings of the device:

• set Remote endpoint -> hostname to ipsec.accns.com
• Set Remote endpoint -> ID -> IPv4 ID value to ipsec.accns.com
• Set Policies -> Policy -> Local network -> Type to Request a network
• Set Management priority to 10, which tells aView to use the tunnel IP as the primary IP to contact the unit.
• Set System > Log > Event categories > Network interfaces > Status interval interval to 1m
• Under Services -> Web administration ensure the following options are set:
  • Enable is selected
  • Port is set to 443
  • Access control list -> Zones includes IPSec
    • Note: this zone is included in the Web administration service's ACL by default, but it's mentioned here for the user to verify that it is still present in case the device is running settings that deviate from the default config

This is one of three SIG servers residing inside our peak10 datacenter, which is where our aView application lives.  This tunnel hands out dynamic IP addresses as well, in the 1.1.32.1/19 range

To utilize this tunnel instead of the default remote.accns.com tunnel, you will need to disable the default VPN -> IPSec -> Accelerated View tunnel, and create a new IPSec tunnel entry with settings matching the following configuration screenshot.  You can replace the 128.136.162.23 IP address of the SIG with either of the other two SIG servers.  I've listed all three below for reference.

• 128.136.162.22
• 128.136.162.23
• 128.136.162.24

# config dump vpn.ipsec.peak10SIG
auth.secret=AUTH0R1ZEF0R5400RM
auth.type=secret
connection_monitor.attempts=3
connection_monitor.enable=true
connection_monitor.interval=15m
connection_monitor.reboot=false
connection_monitor.restart=true
connection_monitor.success_condition=one
connection_monitor.target.0.dns_server=
connection_monitor.target.0.dns_server6=
connection_monitor.target.0.http_url=
connection_monitor.target.0.http_url6=
connection_monitor.target.0.ping_host=10.0.2.50
connection_monitor.target.0.ping_host6=
connection_monitor.target.0.ping_size=20
connection_monitor.target.0.ping_size6=20
connection_monitor.target.0.test=ping
connection_monitor.timeout=15s
dpd.delay=60
dpd.enable=true
dpd.timeout=90
enable=true
ike.initiate=true
ike.mode=aggressive
ike.pad=true
ike.phase1_proposal.0.cipher=aes128
ike.phase1_proposal.0.dh_group=modp768
ike.phase1_proposal.0.hash=sha1
ike.phase2_proposal.0.cipher=aes128
ike.phase2_proposal.0.dh_group=modp768
ike.phase2_proposal.0.hash=sha1
local.id.fqdn_id=
local.id.ipv4_id=
local.id.ipv6_id=
local.id.keyid_id=RM5400_GROUP
local.id.raw_id=
local.id.rfc822_id=
local.id.type=keyid
local.interface=
local.type=defaultroute
mgmt=20
mode=tunnel
modecfg_client.enable=false
nat.0.dst=10.0.0.0/15
policy.0.local.address=
policy.0.local.custom=
policy.0.local.network=
policy.0.local.type=request
policy.0.remote.network=10.0.0.0/15
remote.hostname=128.136.162.23
remote.id.fqdn_id=
remote.id.ipv4_id=128.136.162.23
remote.id.ipv6_id=
remote.id.keyid_id=
remote.id.raw_id=
remote.id.rfc822_id=
remote.id.type=ipv4
type=esp
xauth_client.enable=true
xauth_client.password=all1use
xauth_client.username=atap.v2vl1010
zone=ipsec

You also need to ensure the Ipsec zone is added to the ACL for the Web admin, SSH, and Remote control services, which allows aView to access the device through the SIG on the appropriate ports/services for sending remote commands and using the Terminal on Unit link.  See screenshot below for reference.

The aView application determines the primary interface for a device by looking for a network syslog with default set to pri and then parses out the intf value as the primary interface. However, if I set an interface or tunnel to have a management priority, such as the case when we want to have aView treat the tunnel IP as the primary IP address to access the device, then the device never sends a syslog where the default key is set to pri and also includes an intf key/value. The result is the primary IP address for the device in aView gets updated, but not the Primary Interface. See screenshot below for reference.

Below is a sample syslog of what is currently sent

cnt=93~type=mgmt~default=pri~ip0=192.168.64.26~name0=ipsec-tunnel-aview

What should be sent is this, where the intf value that the management priority is tied to is using. Meaning, if a tunnel has the highest management priority, I still want to know which WAN interface is the primary interface.

cnt=93~type=mgmt~default=pri~ip0=192.168.64.26~name0=ipsec-tunnel-aview~intf=wwan0

This issue is tracked with our developers in ACL-160, and will be fixed in a future firmware update.

https://jira.digi.com/browse/ACL-160

In the meantime, you can add the following custom script to a device to have it update its Primary Interface in aView properly when it's using an alternate aView tunnel.  To do so, click Add under System -> Scheduled tasks -> Custom scripts.  Select the Enable checkbox, add a 5-minute interval, then copy/paste the script below into the Commands field.

#!/bin/sh

# workaround for devices on firmware 18.4.54.22 or lower to log their primary
# WAN interface to aView when they have a mgmt priority set

send_mgmt_intf_update() {
  pri="$(runt get network.mgmt.log.default)"
  if [ "$pri" = 'pri' ]; then
    default_net="$(runt dump network.route.default | grep -m 1 -o "interface_.*=" | cut -f2 -d'_' | tr -d '=')"
    if [ -n "$default_net" ]; then
      default_intf="$(runt get network.interface.${default_net}.device)"
      runt set network.mgmt.log.intf "$default_intf"
    fi
    log=$(runt log network.mgmt.log)
    accns_log network_mgmt "${log:+type=mgmt~}$log"
  fi
}

reset_tunnel() {
  accns_log w config "custom: aView IPSec tunnel dropping incoming traffic. Restarting tunnel..."
  cat /var/log/messages > /var/log/messages.0
  echo '' > /var/log/messages
  /sbin/ipsec stop
  sleep 5
  /sbin/ipsec start
  sleep 10
  accns_log w config "custom: aView IPSec tunnel restarted"
  send_mgmt_intf_update
}

send_mgmt_intf_update


# workaround for a rare issue where the device doesn't update it's local
# tunnel IP address, resulting in device dropping incoming packets from the
# aView tunnel IPSec server

ip_addr_string='[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}'
dropped_tunnel_dst=$(grep -m 1 "DROP.*SRC=192.168.211.50" /var/log/messages | grep -o "$ip_addr_string" | cut -f2 -d'=')
aview_tunnel_ip=$(/sbin/ipsec status | grep -om1 "aview.*$ip_addr_string ===" | grep -o "$ip_addr_string")

route_exists='y' #assume the route is there, then check
[ "$aview_tunnel_ip" ] && ! ip addr | grep -q "$aview_tunnel_ip" && route_exists='n'
[ "$route_exists" = 'n' ] && reset_tunnel

if [ -n "$dropped_tunnel_dst" ] && [ "$dropped_tunnel_dst" = "$aview_tunnel_ip" ]; then
  reset_tunnel
fi

aView looks at two specific config settings within the device's config profile to determine if it needs to prompt the user for a username/password to send a remote command to the device:

1. VPN -> IPSec -> (Tunnel - in 18.4.54 or greater firmware) -> Accelerated View -> Remote endpoint -> hostname

2. Services -> Remote control -> Enable

If option 1 is set to anything other than remote.accns.com, that triggers aView to show the username/password prompt. If option 2 is de-selected, that also triggers the prompt.