Introduction
The 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 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.arindamcctvaccesscontrol.blogspot.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 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.
TCP/UDP Port Forwarding
Normally, traffic initiated from a host site to
a 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.
|