SSV is a Feature Set of the ePipe that enables secure virtual private networks to be established between ePipes and between an ePipe and another device using the IP Security (IPSec) protocol - an IETF (Internet Engineering Task Force) standard. SSV enables data to be transmitted using the encryption and authentication capabilities of the IPSec protocol between an ePipe and another ePipe, an IPSec gateway or router, or a computer with an IPSec VPN client.
The SSV Feature Set also enables Multilink IP (ML-IP) technology in ePipe, which allows multiple Internet connections to be bonded together (Multilink) to transmit data across a VPN tunnel. This allows more bandwidth to be added to a Site-to-Site VPN tunnel when required and in a cost effective way, without having to upgrade existing Internet access connections. To use ML-IP, an ePipe is required at each end of the tunnel. Multilink IP contains End to End Bonding (E2B) technology which provides the connection bonding for the tunnel. ML-IP is access connection agnostic, meaning that ML-IP will work with any Ethernet or PPP based access connection including dial-up PPP (PSTN and ISDN), ADSL (bridged or routed, with or without PPPoE), and any service that can be connected to the ePipe via an Ethernet connection using a router (including Frame Relay, T1, E1, ATM, leased line, etc.).
SSV is an optional Feature Set in the ePipe 2000 family of Internet access and VPN gateways and is a standard feature of ePipe ServerWare (Concentrator-10, 50, 150 and 500 models).
Special Note:
ePipe 2000 models running versions of firmware later than or equal to version 2.3.0 have the capability of using up to:
|
Standard |
With Activation |
|
|
E2B Client Tunnels |
2 1 |
16 2 |
|
E2B Server Tunnels |
2 1 |
50 2 |
|
IKE IPSec Tunnels |
1 1 |
4 2 |
|
SRA (PPTP) Tunnels |
2 1 |
32 3 |
1 Does not require purchase of an Activation Key as of firmware version 2.3.0. IKE-IPSec tunnels are only supported in ePipe 2200 series units and are not supported in ePipe 2100 series units.
2 Requires an SSV Activation Key.
3 Requires an SRA Activation Key.
The SSV Feature Set in ePipe provides two (2) types of IPSec based VPN tunnels:
IKE-IPSec Site-to-Site VPN
E2B-IPSec Site-to-Site VPN
Before configuring a VPN tunnel between two networks or a network and another IPSec client device, a decision needs to be made as to what type of VPN tunnel is required. The following questions and answers may help when making the decision:
Is the tunnel between two ePipes?
Yes: Use either IKE-IPSec or E2B-IPSec
No: Use IKE-IPSec only
Does the tunnel need scalable bandwidth, use ML-IP (E2B) or require bonding?
Yes: Use E2B-IPSec only
No: Use either IKE-IPSec or E2B-IPSec
Is the tunnel between an ePipe and a third party IPSec compliant router or client?
Yes: Use IKE-IPSec only
Is the use of automated key exchange (i.e. IKE) required?
Yes: Use IKE-IPSec only
No: Use either IKE-IPSec or E2B-IPSec
The SSV Feature Set in ePipe includes the capability for configuring IPSec tunnels that use IKE (Internet Key Exchange) to negotiate the parameters for the tunnel. IKE is an IETF standard that defines how two (2) devices can exchange IPSec parameters so that they may transmit data securely between them. IKE is not used for the transmission of data across the IPSec VPN (tunnel). It merely allows each end of the tunnel to agree on how the end points will establish the IPSec tunnel and transmit data across it. Once the IKE negotiation completes, prior to tunnel establishment, IKE takes no further part in the process. It is the task of IPSec to securely transmit data between the IPSec compliant devices. One exception to the above statement is periodically the keys for the IPSec tunnel are re-negotiated to ensure secure transmission continues. It is the task of IKE to re-negotiate the keys for the IPSec session.
The advantage of using an IPSec tunnel with IKE is IPSec devices from different vendors can create IPSec tunnels between them. It is IKE that performs the exchange of keys and other IPSec parameters that enables the two (2) IPSec devices to establish the tunnel. This means that ePipe can receive and establish IPSec tunnels from/to:
Other IPSec gateways or routers.
IPSec clients that are typically software based and run on a generic operating system like Windows or Linux.
IKE-IPSec tunnels do NOT support ML-IP or E2B. Therefore a tunnel established using an IKE-IPSec tunnel in the ePipe cannot “bond” multiple Internet access connections (links) together to increase the available bandwidth between the two (2) IPSec devices. To use ML-IP (including E2B), an ePipe must be used at each end of the IPSec tunnel.
IPSec (Internet Protocol Security) is the native security protocol from IP Version 6 (IPv6 or IPng), which has been ported to IP Version 4. IPSec was designed to provide secure transmission between any two hosts using the next generation Internet Protocol. IPSec is described in Request For Comment (RFC) 2401.
IPSec provides payload (data) encryption and individual packet authentication to ensure data travelling across a VPN remains confidential and is not tampered with in transit.
A Typical TCP/IP packet on an Ethernet LAN
A TCP/IP packet using IPSec on an Ethernet LAN
IPSec allows the user to select various encryption and authentication algorithms to provide a balance between security and performance. For more information on IPSec, refer to the VPN Technologies section of “Section 5: ePipe Key Networking Concepts” in this manual.
Internet Key Exchange is a protocol, described in RFC 2409, which provides a mechanism for exchanging keys (and other IPSec parameters) between two IPSec capable devices so that an IPSec tunnel can be established between them. IKE automates the key exchange process in order to make VPN configuration simpler, provide interoperability between different vendors IPSec implementations and improve tunnel security by rotating session keys. Without IKE, each IPSec device (or gateway) must already be configured with all the necessary IPSec parameters in order to establish a tunnel. This is usually referred to as “manually keyed” IPSec.
Specifically, IKE is a two (2) phase process that, firstly, negotiates a secure conversation to enable the exchange of IPSec information and then, secondly, exchanges the IPSec information to enable the IPSec tunnel to be created. This IPSec information is referred to as an IPSec SA (Security Association). Therefore, IKE defines the process for the secure exchange of the parameters that make up an IPSec SA. For any given IPSec tunnel, there are two (2) SAs, one for each direction of packet flow.
The first phase of IKE involves a peer authentication step where each IKE peer sends a credential to the other IKE peer. The following credential types can be used:
IP address, or
Fully Qualified Domain Name (FQDN), or
User name and Fully Qualified Domain Name (UFQDN)
In practice, using an IP address as the credential during Phase One of the IKE negotiation limits the IPSec device to having a known or fixed IP address on the Internet. If you intend to connect ePipes or other IPSec devices to the Internet and wish to use a dynamically assigned IP address, then you will not be able to use an IP address as your credential during Phase One of the IKE negotiation. This will also require the IKE devices to negotiate in Aggressive Mode. Aggressive Mode passes some data in the clear during Phase One of the IKE negotiation and is considered less secure than Main Mode (the alternative to Aggressive Mode, which requires fixed IP addresses at both ends of the tunnel).
IKE is the standard mechanism for managing keys for the IPSec protocol. IKE actually uses another protocol called ISAKMP (Internet Security Architecture Key Management Protocol), which was originally designed as a generic key management protocol but currently is most widely used in IKE, to the extent that IKE and ISAKMP have become synonymous.
The first step when building any network or communications system is the network design and planning stage. It is very important that the design is correct and complete before attempting to configure the ePipe(s) so that you understand how the network and VPN needs to be configured.
When connecting IP networks together to create a WAN, each network or subnet must have its own unique network address, which provides sufficient individual IP addresses for the hosts on that network. Individual or ranges of IP addresses may also need to be allocated to any remote IPSec clients, such as home or travelling users. For more information on selecting IP addresses, subnetting or routing see the following sections in the TCP/IP Networking Primer:
Selecting a Network Address
Subnetting a Network
Routing
The TCP/IP Networking Primer is located in Key Networking Concepts of this documentation.
A VPN Tunnel is essentially a virtual point-to-point connection that allows two IPSec capable devices to communicate using TCP/IP. This IPSec tunnel can then be used for secure communication between two computers, a computer and a network, or two networks. Before you can connect these devices together using IKE-IPSec, you will need to already have the following:
Any LANs to be connected by the VPN tunnel need to be configured as separate IP subnets, using different IP network addresses.
Each LAN needs to be connected to the Internet by an ePipe or another router. If using another router then that router will need to be configured to allow the IPSec tunnel through.
Any computer with an IPSec client intending to establish an IPSec tunnel to an ePipe needs to be connected to the Internet.
In general, the following items need to be remembered:
If the ePipe is to receive an IKE negotiation from another IPSec device, it will need to be reachable on the Internet with a known fixed IP address. This typically means the ePipe needs to be directly connected to the Internet with a fixed IP address, or located in a DMZ that uses fixed IP addresses.
IKE uses a credential when attempting to negotiate IPSec parameters with another IPSec device. This credential can be:
the IP address of the computer, gateway or router on the Internet, or
the host name of the computer, gateway or router on the Internet, or
a user name or email address
Using an IP address as the IPSec identifier can be a problem if the IPSec device does not have a fixed IP address on the Internet. In this case, an alternative identifier will need to be selected.
IKE-IPSec tunnel in ePipe cannot be used with ML-IP or E2B. This means that all IPSec traffic from an ePipe to another IPSec device will be transmitted out a single Internet Link, usually the link acting as the default route.
An alternative to establishing an IKE-IPSec tunnel between two ePipes is to use an E2B-IPSec tunnel instead. E2B-IPSec has the advantage of supporting ePipe’s End-to-End Bonding technology, which allows multiple Internet connections to be used for transmission of data across a tunnel. This allows inexpensive connections to be used to obtain greater inter-site bandwidth. E2B cannot be used with IKE-IPSec tunnels.
An IKE-IPSec tunnel between two ePipes allows the two networks behind those ePipes to communicate securely with each other. Traffic that is not destined for the other network will not be processed by IPSec and will be forwarded by the ePipe according to its routing table.
Before configuring the ePipes, please ensure the following:
At least one ePipe will need to have a fixed or static IP address on the Internet. See your ISP or service provider for assistance with obtaining a fixed IP address.
Each network that is being connected to the Internet by the ePipes is using a unique network IP address. For example, if network A is 192.168.1.0/24 and network B is 192.168.2.0/24 then these two networks can be connected using an IPSec tunnel across the Internet. If however network C is 172.16.0.0/16 and network D is 172.16.5.0/24, then these networks cannot be connected via an IPSec tunnel. This is because 172.16.5.0/24 is actually a subset (or subnet) of 172.16.0.0/16.
Each ePipe can ping the other ePipe. This tests that the ePipes are correctly connected to the Internet and can reach each other across the Internet.
Ensure any filters on the ePipe allow both IKE and IPSec packets to be transmitted. This means that IPSec ESP packets (protocol 50) and IKE or ISAKMP packets (UDP packets with a source and destination port of UDP 500) need to be allowed through the filter.
The ePipe can be configured to establish an IKE-IPSec tunnel to another ePipe by using the ePipe Management Assistant. The procedure is:
Start a web browser from a LAN connected PC and browse to the internal IP address of the ePipe.
Select Setup and login as the ‘root’ user when prompted.
Select the SSV Setup Wizard.
Select IKE-IPsec Site-to-Site VPN.
If there are no useable Internet Connection Bundles already configured you will be given a warning. At this point you may configure a Bundle and continue on once the Bundle is configured. However, it is better to select No to cancel the tunnel configuration process and use the SIA Setup Wizard to configure your bundle and then test it first. Once you have a working Internet Connection Bundle, continue on.
Select Peer-to-Peer if each ePipe has a fixed or static IP address on the Internet, as this is more secure. If this ePipe does not have a fixed or static IP address then select Client Side. The other ePipe will then need to be configured with the Server Side option.
Follow the wizard through to the end. Options should be self-explanatory.
For information on each option, refer to the on-line help by clicking
on the help icon on each page. The help icon looks like: 
An IKE-IPSec tunnel can be established between an ePipe and another IPSec router or gateway that supports IKE and pre-shared secrets. Both the ePipe and 3rd party IPSec gateway need to be already connected to the Internet. If you have not connected the ePipe to the Internet then please refer to Section 2 of this manual.
It should be noted that IPSec & IKE are complex protocols, and complete inter-operability between vendors is not guaranteed – it is wise to check on interoperability with a specific product if you intend to connect it with another vendor’s.
ePipe supports E2B (End-to-End Bonding) which is part of the ePipe’s ML-IP (Multilink IP) functionality. E2B bonds together multiple Internet links for the transmission of traffic across E2B-based IPSec tunnels. However, E2B only works when tunnelling between two (2) ePipes, not when tunnelling between ePipe and a 3rd party IPSec gateway, as the third party device will not implement E2B.
An IKE-IPSec tunnel between an ePipe and a 3rd party IPSec gateway allows the two networks behind the ePipe and gateway to communicate securely with each other. Traffic that is not destined for the other network will not be processed by IPSec and will be forwarded by the ePipe or gateway according to its routing table.
Before configuring the ePipe or IPSec gateway, please ensure:
The ePipe(s) and/or IPSec gateway(s) will need to have a fixed or static IP address on their Internet connections. This will depend partly on the type of IKE negotiation that is configured however, in general, IKE is easier to configure and make work when both ePipe and the other IPSec gateway have fixed or static IP addresses on the Internet. See your ISP or service provider for assistance with obtaining a fixed IP address. The exception is where the ePipe is configured to establish the IPSec tunnel to the 3rd party IPSec gateway using IKE in aggressive mode, using a credential other than the IP address of the ePipe.
Each internal private network that is being connected to the Internet by the ePipe or 3rd party IPSec gateway needs to use a unique network IP address. For example, if network A is 192.168.1.0/24 and network B is 192.168.2.0/24 then these two networks can be connected using an IPSec tunnel across the Internet. If however network C is 172.16.0.0/16 and network D is 172.16.5.0/24, then these networks cannot be connected via an IPSec tunnel. This is because 172.16.5.0/24 is actually a subset (or subnet) of 172.16.0.0/16.
The ePipe can ping the external interface (IP address) of the 3rd party IPSec gateway or vice versa. This tests that both devices are correctly connected to the Internet and can reach each other across the Internet.
Ensure any filters on the ePipe allow both IKE and IPSec packets to be transmitted. This means that IPSec ESP packets (protocol 50) and IKE or ISAKMP packets (UDP packets with a source and destination port of 500) need to be allowed through the filter. Similarly, ensure any firewall capability in or in front of the 3rd party IPSec gateway allows these types of packet through without modification.
The ePipe can be configured to establish an IKE-IPSec tunnel to a 3rd party IPSec gateway by using the ePipe Management Assistant. The procedure is:
Start a web browser from a LAN connected PC and browse to the internal IP address of the ePipe.
Select Setup and login as the ‘root’ user when prompted.
Select the SSV Setup Wizard.
Select IKE-IPsec Site-to-Site VPN.
If there are no useable Internet Connection Bundles already configured you will be given a warning. At this point you may configure a Bundle and continue on once the Bundle is configured. However, it is better to select No to cancel the tunnel configuration process and use the SIA Setup Wizard to configure your bundle as this then allows the connection to be tested first. Once you have a working Internet Connection Bundle, continue on.
Select Peer-to-Peer if both devices have a fixed or static IP address on the Internet, as this is more secure. If this ePipe does not have a fixed or static IP address then select Client Side; the 3rd party IPSec gateway will then need to be configured to allow IKE aggressive mode negotiations. Usually Peer-to-Peer works more easily with other IPSec gateways and is the preferred option.
Follow the wizard through to the end. Options should be self-explanatory. For information on each option, refer to the on-line help by clicking on the help icon on each page. The help icon looks like:
Local and Remote Address fields are used to determine which packets are to be processed by this IPSec tunnel and, therefore, encrypted and forwarded to the other ePipe. These addresses can be network addresses or host addresses. These addresses will need to match (in reverse) the equivalent parameters on the 3rd party IPSec gateway.
The shared secret needs to be at least 80 characters in length to be considered secure. Choosing a shared secret may also depend on any restrictions imposed on you by the 3rd party IPSec gateway.
On the Cryptographic Algorithms page, select the matching 3rd party IPSec gateway from the list of suitable peer algorithms, unless you wish to use a specific custom set of algorithms. If selecting a custom set of algorithms, ensure the 3rd party IPSec gateway supports the algorithms selected.
Remember to allow IPSec (ESP) and IKE (ISAKMP) through the ePipe’s filter/s and any other firewalls.
The IPSec gateway needs to be configured in either IKE Main Mode or IKE Aggressive Mode depending on how the ePipe was configured. See the table below.
| ePipe IKE-IPSec Tunnel Type | 3rd Party IPSec Gateway Equivalent |
| Peer-to-Peer | IKE (ISAKMP) Main Mode |
| Client Side | IKE (ISAKMP) Aggressive Mode; ePipe establishes tunnel |
| Server Side | IKE (ISAKMP) Aggressive Mode; ePipe accepts tunnel |
For more information on configuring the 3rd party IPSec gateway, refer to the documentation for that gateway.
An IKE-IPSec tunnel can be established between an IPSec software client and an ePipe, if the client supports IKE and pre-shared secrets. Both the ePipe and 3rd party IPSec client need to be already connected to the Internet. If you have not connected the ePipe to the Internet then please refer to Section 2 of this manual.
ePipe supports E2B (End-to-End Bonding), which is part of the ePipe’s ML-IP (Multilink IP) functionality. E2B bonds together multiple Internet links for the transmission of traffic across E2B-based IPSec tunnels. However, E2B only works when tunnelling between two (2) ePipes, not when tunnelling between ePipe and a 3rd party IPSec client.
An IKE-IPSec tunnel between an ePipe and a 3rd party IPSec client allows the client to communicate securely with the network behind the ePipe. This provides remote access to a corporate network for remote users that may be on the road or at home.
Software based IPSec clients are available for many operating systems including (to name a few):
Before configuring the ePipe or IPSec client, please ensure:
The ePipe can accept an IKE-IPSec tunnel from a 3rd party IPSec client by configuring the ePipe using the ePipe Management Assistant. The procedure is:
Local and Remote Address fields are used to determine which packets are to be processed by this IPSec tunnel and, therefore, encrypted and forwarded to the other ePipe. These addresses can be network addresses or host addresses. For remote IPSec clients (that are not routing packets from a private network across the tunnel) all traffic to the Internet IP address of the client and from the network behind the ePipe needs to be encrypted. Therefore, the ePipe local address will be the address of the LAN behind the ePipe and the ePipe remote address will be 0.0.0.0 with a subnet mask of 0.0.0.0.
The shared secret needs to be at least 80 characters in length to be considered secure. Choosing a shared secret may also depend on any restrictions imposed on you by the 3rd party IPSec client.
On the Cryptographic Algorithms page, select the matching 3rd party IPSec client from the list of suitable peer algorithms, unless you wish to use a specific custom set of algorithms or if the IPSec client being used is not listed. If selecting a custom set of algorithms, ensure the 3rd party IPSec gateway supports the algorithms selected.
Remember to allow IPSec (ESP) and IKE (ISAKMP) through the ePipe’s filter/s and any firewall running on the client computer.
The IPSec client needs to be configured in either IKE Main Mode or IKE Aggressive Mode depending on how the ePipe was configured. See the table below.
| ePipe IKE-IPSec Tunnel Type | 3rd Party IPSec Gateway Equivalent |
| Peer-to-Peer | IKE (ISAKMP) Main Mode |
| Client Side | IKE (ISAKMP) Aggressive Mode; ePipe establishes tunnel |
| Server Side | IKE (ISAKMP) Aggressive Mode; ePipe accepts tunnel |
For more information on configuring the 3rd party IPSec client, refer to the documentation for that client.
An IPSec tunnel can be established between many different IPSec routers and gateways in many different network configurations. It is not uncommon for an IPSec gateway to be dedicated to providing IPSec tunnels, with or without firewall capabilities, while Internet access is provided by a separate router. Therefore, it is possible to locate devices that do some form of firewall function between the IPSec gateway and the Internet. This can cause the IPSec tunnel to fail as the firewall may modify the packets as they pass through the firewall, which causes IPSec authentication to fail when the packet is received by the IPSec device at the other end of the tunnel.
It is not normally recommended to place a firewall or other device that does NAT (Network Address Translation) or IP masquerading between an IPSec device and the Internet, thereby placing the firewall or NAT device between the two IPSec gateways.
To view the characteristics of the IKE-IPSec tunnels configured in the ePipe, use the ePipe Management Assistant to view the configuration of each tunnel. A summary of all configured IPSec tunnels (both E2B-IPSec and IKE-IPSec) is available by browsing to Advanced > VPN. Clicking on the plus (+) will allow individual tunnels to be seen in more detail. Tunnels can then be modified by simply clicking on the tunnel name. This will allow you to enter the tunnel configuration wizard for that tunnel.
To confirm if the IKE-IPSec tunnel is connected, use one of the following methods:
The basic characteristics of an IKE-IPSec tunnel can be seen by executing the following command from the CLI:
SHOW INTERNET IKE CHARACTERISTICS
Viewing the Full IKE-IPSec Tunnel Configuration
The complete configuration of an IKE-IPSec tunnel can be viewed by executing a special command as a URL in a web browser. Simply start a web browser and type the following into the address or URL of the browser window:
http://<ip_address_of_epipe>/ike_backup.cgi
For example:
http://192.168.1.1/ike_backup.cgi
An example output follows:
Backing up IKE-IPSec configurations is done separately to the rest of an ePipe configuration by browsing to a specific location on the ePipe’s web server. If you open a web browser, and go to a file on the ePipe named “ike_backup.cgi” (go to the address bar of your web browser and type “http://ip_address_of_epipe/ike_backup.cgi”), you will see the full configuration of any IKE-IPSec tunnels defined in the ePipe, as seen in “Viewing the Full IKE-IPSec Tunnel Configuration” in the “Monitoring IKE-IPSec Tunnels” chapter of this document. This text, if saved to a file, can later be used to restore the complete IKE config of the box.
It is important to note that the configuration of any IKE-IPSec tunnels are not stored in the same way as the rest of the ePipe configuration, and so will not be backed up by using the ePipe backup tool ‘eConfig’ or by saving the output of a LIST CHANGES command. As VPN configuration can be time consuming and involve secrets, it is particularly important to keep it backed up.
Currently, in order to restore a saved configuration, a relatively complex process must be followed. If this becomes necessary, please contact ePipe Technical Support.
The main troubleshooting tool in the ePipe for IKE-IPSec connections is syslog – this tool is accessed through the main ePipe syslog facility, and the level of logging is set firstly through that facility, and secondly through the IKE-IPSec configuration.
To set up IKE syslog, firstly set the level of logging desired in the normal fashion, using a command of the form:
CHANGE SERVER SYSLOG IKE level
Where ‘level’ is either NONE, SUMMARY, DETAIL, or DEBUG. NONE turns off IKE syslog, SUMMARY records major events, DETAIL provides in depth information, and DEBUG should typically only be used under direction from ePipe Technical Support, as it can seriously reduce the performance of an ePipe. IKE syslog is different to the other types of syslog in the ePipe, in that the level of DEBUG logging can be set more finely by using the command:
CHANGE INTERNET IKE DEBUG number
Where ‘number’ is a number from 10 to 100. Setting this to 10 will allow a fairly minimal amount of syslog output. As the value increases, so does the amount of syslog output, through to a maximum of 100. This allows the use of debug syslog for troubleshooting IKE-IPSec tunnels by allowing the user to set the level so that there is enough information to solve the problem without overwhelming the user or the ePipe with extra information. A good level to start at is 40.
IKE syslog is quite cryptic, and can be difficult to interpret, due to the complex nature of the algorithm. Important things to look for in it include the completion of phase 1 and phase 2 negotiations, or any accepted proposals. If the problem is not immediately obvious after inspection of the output log, it may be necessary to refer the matter to ePipe Technical support.
Filter syslog can be useful for troubleshooting IKE-IPSec tunnels as, although not directly related to the process, it can show useful information about what is being sent between the VPN devices. If set to SUMMARY, FILTER syslog will log information about any packets which are dropped by the filter, and if set to DETAIL, it will log information about any packets passing through the filter. This will reveal whether any packets necessary for VPN creation are reaching the ePipe, and whether they are being allowed through the filter. It is also useful to confirm that packets that should be sent over the VPN are being sent that way, rather than simply being routed in the clear.
To see filter syslog, run the command:
CHANGE SERVER SYSLOG FILTER level
Where ’level’ is one of SUMMARY or DETAIL, and then enter the command:
WATCHLOG
You should then see syslog output in the command line session. This will continue until you hit <Enter> to stop the watchlog session.
The routing table in the ePipe shows any IPSec flows in effect at the bottom of the table, and can be seen by running the command:
SHOW INTERNET GATEWAY
This is useful for confirming that the routing information for the tunnel is correct, and also serves as an indicator that the tunnel is connected.
Connecting two (or more) networks together using SSV tunnels is no different from building any other wide area network: it all becomes a matter of routing. Therefore, every PC, server or other device will need to know where to send packets when they need to travel to a remote LAN. Typically this involves configuring each device with a default route or default gateway. In general terms, every host on an IP WAN must know the IP address of a router with more “knowledge of the WAN” than themselves. In practical terms this means the default gateway needs to be set to the IP address of a router on the local LAN that knows how to forward packets to their destinations. In smaller networks, this router would be the local ePipe, where as in larger networks this router may be the ePipe or some other device.
If your hosts run an operating system that supports RIP (Routing Information Protocol), such as Windows NT/2000 or UNIX, then the host will learn about network routes by the RIP broadcasts from the ePipes. Consult your operating system documentation for more information on installing and configuring RIP.
The Site-to-Site VPN (SSV) Feature Set allows multiple ePipes to establish IPSec-based Virtual Private Networks (VPNs) between each other, forming secure virtual wide area networks across the Internet or other public network. The E2B-IPSec Site-to-Site VPN allows ePipe to create these tunnels with scalable bandwidth by bonding multiple low-cost lines together using ePipe’s End-to-End Bonding (E2B) technology.
The E2B technology of the ePipe enables a “bundle” of modems or other links to be used as a single connection for the transmission of the VPN traffic. For more information on configuring bundles see SIA (Shared Internet Access). All links in the bundle will automatically be used by E2B for tunnelled packets.
IPSec (Internet Protocol Security) is the native security protocol from IP Version 6 (IPv6 or IPng), which has been ported to IP Version 4. IPSec was designed to provide secure transmission between any two hosts using the next generation Internet Protocol. IPSec is described in Request For Comment (RFC) 2401.
IPSec provides payload (data) encryption and individual packet authentication to ensure data travelling across a VPN remains confidential and is not tampered with in transit.
A Typical TCP/IP packet on an Ethernet LAN
A TCP/IP packet using IPSec on an Ethernet LAN
IPSec allows the user to select various encryption and authentication algorithms to provide a balance between security and performance. For more information on IPSec, refer to the VPN Technologies section of “Section 5: ePipe Key Networking Concepts” in this manual.
End-to-End Bonding (E2B) allows multiple Internet links to be bonded together so that data traffic between two networks can be split up over the available links. This allows the available bandwidth between sites to be increased without having to move to a more expensive access technology. For example, you could use three 56k analogue modems at each site to connect each LAN to the Internet and E2B would allow you to have up to 3 x 56 = 168k between the sites. This is typically less expensive than using ISDN or other access technologies.
When using multiple links in a bundle for a Site-to-Site VPN, the following should be considered:
E2B tunnels are based on a client-server model where one ePipe is the client end of the tunnel (this ePipe establishes the tunnel) while the other is the server end of the tunnel (this ePipe listens for the tunnel connection). The ePipe designated the server end of the tunnel needs a fixed or permanent IP address on the Internet. Permanent IP addresses can be obtained from your ISP (Internet Service Provider).
It is the client end of the tunnel that determines how many links in a bundle can be used for bonding of links to increase the end-to-end available bandwidth for the tunnel. The client will not bond to more links than it has itself. For example, if the bundle at the client end of the tunnel has 3 links and the server end has 5 links, only 3 links at the server end will be used for the E2B tunnel. The other links in the bundle at the server end of the tunnel may, of course, be used with I2B for Internet access. This is illustrated in the diagram below.
If you are connecting many sites to one site, it is recommended the main site have a single high speed Internet connection of sufficient bandwidth to handle all the other sites simultaneously. The remote sites can use multiple physical links bonded together using E2B.
Each ePipe can use different types of links. For example, the head office may have a 1.5 Mbps ADSL link while the remote sites may use multiple 56k analogue modems or ISDN modems (terminal adapters or TAs).
The first step when building any network is the network design and planning stage. It is very important that the design is correct and complete before attempting to configure the ePipe(s) so that you understand how the network and VPN needs to be configured.
When connecting IP networks together to create a WAN, each network or subnet must have its own unique network address, which provides sufficient individual IP addresses for that network. For more information on selecting IP addresses, subnetting or routing see the following sections in the TCP/IP Networking Primer:
Selecting a Network Address
Subnetting a Network
Routing
A VPN Tunnel is essentially a virtual point-to-point connection that allows two separate LANs to communicate using TCP/IP. As such, the tunnel is simply a connection between LANs that has IP addresses so that packets can be routed through it. Before you can connect two networks together using E2B-IPSEC, you will need to already have the following:
The LANs to be connected by the VPN tunnel need to be configured as separate IP subnets, using different IP network addresses.
Each LAN needs to be connected to the Internet by an ePipe or another router. If using another router then that router will need to be configured to allow the tunnel through.
In general, the following items need to be remembered:
The ePipe at the “Server” end of the tunnel is the ePipe that needs a fixed or permanent IP address on an Internet link. One of the links in the bundle selected for the VPN tunnel needs to be configured to use this fixed IP address. See the SIA chapter for more information on configuring links and bundles.
E2B will use all links in the bundle that you select for the VPN traffic. Note that this bundle may also be used for Internet access. If you do not want to share the available bandwidth of the bundle with Internet traffic (such as web browsing) then you may want to create a new bundle made of new links.
The tunnel is a point-to-point link between the ePipes and needs to be allocated IP addresses at each end. These addresses are configured at the server end of the tunnel and are allocated to the end points of the tunnel when the tunnel is established. These addresses must not match any addresses used elsewhere in your network.
If you are connecting more than two networks together then consideration should be given to which sites will need fixed IP addresses and which do not. One approach to use is to base your VPN design on a star with the head office or major offices at the centre of the star and the satellite offices at the edge. In this way you can minimize the number of offices that require fixed IP address connections to the Internet.
ePipe has created a network design template which will assist you in designing your VPN. Click here to open the ePipe SSV Design Template (PDF - 22 kb). This template is a simple two LAN network with the LANs being connected together using a VPN tunnel. This template assumes you are using the ePipes to connect the LANs to the Internet.
ePipe has also created a basic worksheet to assist in the setup of the ePipes when using the ePipe’s E2B-IPSec setup wizard (in SSV Setup). Click Here to open the ePipe SSV Worksheet (PDF - 19kB). Both worksheets are suitable for printing and can be copied when doing several network configurations. Complete the ePipe SSV Design Template first and then complete the ePipe SSV Worksheet, transferring any appropriate information from the design template to the worksheet. The worksheet can be used when completing the configuration of the ePipes at both ends of the tunnel.
The best way to explain the process of designing a WAN that connects two networks using an ePipe based VPN is by using an example. Let us suppose you have two sites, one a head office and the other a remote site and you are already using ePipes at both sites to provide local Internet access for the users on each LAN. Let us also assume that the head office uses the IP network 192.168.1.0/24 (meaning network 192.168.1.0 with subnet mask 255.255.255.0, where the 24 is the number of subnet bits in the subnet mask) and the remote office uses the IP network 192.168.2.0/24. The diagram below illustrates this scenario and shows the proposed IPSec-based tunnel that will connect these two LANs together using the existing Internet connection for the transmission of the tunnel traffic.
In this example, the head office will need at least one link (one of the modem links) with a fixed IP address so that the ePipe 2181 at the head office can be configured as the server end of the tunnel. The client end of the tunnel at the remote office does not need a fixed IP address.
The tunnel end points were allocated addresses from the 192.168.254.0/24 subnet as this subnet was not already in use.
If you are designing a WAN, connecting many LANs together so that any host on any LAN can communicate with any host on any other LAN, there are two ways of approaching the design:
Connect the LANs using a star or hierarchical topology, where large LANs become the hubs that smaller LANs connect to.
Connect the LANs in a fully meshed topology, where every LAN is connected to every other LAN.
The diagram below illustrates the two different approaches to inter-connecting networks .
The first approach, using a star or hierarchical topology, is the one usually adopted in most designs as it usually matches the paths of communication within an organization and frequently suites the geographical location of the LANs as well. It is unusual to adopt a fully meshed approach as the number of inter-connections is very large and the network becomes increasingly more complex as the number of networks increases. These two approaches can be combined so that some meshing can be achieved to provide redundant paths in your network to increase fault tolerance.
Whichever approach is used, the WAN is a series of LANs inter-connected by VPN tunnels using ePipes. Each tunnel is simply designed as in the section above, however the following points need to be considered:
ePipes running 1.0.9 firmware support up to 64 server side tunnels and up to 16 client side tunnels per ePipe. This assumes you have enough configuration memory in the ePipe to support that number of tunnels (this depends on what other configuration is stored in the ePipe).
ePipes running 2.3.x firmware support up to 50 server side E2B tunnels, 16 client side E2B tunnels and 4 IKE IPSec tunnels per ePipe (with full activation) or 2 server side E2B tunnels, 2 client side E2B tunnels and 1 IKE IPSec tunnel (with partial activation).
All ePipes configured as the server end of a tunnel will need a fixed IP address.
ePipes that are using a single bundle for more than one tunnel will share the bandwidth of the bundle amongst the tunnels using that bundle as well as any non-VPN Internet traffic.
All ePipes in the WAN will need to have unique tunnel IP addresses and unique SPI (Security Parameters Index) values.
Creating a VPN tunnel using ePipe is basically a 4 step process:
Select the Bundle the VPN Tunnel will use
Configure the VPN Tunnel details
Configure any routes to remote networks
Configure the VPN Tunnel IPSec settings
The ePipe SSV Worksheet (discussed above) is divided into these four sections, as is the E2B-IPSEC Setup Wizard (in SSV Setup) to assist you in completing the tunnel setup process.
Before starting the E2B-IPSEC setup wizard you will need to have done the following:
Connected your ePipe to the Internet or created the Internet connection bundle to be used by the tunnel. If you are using a traffic filter on the bundle, ensure you allow E2B (TCP Port 2000) through. Allow the tunnel “out of the internal network” at the client end of the tunnel and “into the internal network” at the server end of the tunnel.
Decided whether this ePipe will be the server or client end of the tunnel. The server end requires a fixed IP address so this may be the determining factor.
Completed the SSV Design Template and ePipe SSV Worksheet. This will make the setup easier for those unfamiliar with ePipe and/or network design.
To configure a VPN tunnel, follow these steps:
Start a JavaScript enabled web browser (such as Microsoft Internet Explorer or Netscape Navigator) and browse to the IP address of the ePipe.
Select the Setup option. You will be presented
with the Setup page, which will list the ePipe Feature Sets. Confirm that
the SSV Feature Set has been activated by the presence of the Activated
icon ( 
)
to the left of the SSV Feature Set. If the SSV Feature Set has not been
activated, click on the Inactive icon ( 
)
to the left of the SSV Feature Set for information on how to obtain an
Activation Key.
Click on the Setup Wizard link, to the right of the SSV Feature Set.
Click on the E2B-IPsec Site-to-Site VPN option to start the configuration of the tunnel.
Follow the prompts to complete the configuration of
the tunnel. If you need assistance at any time, click on the information
or help button, which is located at the top right of each page and looks
like:
At the end of the wizard you will be asked to confirm the bundle you wish to use for this tunnel and whether you would like to start the VPN tunnel now or later. If you are configuring the server end of a tunnel then it is best to select Start VPN Now. If you are configuring the client end of a tunnel then select Start VPN Now (if the server end is ready to receive the tunnel connection). If not, select Start VPN Later.
Repeat this process on the ePipe at the other end of the tunnel.
E2B tunnels, by default, use a TCP transport with the client end of the tunnel establishing a TCP connection to TCP port 2000 on the server end. The TCP port the client end connects to can be changed in the SSV Setup Wizard however the TCP port the server end listens on is configured separately. See below for further details.
Unless there is a good reason for changing the E2B fragment length, it should be left at the default value of 800 bytes.
The VPN Group Name option is used as a way of visually grouping tunnels together on the Advanced > Summary page of the ePipe Management Assistant. This field is not required.
Although it is not mandatory to configure network addresses of the networks reachable across the VPN, it is recommended.
SPIs (Security Parameters Index) values assist in the identification of IPSec tunnels and should be unique across all tunnels configured in the ePipe.
Encryption and Authentication keys can be entered as a plain text phrase (e.g. “The cow jumped over the moon”) or as a hexadecimal string (e.g. “0x1234567890ABCDEF”, the “0x” indicates that the string is in hex).
If you are using a traffic filter on the bundle, ensure you allow E2B (TCP Port 2000) through. Allow the tunnel “out of the internal network” at the client end of the tunnel and “into the internal network” at the server end of the tunnel.
IPSec provides a security framework for encrypting and authenticating data streams using industry standard protocols. The ePipe provides several options for the IPSec tunnel authentication and encryption protocols including:
|
Protocol Type |
Protocols supported in ePipe for E2B |
| Authentication | SHA1, MD5, RMD160 |
| Encryption | DES (56 bit), 3DES (168 bit), Blowfish (128 bit), AES (128 bit) |
Currently, SHA1 is the strongest of the authentication protocols and is recommended in preference to RMD160. MD5 authentication is more efficient than SHA1 and nearly as strong.
DES (Data Encryption Standard) is one of the world’s most widely used encryption protocols, while 3DES is a 3-way DES encryption of the same data providing even greater strength. Blowfish is an encryption protocol that grew out of the open source community and is widely used in Linux and BSD operating systems. It is also very strong and has the advantage of being computationally efficient. AES (Advanced Encryption Standard) is also available in ePipe models with firmware version 2.0 or higher. AES (or Rijndael) is the cryptographically strongest encryption algorithm supported by ePipe and has the additional advantage of being computationally efficient; more efficient than 3DES but not quite as efficient as Blowfish.
When selecting an encryption protocol, a balance is usually found between cryptographic strength and performance. So for maximum security use AES or 3DES encryption, but for greater throughput with strong encryption select Blowfish.
The cryptographic strength of any IPSec VPN depends heavily on the quality of the keys (passwords) being used to authenticate and encrypt the data. When selecting keys, the following should be remembered:
The keys need to be kept secret as they form the basis of the encryption. Treat them like a password.
Each key should be different and unique. Do not use keys that could be guessed.
Keys need to be as long as possible, using as many different characters and numbers as possible. The best keys are made up of characters selected completely at random.
The table below shows the minimum recommended key lengths for each encryption protocol.
| Encryption Protocol | Minimum Key Length (characters) | Minimum Key Length (hex digits) |
| DES | 35 | 16 |
| Blowfish | 80 | 32 |
| 3DES | 105 | 48 |
| AES | 80 | 32 |
ePipe, by default, establishes tunnels using a TCP transport by establishing a TCP connection from an ePipe E2B client to an ePipe E2B server. The TCP port that is used on the server end is TCP port 2000. This can be changed to any user selectable port by following the steps below:
Browse to the ePipe’s IP address to access the ePipe Management Assistant.
Click on the Setup option, then click on the SSV Setup Wizard.
Click on Advanced E2B Settings.
Change the E2B TCP/UDP Server Port Number to the value you wish to use. The value should be greater than or equal to 1024 as TCP/UDP port numbers less than 1024 are reserved for well known services. Click on Configure when finished.
Click on OK on the confirmation page. This completes the port change.
E2B-IPSec Tunnels are connected and disconnected using the same mechanisms as Links and Bundles. That is, an E2B-IPSec tunnel is controlled by a bundle that uses a virtual link with the same name as the tunnel. One of the easiest ways to see if a tunnel is connected is to monitor the status of the bundles (and their associated links).
To monitor the status of the tunnel you can use the following options in the ePipe Management Assistant (via the web browser):
Status > Raw Stats > SSV (E2B)
This will show the current state of all configured tunnels. Information
displayed includes the tunnel name, mode (client or server), VPN status
(OPENED or CLOSED) and LM (Link Manager) Status. When a tunnel is established,
both the VPN and LM status show OPENED.
Status > Raw Stats > Bundles
This will show the current list of bundles and their links (numbered beneath
each bundle) and whether the bundle and link(s) are connected, idle or
disabled. Other information displayed includes the number of retries (attempts
to connect), link/bundle up time, TTL (Time to Live, indicating the time
before dial-on-demand disconnects a link), the average received characters
(bytes) per second (RxAvCps), the average transmitted characters (bytes)
per second (TxAvCps) and the nominal bandwidth of the link. Each Tunnel
will have a bundle and link named after it. A status of “Connected” indicates
the tunnel is established.
More status information can be obtained from the ePipe CLI (Command Line Interface). The CLI can be accessed by logging into the ePipe from the console port or via a telnet session. You will need to know the root or privileged mode password to login. The following commands can be used to obtain status information on all E2B-IPSec tunnels:
SHOW INTERNET E2B ALL STATUS
SHOW INTERNET E2B ALL CHARACTERISTICS
To see tunnel specific information, use the following commands:
SHOW INTERNET E2B “name_of_tunnel” STATUS
SHOW INTERNET E2B “name_of_tunnel” CHARACTERISTICS
Where “name_of_tunnel” is the name of the specific tunnel.
To see the status of the links and bundles, use the command:
SHOW INTERNET DOD ALL STATUS
SET SERVER MONITOR TIMER n
Where N is the time in seconds. This timer also controls the refresh interval for the status commands in the ePipe Management Assistant.
There are situations where the tunnel that connects two networks together is not terminated at the Internet access router at one or both ends of the tunnel. In these cases, there may be an existing Internet router providing Internet access or a DMZ (De-Militarised Zone) network for external web or other servers. In both cases, when creating a VPN tunnel between two ePipes (and, therefore, between two networks) the critical issue in making it work is considering where your NAT (Network Address Translation) or IP Masquerading boundaries lie.
The first thing to note is what type of transport is being used by IPSec to carry the tunnelled data. ePipe supports ESP (Encapsulated Security Payload) with E2B. ESP is one of the methods defined by the IPSec standard for tunnelling data across public networks. ESP can work by transporting the data across TCP or by encapsulating the data directly over IP. The ePipe, by default, uses TCP encapsulation as this is usually the only way to tunnel through firewalls and routers. Thus, the ePipe at the server end of the tunnel makes a TCP connection to the ePipe at the server end of the tunnel on the default TCP port of 2000. The ePipe at the server end of the tunnel listens for this TCP connection on port 2000. If you have packet-filtering routers, firewalls or proxy servers between the ePipes at each end of the tunnel, then you may need to configure these devices to enable the TCP connection to become established.
NAT or IP Masquerading, makes all packets being transmitted from a private network to a public network appear as if they come from the IP address of the NAT or IP Masquerading device. This allows the private network to have private IP addresses (non-routable on the Internet) and increases the security of the private network. If the NAT device is placed between the ePipe and the Internet then the tunnel packets will appear to be from the NAT device. This is not a problem for the client side of an E2B-IPSec tunnel as the client end of the tunnel makes the tunnel connection out through NAT, and NAT handles this dynamically. However, at the server side, if the ePipe is located behind a NAT or IP Masquerading device, the device will need to forward the packets to the other ePipe or emulate this on some other way.
These two situations are explored below by looking at what needs to be done to allow the tunnel through NAT or a firewall.
If you are using ePipe to connect a private LAN to the Internet directly or to a DMZ network that is reachable from the Internet, then no special configuration of the ePipes is required. If another router is used to connect the DMZ to the Internet (see the diagram below) and the DMZ uses real IP addresses then the only possible problem for tunnel establishment is the router. (Note that in this scenario, the ePipe needs to do NAT as it is connecting public and private networks.)
If the router is doing packet filtering or limiting traffic flow for security reasons then it must be configured to allow a TCP connection to the ePipe on port 2000 from the remote ePipe. You will need to consult your router’s documentation for information on how to do this.
NOTE: The remote ePipe (at the client end of the tunnel) needs to know the “Fixed IP address” to which it will establish the E2B-IPSec tunnel. In this case the ePipe at the server end of the tunnel is directly reachable at a real Internet IP address so this address should be used when configuring the client end of the tunnel.
If you already have a router/firewall that is protecting your LAN from the Internet and simply want to allow the E2B-IPSec tunnel TCP connection from the remote ePipe through your router/firewall then the ePipe at the server end can be placed directly on your internal LAN. This is sometimes referred as a “one-armed ePipe”, indicating that the ePipe’s only connection is to the internal LAN. This situation is described in the diagram below.
In this situation, the client end of the tunnel cannot directly “see” the server ePipe as it is located on a Private LAN. To make this work the router/firewall needs to be configured to do one of two things:
Configure the router/firewall to forward packets arriving on TCP port 2000 to the internal IP address of the ePipe. If the router/firewall is using NAT to hide the IP address of the LAN from the Internet then this is called NAT port redirection or PAT (Port Address Translation).
If the router/firewall is designed to work like a proxy server, then it will need to be configured to “relay” the incoming TCP connection on port 2000 to the ePipe’s internal IP address on the LAN. A “relay” is actually two TCP connections; one from the remote ePipe to the router/firewall and the second from the router/firewall to the ePipe inside the LAN.
Consult the documentation of your router or firewall for information on how to achieve these options. Typically, option 1 is used with routers using NAT and option 2 is used with firewalls based on a proxy server.
The remote ePipe (at the client end of the tunnel) needs to know the “Fixed IP address” to which it will establish the E2B-IPSec tunnel. In this case the ePipe at the server end of the tunnel is not directly reachable at a real Internet IP address as it is on a private LAN. The router/firewall used to connect the LAN to the Internet is the only reachable device and, as it is forwarding or relaying the tunnel packets, the ePipe at the client end will need to have its “Fixed IP Address” in the tunnel configuration set to the external IP address of the router/firewall.
The ePipe located behind the router/firewall will need to have a route configured to forward the tunnelled packets to the other ePipe. This is usually achieved by setting a default gateway in the ePipe configured to be the internal address of the router/firewall. To do this, login to the ePipe using the console port or a via telnet and execute the following command:
CHANGE INTERNET GATEWAY a.b.c.d NETWORK ANY
Where a.b.c.d is the internal IP address of the router/firewall connecting the LAN to the Internet.
For example:
CHANGE INTERNET GATEWAY 192.168.1.1 NETWORK ANY
Where 192.168.1.1 is the internal IP address of the router/firewall.
Most tunnel connection problems are due to configuration errors. When a tunnel is not connecting, the bundle status will not show the bundle status as “Connected” and the E2B-IPSec status will be “CLOSED”. Common configuration problems are listed below:
1. Ensure the tunnel name used at each end of the tunnel is the same.
2. The local and remote IP addresses used at the server end must not already be in use anywhere in your network. Neither can they be allocated from any IP subnets currently being used in your network.
3. If you have changed the tunnel TCP port at one ePipe, ensure you change it at the other end as well.
4. Ensure the network addresses set on the “VPN Internet Gateway Setup” screen are set to the IP addresses of the network(s) at the other end of the tunnel. The network IP address should not be set to the local network address or an IP address of a specific host.
5. All parameters labelled “Local” and “Remote” on the Security Parameters screen must be entered in reverse when configuring the other end of the tunnel. That is, the local SPI at one end should equal the remote SPI at the other end. Similarly for the local and remote keys for both encryption and authentication.
6. You should set the authentication and encryption protocols on both ends of the tunnel to be the same.
If you are experiencing problems transmitting data across the tunnel, first confirm if the tunnel has been established. If it is “OPENED” according to SSV (E2B) status or “Connected” according to the Bundle status, then the following tips should help:
1. Firstly, try pinging the host you are trying to communicate with from the computer initiating the communication. Always use the IP address and not the host or DNS name as this will preclude any name resolution problems. If you can ping the remote host then the problem is most likely application related and not the tunnel.
2. Login to the ePipe and ping the remote ePipe’s LAN IP address. If this works then the tunnel is working. This would indicate the problem is related to the routing of packets from one of the hosts to the other and not directly related to the tunnel.
3. Check the routing tables on the ePipes using the command:
SHOW INTERNET GATEWAY
Check the active routes for the appropriate destination network and ensure
it will route packets to that LAN via the tunnel end-point IP address for
that tunnel.
4. Check the default gateway of each host. These should be set to the IP address of the local ePipe.
5. If the host listens to RIP updates, check the routing table on the host to see where it will forward packets for the specific destination. Usually the command “netstat -nr” will display the routing table on Windows and UNIX hosts. If the gateway for that destination is not the local ePipe then this may be the problem.
6. If you can ping some remote hosts but not others then the problem is most likely to be the default gateway or routing table on the remote hosts that cannot be reached. These hosts probably do not know where to forward the replies.
Connecting two (or more) networks together using SSV tunnels is no different from building any other wide area network: it all becomes a matter of routing. Therefore, every PC, server or other device will need to know where to send packets when they need to travel to a remote LAN. Typically this involves configuring each device with a default route or default gateway. In general terms, every host on an IP WAN must know the IP address of a router with more “knowledge of the WAN” than themselves. In practical terms this means the default gateway needs to be set to the IP address of a router on the local LAN that knows how to forward packets to their destinations. In smaller networks, this router would be the local ePipe, where as in larger networks this router may be the ePipe or some other device.
If your hosts run an operating system that supports RIP (Routing Information Protocol), such as Windows NT/2000 or UNIX, then the host will learn about network routes by the RIP broadcasts from the ePipes. Consult your operating system documentation for more information on installing and configuring RIP.
about ePipe | products | solutions | support | information center | contact us
Copyright © 2002 ePipe Pty. Ltd. All rights reserved.
Getting started guides for:
2344
(1.4M pdf)
ML-IP
Concentrator (1.3M pdf)
2202
(1.4M pdf)
2242
(1.4M pdf)
2148/2188
(350KB pdf)
2181
(1.4M pdf)
ePipe
ServerWare (650K pdf)
User Guides for:
ML-IP
Family
VPN
and Security Family
Utilities for viewing guides:
Get
Acrobat Reader (free)
