How do I setup IP forwarding/filtering with the Connect Wan?

Introduction

The Digi Connect WAN supports four features which provide security and IP traffic forwarding when using incoming or Mobile Terminated connections:
1. Network Address Translation (NAT)
2. Generic Routing Encapsulation (GRE) forwarding
3. TCP/UDP port forwarding
4. IP Filtering

This document describes each function, how they are used in conjunction with each other, how they are used, and what issues can occur with each if not used properly.

Network Address Translation (NAT)

NAT allows the Digi Connect WAN to have a single public IP address on the mobile link, while allowing multiple private IP addressed devices connected to the Ethernet interface.
Outgoing traffic (mobile initiated) from the private network to the public mobile network assumes the IP address of the public mobile interface. An internal table tracks which internal IP address made the outgoing request so that responses get sent to the proper requestor.

For example, a workstation at IP address 192.168.1.15 sends a request to www.digi.com. The source IP address is changed by the Connect WAN address translation to the public

Incoming (mobile terminated) traffic is either designated to the Connect WAN itself (i.e. HTTP or telnet connections for configuration or monitoring), or is forwarded to hosts via the Ethernet interface based either on GRE or TCP/UDP port forwarding which is covered below.

NAT provides two main benefits:
1. Security: NAT hides the Private IP addresses of the devices on the Connect WAN''''s Ethernet network.
2. IP Address Availability: IP addresses are in short supply and cost money. The Connect WAN need be provided only one IP address from the wireless carrier.

NAT is enabled by default on the Connect WAN. It should not be disabled unless there is a specific reason to do so.

Generic Routing Encapsulation (GRE) forwarding

GRE is a transport layer protocol, designated as IP protocol number 47, is used by many routers, WAN switches and VPN concentrators, to effectively tunnel traffic over a WAN between routers. Note that GRE itself provides no encryption but protocols such as PPTP can use GRE. IPSec can be encapsulated in GRE (and vice-versa). GRE uses IP-in-IP and allows private IP addresses to be tunneled through a public network.

The Connect WAN provides a simple checkbox to turn on GRE forwarding to pass GRE traffic from the mobile interface through to a router on the Ethernet interface. Note the Connect WAN only passes GRE traffic and does not terminate it.

Here is an example diagram:


Figure 1 - GRE Forwarding

The HQ router''''s peer GRE address is the mobile IP address of the Digi Connect WAN, which in this case is 166.213.229.218. The Connect WAN has GRE forwarding enabled and will send to the router''''s Ethernet WAN port, in this case 192.168.1.2. Typically this connection is a directly connected Ethernet cable.

An example similar to the above is where GRE tunneling is used to create a backup WAN connection to a primary Frame Relay connection through the Connect WAN and wireless network. See the Digi Connect WAN application notes on primary and fail-over connection scenarios.

TCP/UDP Port Forwarding

Normally, traffic initiated from a host site to a Digi Connect WAN is blocked by NAT, unless the traffic is destined for the Connect WAN itself. Port forwarding provides a means to pass traffic from the mobile interface to devices connected to the Connect WAN''''s Ethernet port. There are two main applications where port forwarding is required:
1. Pass application data traffic, such as polls or requests, to Ethernet connected devices, and
2. Pass VPN traffic, such as IPSec-in-UDP, through to routers or VPN appliances.

For example, three devices are attached to the Connect WAN''''s Ethernet port:

Figure 2 - TCP Port Forwarding

The application uses a protocol that polls the devices using the device IP address and TCP port 502 (which is Modbus). On local LANs and publicly routable IP addresses this is not a problem.

NAT hides the private Ethernet IP addresses of the devices connected behind the Connect WAN''''s Ethernet port. The application can then only send polls to one IP address the mobile IP in this case 166.213.229.218.

TCP port forwarding is used to forward the IP polls to one or more devices on the Connect WAN Ethernet port. Different TCP port numbers are used to designate which device gets the proper traffic. The application must be able to support changing the TCP protocol port number from the default of 502. In this case the application is configured to poll according to this table:

Notice the destination IP address is the Connect WAN''''s mobile IP address.

The Connect WAN is configured with a TCP/UDP forwarding table as follows:

Incoming traffic is then routed to the proper device. The devices can use their standard TCP port of 502.

The main issue with port forwarding in this case is when the polling application does NOT allow the user to specify the TCP or UDP port used. The workaround is to use routers that support GRE, VPN, or other forms of tunneling that can be forwarded through the Connect WAN.

Another example of port forwarding is forwarding of IPSec-in-UDP traffic to a VPN appliance or router attached to the Connect WAN''''s Ethernet port. Figure 1 above shows a GRE tunnel. In much the same way, IPSec traffic can be encapsulated in UDP to prevent NAT from modifying the IPSec headers (which would invalidate the traffic). IPSec-in-UDP implementations always use UDP port 500 for IKE/ISAKMP, but can use various UDP port numbers for the AH/ESP traffic. Here is an example of UDP port forwarding entries on a Connect WAN for IPSec in UDP:

IP Filtering

IP Filtering is a security feature that allows the user to block all incoming, mobile terminated traffic into the Connect WAN except for traffic from specific IP addresses and/or subnets. There are three IP Filtering settings on the Connect WAN:
1. Only allow access from the following devices and networks. When checked this blocks ALL incoming traffic except for the traffic from the IP address/subnets listed in the "allow access" tables.
2. Automatically allow access from all devices on the local subnet. This allows out-bound traffic from the private Ethernet network out to the mobile network and beyond.
3. Allow access from the following devices and/or subnets. When the "Only allow access from the following devices and networks" box is checked, you must provide entries here to allow in-coming mobile traffic to be passed through the Connect WAN.

CAUTION: Incorrect settings here can stop some or all traffic. For example, checking "Only allow access from the following devices and networks" without adding IP addresses or subnets to the "allow access" tables will block ALL incoming traffic, even responses from outgoing requests.

Furthermore, the Connect WAN is not a stateful firewall. That is, it does maintain a state table of out-going connections. For example, you attempt to open www.digi.com, but the IP address of www.digi.com is not in the "allow access" table. Responses back from www.digi.com are blocked