Frequently Asked Questions

VPN

What is a VPN?

A virtual private network (VPN) extends an enclave network such as the Non-Classified IP Router Network (NIPRNET) or BLACK core and its resources contained in the network across public networks like the Internet to a remote site such as the MissionMobility Module Devices.

The VPN can be broken down into 2 processes:

1. ISAKMP Process: This deals with the authentication, buildup and teardown of the VPN tunnel. It will also periodically check on the VPN tunnel depending on the configuration set.

2. IPSEC Process: This process deals with the encryption of the packets that will transverse the VPN and what will be allowed through.

What is the encryption Strength of my VPN?

With the entire MissionMobility VPN aware devices, you have the option to go up to AES-256 /SHA encryption strength.
To see what your encryption strength would be within your router examine the string under “crypto ipsec transform-set XXXXX esp-aes 256 esp-sha-hmac”

What are the different VPN configuration types used?

Depending on the customer, MissionMobility can configure for many different VPN uses:

1. (Point-to-Point VPN) Standard Virtual Private Network, VPN, allowing the connectivity of unicast packets from one network to another. (No native multicast, routing protocol support or Multi-gateway support. This type of VPN can be used on our entire product line.
2. (DMVPN) Dynamic Multipoint Virtual Private Network is a VPN protected GRE tunnel. Allows for native multicast, routing protocol, and mutli-gateway support configuration. This type of VPN can be used on our entire product line with the exception of the LoneWolf module. (DMVPN not support in ASA operating system)
3. (EZVPN) this is similar to the Point-to-Point VPN except that most of the configuration is kept at the Gateway VPN router. This allows for minimum configuration on the mobile routers. When the MissionMobility module connects to the Gateway router and is authenticated, it then pulls the needed configuration to finish up the creation of the VPN tunnel.
4. (Mobile IP) though not a type of VPN, it is an authenicated tunnel that works in conjunction with a normal VPN to allow for greater flexibility in connection methods and failover time in COOP situations.

How can I tell if my VPN is operational?

By using the show and debug commands from within the router console you can find out a lot of information concerning your gateway or mobile router’s VPN. A few of the show tools can be found below:

Show commands: (From the Privileged mode)

Show Crypto ISAKMP SA
(This will show you the status of the ISAKMP process) under normal conditions when the VPN is operational, you will see QM_IDLE.

Show Crypto IPSEC SA
(This will show you the status of the IPSEC process) under normal conditions when the VPN is operational, you will see Active as well as the VPN end-point IP identifiers. From this page you can also see if packets are being received (decapsulated) or sent (encapsulated). You can perform a refresh by typing the command again to see if the counters are incrementing.

Show Crypto SESSION detail
(This command will show you a snapshot of both the ISAKMP and IPSEC SA show commands instead of typing each one independently). Some information is omitted in the session detail command as opposed to view each individual command. Most information for troubleshooting can be gained from this command.

What services can run over the VPN?

Any services connected or access via the Gateway VPN router and allowed by Firewalls and/or permissions can be accessed via the MissionMobility mobile VPN module. The module can gives access to the remote networks at the gateway, but still other authentication and permission issues exist past that point such as Active Directory or Firewall access into the gateways enclave. In a normal DOD network you may find that either NIPRNET Services and/or a Black core is passed through the VPN. All traffic not SBU and above NIPRNET will be encrypted as well by a NSA Type-I approved In-line Network Encryptor such as a KG-250, KG-175, SecNet-54, etc.

What MissionMobility Modules can run a VPN?

Most of the MissionMobility modules are powered by Cisco or Vocality and can run VPN’s. Below is a list of current devices that can run VPN’s.
LoneWolf – Cisco ASA 5505 Base OS modules
Defender – Cisco 32XX series mobile router-based IOS modules
Defender-Voice – Cisco 32XX series mobile router-based IOS modules
Defender-X – Cisco 59XX series mobile router-based IOS modules
WolfPack – Cisco 59XX series mobile router-based IOS modules
Guardian – Vocality router-based modules
Spectre – Cisco 59XX Series router-based IOS module with VM Ware

How do I solve issues with VPN connections?

Ensure there is a path to the VPN Gateway. You will not normally be able to PING the Gateway VPN end-point due to access control list (ACLs) and Firewall blocking.

1. Ensure the output connection you will connect the Kit to is good

  • a. If at hotel, home connection, or broadband connection, can you get to the public internet? On hotel internet, you may have to pay or agree to a splash page before you can receive public internet connectivity.
  • b. If using SATCOM, Check to ensure you have a link to the distant end and that the SATCOM device has registered with the provider along with having air-time available.
  • c. If using Integrated Services Digital Network (ISDN/INMARSAT), Ensure the Terminal adapter (TA) can a Link to the Gateway TA. Check lights on TA device once connection is dialed up.
    • i. If using Tiny-bridge devices, ensure they are powered-on and connected properly.

2. Check to ensure the mobile VPN device is connected to the next hop with a good link and has an IP address.

  • a. If the interface from the mobile VPN device is a statically assigned IP address and subnet, ensure that the attached device is within the same subnet and has the connect configurations.
    • i. Within the static route configuration it will have a route to the VPN end-point for specific interface. Perform a “show ip route” command to ensure the route exist in the routing table. Ensure that the Gateway for that hop is the next connected device to the path the packet needs to travel to reach the VPN Gateway.
  • b. If the interface from the mobile VPN device is DHCP assigned, ensure that the interface is assigned an IP address by the provider.
    • i. Within the route configuration it will have a route to the VPN end-point for specific interface with DHCP as the gateway. Perform a “show ip route” command to ensure the provider assigned a gateway via DHCP. Ensure that the Gateway for that hop is the next connected device to the path the packet needs to travel to reach the VPN Gateway.

3. To connect to the Gateway VPN, 3 Major ports need to be open between the Mobile and Gateway VPN devices.

These ports are as follows:

  • UDP 500 (ISAMKP) will always be used for setup and negotiations of the VPN.
  • IP50 (IPSEC) will be used if no Network address translation (NAT) is performed in-between the 2 end-points to transmit encrypted data.
  • UDP4500 (NAT-Transversal) is used instead of IP50 in cases where NAT is present such as a Hotel or Home Network. (Meaning not using a publicly routable IP address. The address assigned to the kit via DHCP or Static is turned into another IP address before entering the public Internet.)
  • a. There may be times where the gateway Firewall will go through changes and the ACL or firewall entry will not allow one of the 3 types of packets above to reach its destination or return back to the mobile VPN device.
  • b. Some Hotels may block VPN access from there site (this is not as common today), In these instances, you will need to contact the front desk or the hotel ‘s internet provider.

4. All VPN’s require the need of interesting traffic to start the connection to the gateway.

  • a. For LoneWolf base ASA devices and Point-to-point VPN in the IOS routers, Traffic will need to be initiated from a Laptop off the internal LAN network of the device to provide the interesting traffic to start the VPN. There may be an initial delay as the VPN builds before traffic is sent across.
  • b. For DMVPN /GRE (Dynamic Multipoint Virtual Private Network/Generic Routing Encapsulation) configured devices, The Device is always looking to connect to the Gateway and will create the interesting traffic to start the VPN operation. There may be an initial delay as the VPN builds before traffic is sent across.

INE (In-line Network Encryptor)

How do I connect my INE device to the gateway?

To ensure the remote INE device connects to the Gateway the following needs to be in place and verified:

1. Ensure you have a link to the INE black-side (CT) and to the next connecting device and that there is connectivity.

2. A Path exists to the Gateway INE device. This path can either be a NIPRNET or BLACK enclave path depending on the setup of the network.

Perform a “BLACK” ping from the remote INE to the CT endpoint of the Gateway INE. If the Ping is successful then you have CT connectivity to the network. If not check the following:

  • Ensure the Transport (Either NIPRNET or BLACK enclave is up and operational)
  • IP addresses and subnet mask.
  • BLACK routes in the INE devices.

3. The correct time has been set and is within the lowest common tolerances of the connecting INE devices.

  • Example: If using 2 KG-250 devices, the devices cannot be off more than 55 minutes.
  • If using different INE devices, go with the lowest “maximum” setting allowed between the two.
  • Ensure the connecting INE’s are using the same time (example: GMT, EST, etc.)

4. Ensure the HAIPIE version are correct

  • Older INE devices may not understand or recognized what to do with newer transform-sets.
  • If using 2 different HAIPE version ensure that the newer INE device does not offer new transform-sets.

5. Ensure the CIK has been provisioned for the enclave that the INE device will be used for.

6. Ensure the F/F key or pre-placed key has been loaded and is current.

  • If Firefly key, Short title must match , but KMID’s must be different (Yearly)
  • If Pre-placed keys, the Keys will be exact (Monthly)
  • Classification must match that of the provisioned CIK or Key will not load.

7. Ensure secure tunnels routes and security associations have been configured and are correct.

  • These tunnels are used to pass the Plain Text (PT) traffic between the connecting INE devices.
  • Ensure the correct key type has been associated with the secure tunnel.
    • i. An example is HIKE, BATON, etc.

8. Ensure traffic is passing into the (PT) side of the INE device.

  • The INE device will not try to create a secure tunnel to the remote INE device until “interesting traffic” (That is traffic that matches the secure tunnel configurations) is received from the RED INE port or (PT) port.
  • If there is no interesting traffic passing into the INE device, perform a manual connect within the INE device if available.
  • MissionMobility equipment that is configured for DMVPN or GRE tunnels on the enclave and plugged into the RED (PT) side of the INE will generate interesting traffic as the modules are trying to connect to the GRE end-points.

General

What is the sequence on MissionMobility Kits with Multiple Input Power options?

Please refer to the manual for the specific power device you are using with the kit. As a general rule the following applies to most of the MissionMobility kits that accept multiple inputs for power:

1. AC (Primary)

2. DC (Secondary)

3. Battery (Tertiary)

From the order above, once input fails it will look to the other sources for power. Once power has been re-established the device will automatically switch over to the more preferred source.

Example: On loss of AC, device will try DC and then Battery. If Battery is the only other connected source it will go to battery power. If DC is established, the kit will use DC power instead of the Battery. The same holds for AC. In most instances, with exception of the older kits, the Battery will charge if connected to the Kit with either AC or DC power connected.

The power output is regulated and the power module acts as an “On-line” UPS with the battery attached so that the attached devices will not lose power during the changeover. The user can change from one power source to another without dropping the power needed to the attached devices as long as 1 of the input power sources are available.

How can I set my kit up so that the power module acts as a UPS?

The MissionMobility kits with the multi-Power options allows for multiple input sources for power. The internal circuitry provides a regulated output for the attached devices. This internal circuitry will also act allow the power module to “On-line” uninterruptable Power Supply (UPS) for the attached devices. (Meaning if voltages drop out of tolerances, the power module will switch to the next preferred device.)

To setup the kit, connect a Primary source such as AC and or DC voltage to the appropriate connectors and then connect the battery to its appropriate connector. Ensure the Input power switches are turned to the “on” position for each input.

If the primary power sources are loss the kit will revert to Battery power. Once primary power has been restored the Power module will switch back to the primary power.

Note: that when on primary power the Battery will charge. (See device manual for indications)

What is the MissionMobility Dashboard GUI?

The MissionMobility Dashboard is a Graphical User Interface that can be access via your browser on the laptop associated within that enclave/domain.

It allows for the monitoring and many reconfiguration tasks that the operator in the field may need without the full knowledge of Cisco IOS-based command lines or other devices within the kit. It can be used in either the User mode which allows for monitoring without reconfiguration access and access to passwords or it can be used in the admin mode for full access to its resources.

To see the features and devices capable of supporting these functions refer to your kits manual or contact MissionMobility for assistance.

What are the steps on bringing the kits up on-line to reach full convergence?

  1. The Physical WAN is connected on both sides.
  2. There is an IP Path between the Gateway and Mobile VPN End-Points.
  3. The VPN has been established between the Gateway and Mobile SBU Routers.
  4. Routing Protocol Database can converged between the Gateway and Mobile SBU Router.
  5. VPN/NIRPNET Router is now Ready. NIPRNET Laptops and Peripherals can attach.
  6. The INE has Black Connectivity.
  7. The INE builds a Type-I crypto tunnel to Gateway INE.
  8. The SEN Router has connectivity to the Gateway SEN Router tunnel End-Point.
  9. The SEN router builds GRE tunnel to the PACAF Gateway SEN router.
  10. Routing Protocol Database can converged between the Gateway and Mobile SEN Router.
  11. SEN Router is now Ready and Peripherals can attach.
  12. The Computers and VoIP phones have connectivity to Gateway.

Each Line requires the line above it to be in-place and operational to allow for complete convergence.

Example: Without (#7) Black INE connectivity, (#6) INE builds tunnel cannot occur.

MissionMobility Devices and Kits

What is the Defender?

The Defender Series is MissionMobility’s most rugged and scalable baseband communication solution. Designed to access your headquarters office network from anywhere in the world, the crypto agnostic, flexible powered Defender Series supports mobile tactical teams and units, providing solutions for mission critical communications, in the most demanding environments.

What devices are used in a Defender kit?

The Standard configuration is that of 2 Cisco 32XX based routers with SKIPWARE TCP acceleration.

It is divided into 2 sections:

  1. NM Module: (Network module) Used for networking and access to an enclave. It can standalone with an external power adapter or can draw power from the INS module
  2. INS module (Integrated network module solution) contains all the features of the NM module above with the power requirements needed for internal components as well as external components. This device can also supply regulated power to KG-250 INE devices.

Both devices above come in a ruggedized module and are easily transported within a single lightweight transportable case. Though the standard setup is for 2 enclaves, this device can be setup to support a 3rd enclave with the addition of another INE (Inline network encryption) device.

What are the benefits of using a Defender Series kit?

The benefits of using a Defender Series Kit include the following:

  • Supports unstable power sources in the most abstruse locations.
  • Provides SCPS TCP acceleration.
  • Scalable supporting system, configurations on the fly.
  • Adaptable and configurable to support multiple types of Inline Network Encryption (INE) devices.
  • Provides DC power when AC is unavailable, and acts as a UPS when AC power is interrupted.
  • Provides user-friendly onboard web server tools for baseband router management.
  • Natively support power requirements for the KG-250.

Can the Defender support the MissionMobility Dashboard?

Yes, the Defender can support the MissionMobility Dashboard.

What are the typical numbers of users for the Defender kit?

The typical number of users for the Defender kit is 10 to 20 Tactical users.

What are the operating temperatures for the Defender?

The Defender operates in the harshest environments. The Defender will operate in temperatures up to 60°C/140°F and temperatures down to 0°C/32°F.

How many access ports are on the Defender?

NM Module:
7 TCP Accelerated Ports (4 with PoE), 1 routed and 3 Routable VLAN ports

INS Module:
7 TCP Accelerated Ports (4 with PoE), 1 routed and 3 Routable VLAN ports

What is the weight and dimensions of the Defender kit?

The Defender kit weighs 51.6 pounds. The dimensions of the Defender kit are 24″x16″x10″.

Are the devices in the Defender Kit IPv6 compliant?

Yes, the Defender Kit is IPv6 compliant. All the products made at MissionMobility are IPv6 compliant to carry our customers into the future smoothly.

How many access ports are on the Defender-Voice?

NM Module: 7 TCP Accelerated Ports (4 with PoE), 1 routed and 3 Routable VLAN ports
INS Module: 7 TCP Accelerated Ports (4 with PoE), 1 routed and 3 Routable VLAN ports

What is the Defender-Voice?

The Defender “Series” is MissionMobility’s most rugged and scalable baseband communication solutions supporting Everything-Over-IP (EoIP). The Defender “Voice”, a derivative of the Defender Series, provides a simplified approach to the deployment of networking, Voice and IP solutions. The added Voice capabilities support analog telephones to IP conversion at the remote site; providing RJ11 (2-wire) connections, supporting four (4) Standard POTS phones simultaneously to a SIP Phone Switch, CISCO Call Manager, or other 3rd Party VoIP Switch.

What devices are used in a Defender-Voice kit?

The Standard configuration is that of 2 Cisco 32XX based routers with SKIPWARE TCP acceleration. It is divided into 2 sections.

1. NM Module: (Network module) Used for networking and access to an enclave. It can standalone with an external power adapter or can draw power from the INS module
2. INS module (Integrated network module solution) contains all the features of the NM module above with the power requirements needed for internal components as well as external components. This device can also supply regulated power to KG-250 INE devices and houses the VoIP device

Both devices above come in a ruggedized module and are easily transported within a single lightweight transportable case. Though the standard setup is for 2 enclaves, this device can be setup to support a 3rd enclave with the addition of another INE (Inline network encryption) device.

What are the Benefits of using a Defender-Voice Series kit?

1. Supports unstable power sources in the most abstruse locations
2. Provides SCPS TCP acceleration.
3. Maintains up to 4 port solutions (analog to VoIP)
4. Scalable supporting system, configurations on the fly
5. Adaptable and configurable to support multiple types of Inline Network Encryption (INE) devices
6. Provides DC power when AC is unavailable, and acts as a UPS when AC power is interrupted
7. Provides user-friendly onboard web server tools for baseband router management
8. Natively support power requirements for the KG-250

Can the Defender-Voice support the MissionMobility Dashboard?

Yes, the Defender-Voice can support the MissionMobility Dashboard.

What are the typical numbers of users for the Defender-Voice kit?

The typical number of users for the Defender-Voice Kit is 10 to 20 Tactical users.

What are the operating temperatures for the Defender-Voice?

The Defender-Voice operates in the harshest environments. The Defender-Voice will operate in temperatures up to 60°C/140°F and temperatures down to 0°C/32°F.

What is the weight and dimensions of the Defender-Voice kit?

The Defender kit weighs 51.6 pounds. The dimensions of the Defender kit are 24″x16″x10″.

What is the internal Voice option in the Defender-Voice Series?

The Defender-Voice Series uses the Vocality BASICS (Secured) for VoIP communications to the Gateway. This device will support 4 POTS lines to the operators of the kit for use with standard telephones or secure communication devices that use POTS lines. This device is used many times in conjunction with a gateway Vocality to establish communications. It is located within the INS module.

The Vocality can be ordered with the option of either 4 FXS ports to be used with end-devices, 4 FXO ports to be used for connections to POTS lines, or a combination of 2 FXS and 2 FXO lines for versatility.

This allows for the establishment of long local POTS line from anywhere the kit goes.

  • Maintains up to 4 port solutions (analog to VoIP)
  • 2 Wire interfaces (FXS and FXO available)
  • Voice compression as low as 5.3kbps
  • Real time Transport Protocol (RTP) optimization
  • Compatible with CISCO Mobile Access Router or Call Manager

Where has Defender X gone?

The Defender-X is no longer a supported platform.

Mobile IP

What is Mobile IP?

The Mobile IP protocol allows location-independent routing of IP datagrams on the Internet. Each mobile node (Mobile Kit) is identified by its home address disregarding its current location in the Internet. While away from its home network (Gateway), a mobile node is associated with a Collocated care-of address or CCoA (The local IP address assigned to the connecting interface) which identifies its current location and its home address is associated with the local endpoint of a tunnel to its home agent (Gateway Mobile Router). Mobile IP specifies how a mobile node registers with its home agent and how the home agent routes datagrams to the mobile node through the tunnel. In essence, it is a “collapsible Black- core” that can pass the VPN and Encrypted INE traffic across the internet via an authenticated tunnel.

What makes up the components of Mobile IP?

Mobile IP Consists of 3 Main Components

They are:

  1. The Home Agent (HA). This would be the Gateway Mobile IP router to demark the Mobile IP tunnel from the Mobile kits or Clients
  2. The Foreign Agent (FA). In a Static situation the FA would provide the Care-of Address to the Mobile Nore (MN) or Mobile Kit. In the “Mobile Networks” Architecture an FA is not used. Instead a Collocated Care-of-address is used on the attaching interface that will provide a path back to the Gateway HA router.
  3. The Mobile Node (MN). Within our “Mobile Network” architecture, this is the Mobile Kit itself, incorporating Mobile IP (MIP) as well as the SBU enclave.

What are the advantages of Mobile IP verses a traditional VPN from the Mobile Kit to the Gateway?

Security

  1. Single Port & Protocol Alleviates Weaknesses of IPSEC Tunnels: Only a single UDP port (434) needs to transverse the Internet into the Gateway
  2. Quarantined HA/IR Routers
  3. Anti-Spoofing Mechanism
  4. Prevents Re-Play Hacker Attacks
  5. Secure Tunnel Establishment
  6. Randomized Sequence Numbers with Caching
  7. No Split Tunneling

Performance

  1. Tunnel Establishment 500x faster
  2. Automatic tunnel re-establishment without traffic loss
  3. Connect more nodes & more users to the gateway
  4. Significantly decrease occurrence of comms black holes
  5. Enables gateways to communicate leading to faster convergence

Flexibility

  1. Connect up to 16 gateways to each mobile router
  2. Move seamlessly between gateways
  3. Move seamlessly between network mediums (wireless, wired, cellular, satellite)
  4. In-office, desktop experience and access from the field
  5. Proactively manages the WAN mediums using programmed hierarchy

What are the Current Requirements at the Gateway to support Mobile IP Networks and their Mobile IP Clients?

The following is an example of the current offerings by MissionMobility/Cisco that support Mobile Networks and the associated Mobile Kit / Client count

 TIER LEVEL CISCO PRODUCT MOBILE KIT SUPPORT CLIENT/USER SUPPORT
 TIER 1 Cisco 7600 Router Platforms 400 Mobile Kits 5000+ Users
 TIER 2 Cisco 3900 Router Platforms 150 Mobile Kits <1500 Users
 TIER 3 Cisco 2951 Router Platform 25 Mobile Kits <500 Users

What is the overhead involved with running Mobile IP?

One of the many benefits of running Mobile IP is its ability to transport packets from one-site to another without the overhead that is associated with a “Black-core VPN”. In a standard Black-Core VPN, multiple encrypted data streams as well as the non-encrypted traffic flows from one end-point to another, or put simply, from the Mobile kit to the gateway and vice versa.

The connection between the Mobile Kit and Gateway is authenticated. Because of this, only traffic from the mobile kits that have the authorizations can attach to the black core of the Gateway. Unclassified traffic that needs no encryption, but needs to have authentication between the 2 end-points can flow though the Mobile IP tunnel natively. The Sensitive but Unclassified (SBU) traffic such as NIPRNET can flow though the Mobile IP tunnel using the standard IOS AES256 encryption, while Sensitive Enclave Network (SEN) traffic such as SIPRNET can flow through the tunnel under the NSA type-I encryption Inline Network Encryptor device tunnels.

In a best case scenario; instead of the Black-Core VPN overhead of 52 bytes which allow a maximum MTU size of 1448 payload to transport through it, Mobile IP Networks have an overhead of 20 bytes thus decreasing the overhead by more than half that of a traditional VPN black-core architecture whereas the payload size could go up to 1480.

This may not seem like so much to begin with, but factor in having multiple mobile kits accessing the gateway at the same time. Not only does the router have to process the normal packet, but it will also put a strain on the CPU as it has to decrypt/Encrypt packets to and from the gateway.

With Mobile IP, you can increase the amount of data sent at a time due to an increase in the MTU size as well as decrease the CPU usage at both the mobile and Gateway routers.

What MissionMobility Mobile Devices currently support Mobile IP?

The following lineup of MissionMobility products currently supports the use of Mobile IP Networks within their architecture.

  • The WOLFPACK Series
  • The DEFENDER X Series
  • The DEFENDER VOICE Series
  • The SPECTRE Network Module

All Cisco IOS-based router modules running 12.4 or higher can support Mobile IP Networking which allows the existing MissionMobility customer based to incorporate the newer and more flexible networking architecture into the earlier models while. Thus allowing for continuity in architecture while the customer upgrades
equipment as needed due to IA, APL, or command needs.

In times of governmental cut-backs in spending, MissionMobility realizes the needs of our customers to phase in products when they can fund such. When a customer advances to Mobile IP Networking, they can be assured that the current equipment will work with the newer architecture without having to outlay more money than needed which allows the End user to save money and receive all the benefits associated with Mobile IP.

Earlier Line of MissionMobility products (Retired) that can support Mobile IP are as follows:

  • The DEFENDER series
  • The DCD-INS-V3 Series
  • The DCD-INS-V4 Series
  • The DCD-CDR
  • The MCS-V3