Product Documentation
ADC
14.1-Current Release 13.1
View PDF

IP Tunnels

September 27, 2025
Contributed by: 
C S

An IP Tunnel is a communication channel, that can be created by using encapsulation technologies, between two networks that do not have a routing path. Every IP packet that is shared between the two networks is encapsulated within another packet and then sent via the tunnel.

The NetScaler appliance implements IP Tunneling in the following ways:

  • NetScaler as an Encapsulator (Load Balancing with DSR Mode): Consider an organization that has multiple data centers across different countries, where the NetScaler maybe at one location and the back-end servers are located in a different country. In essence, the NetScaler and the back-end servers are on different networks and are connected via a router.

    When you configure Direct Server Return (DSR) on this NetScaler, the packet sent from the source subnet is encapsulated by the NetScaler and sent via a router and tunnel to the appropriate back-end server. The back-end server decapsulates the packet and responds directly to the client, without allowing the packet to pass via the NetScaler.

  • NetScaler as a Decapsulator: Consider an organization having multiple data centers each having NetScalers and back-end servers. When a packet is sent from data center A to data center B it is usually sent via an intermediary, say a router or another NetScaler. The NetScaler processes the packet and then forwards the packet to the back-end server. However, if an encapsulated packet is sent, the NetScaler must be able to decapsulate the packet before sending it to the back-end servers. To enable the NetScaler to function as a decapsulator, a tunnel is added between the router and the NetScaler. When the encapsulated packet, with additional header information, reaches the NetScaler, the data packet is decapsulated i.e. the additional header information is removed, and the packet is then forwarded to the appropriate back-end servers.

    The NetScaler can also be used as a decapsulator for the Load Balancing feature, specifically in scenarios when the number of connections on a vserver exceeds a threshold value and all the new connections are then diverted to a back-up vserver.

The IP Tunnel feature is available with a NetScaler Premium edition license. For more information about NetScaler edition licenses and NetScaler features matrix, see NetScaler Editions data sheet.

Configure IP Tunnels

Configuring IP tunnels on a NetScaler appliance consists of creating IP tunnel entities. An IP tunnel entity specifies the local and remote tunnel end-point IP addresses and the protocol to be used for the IP tunnel.

Note: While configuring an IP tunnel in a cluster setup, the local IP address must be a striped SNIP address.

CLI procedures

To create an IP tunnel by using the CLI:

At the command prompt type:

  • **add iptunnel** <name> <remote> <remoteSubnetMask> <local> -**type** -**protocol** (**ipoverip** | **GRE**)
  • show iptunnel

To remove an IP tunnel by using the CLI:

To remove an IP tunnel, type the rm iptunnel command and the name of the tunnel.

To create an IPv6 tunnel by using the CLI:

At the command prompt type:

  • add ip6tunnel <name> <remoteIp> <local>
  • show ip6tunnel

To remove an IPv6 tunnel by using the CLI:

To remove an IPv6 tunnel, type the rm ip6tunnel command and the name of the tunnel.

GUI procedures

To create an IP Tunnel by using the GUI:

Navigate to System > Network > IP Tunnels, add a new IP tunnel.

To create an IPv6 Tunnel by using the GUI:

Navigate to System > Network > IP Tunnels > IPv6 Tunnels, and add a new IPv6 tunnel.

Customizing IP Tunnels Globally

By globally specifying the source IP address, you can assign a common source IP address across all tunnels. Also, because fragmentation is CPU-intensive, you can globally specify that the NetScaler appliance drop any packet that requires fragmentation. Alternatively, if you would like to fragment all packets as long as a CPU threshold value is not reached, you can globally specify the CPU threshold value.

CLI procedures

To globally customize IP tunnels by using the CLI:

At the command prompt, type:

  • **set ipTunnelParam** -**srcIP** <sourceIPAddress> -**srcIPRoundRobin** ( **YES** | **NO** )-**dropFrag** [**YES** | **NO**] -**dropFragCpuThreshold** <Positive integer>

  • show ipTunnelParam

Example:

> set iptunnelparam –srcIP 12.12.12.22 -dropFrag Yes –dropFragCpuThreshold 50
 Done

> set iptunnelparam -srcIPRoundRobin YES -dropFrag Yes –dropFragCpuThreshold 50
 Done
<!--NeedCopy-->

To globally customize IPv6 tunnels by using the CLI:

At the command prompt, type:

  • **set ip6tunnelparam** -**srcIP** <IPv6Address> -**srcIPRoundRobin** ( **YES** | NO )-**dropFrag** [**YES** | **NO**] -**dropFragCpuThreshold** <Positive integer>

  • show ip6tunnelparam

GUI procedures

To globally customize IP tunnels by using the GUI:

Navigate to System > Network, in the Settings group, click IPv4 Tunnel Global Settings.

  1. Navigate to System > Network, in the Settings group, click IPv6 Tunnel Global Settings.
  2. In the Configure IP Tunnel Global Parameters dialog box, set the parameters.

To globally customize IPv6 tunnels by using the GUI:

  1. Navigate to System > Network, in the Settings group, click IPv6 Tunnel Global Settings.
  2. In the Configure IP Tunnel Global Parameters dialog box, set the parameters.

GRE Payload Options in a GRE IP Tunnel

For a configured GRE IP tunnel, the NetScaler appliance encapsulates the entire Layer 2 packet, including the Ethernet header and the VLAN header (dot1q VLAN tag). IP GRE tunnels between NetScaler appliances and some 3rd party devices might not be stable, because these 3rd party devices are not programmed to process some or the Layer 2 packet headers. To configure a stable IP GRE tunnel between a NetScaler appliance and a 3rd party device, you can use the GRE payload parameter of the GRE IP tunnel command set. GRE payload setting can also be applied to a GRE with IPSec tunnel.

You can set the GRE payload parameter to do one of the following before the packet is sent through the GRE tunnel:

  • Ethernet with DOT1Q. Carry the Ethernet header as well the VLAN header. This is the default setting. For a tunnel bound to a netbridge, inner Ethernet header and VLAN header contains information from the ARP and bridge table of the NetScaler appliance. For a tunnel set as a next hop to a PBR rule, Inner Ethernet destination MAC address is set to zero and the VLAN header specifies the default VLAN. The encapsulated (GRE) packet sent from the NetScaler tunnel end point has the following format:

    localized image

  • Ethernet. Carry the Ethernet header but drop the VLAN header. Because the packets do not carry any VLAN information in the tunnel, for a tunnel with this setting and bound to a netbridge, you must bind an appropriate VLAN to the netbridge so that on receiving any packets on the tunnel, the NetScaler can forward these packet to the specified VLAN. If the tunnel is set as a next hop in a PBR rule, the NetScaler routes the packets that are received on the tunnel. The encapsulated (GRE) packet sent from the NetScaler tunnel end point has the following format:

    localized image

  • IP. Drop the Ethernet header as well as the VLAN header. Because tunnels with this setting do not carry Layer 2 headers, these tunnels cannot be bound to a netbridge but can be set as a next hop in a PBR rule. The peer tunnel endpoint device on receiving the packet either consumes or routes it. The encapsulated (GRE) packet sent from the NetScaler tunnel end point has the following format:

    localized image

To drop Layer 2 headers of packets in a GRE IP tunnel by using the CLI:

  • add ipTunnel <name> <remote> <remoteSubnetMask> <local> [-protocol <GRE> [-vlan <positive_integer>]] [-grepayload <grepayload>] [-ipsecProfileName <string>]
  • show iptunnel <tunnelname>

Example:

> add iptunnel IPTUNNEL-1 203.0.113.133 255.255.255.0 198.51.100.15 –protocol GRE –grepayload Ethernet -ipsecProfileName IPTUNNEL-IPSEC-1
Done
<!--NeedCopy-->

IPv6 Traffic through GRE IPV4 Tunnels

The NetScaler appliance supports transferring IPv6 traffic through an IPV4 GRE tunnel. This feature can be used for enabling communication between Isolated IPv6 networks without upgrading the IPv4 infrastructure between them.

For configuring this feature, you associate a PBR6 rule with the configured IPv4 GRE tunnel through which you want the NetScaler to send and receive IPv6 traffic. The source IPv6 address and destination IPv6 address parameters of the PBR6 rule specify the IPv6 networks whose traffic is to traverse the IPv4 GRE tunnel.

Note: IPSec protocol is not supported on GRE IPv4 tunnels that are configured to transfer IPv6 packets.

To create a GRE IPv4 tunnel by using the CLI:

At the command prompt, type:

  • add ipTunnel <name> <remote> <remoteSubnetMask> <local> -protocol GRE
  • show ipTunnel <name>

To associate a PBR6 rule with a GRE IPv4 tunnel by using the CLI:

  • add ns pbr6 <pbrName> ALLOW -srcIPv6 <network-range> -dstIPv6 <network-range> -ipTunnel <tunnelName>
  • show pbr

Sample configuration

In the following sample configuration, GRE IP tunnel TUNNEL-V6onV4 is created with remote tunnel endpoint IP address 10.10.6.30 and local tunnel endpoint IP address 10.10.5.30. The tunnel is then bound to pbr6 PBR6-V6onV4. The srcIPv6 specifies the IPv6 network connected to the local endpoint and destIPv6 specifies the IPv6 network connected to the remote endpoint. The traffic from these Ipv6 networks are allowed to traverse through the GRE IPv4 tunnel.

> add ipTunnel TUNNEL-V6onV4 10.10.6.30 255.255.255.255 10.10.5.30 -protocol GRE
-ipsecProfileName None
Done
> add ns pbr6 PBR6-V6onV4 ALLOW -srcIPv6 = 2001:0db8:1::1-2001:0db8:1::255 -destIPv6 =
1-2001:0db8:4::255 -ipTunnel TUNNEL-V6onV4
<!--NeedCopy-->

Send Response Traffic Through an IP-IP Tunnel

You can configure a NetScaler appliance to send response traffic through an IP-IP tunnel instead of routing it back to the source. By default, when the appliance receives a request from another NetScaler or a third-party device through an IP-IP tunnel, it routes the response traffic instead of sending it through the tunnel. You can use policy based routes (PBRs) or enable MAC-Based Forwarding (MBF) to send the response through the tunnel.

In a PBR rule, specify the subnets at both end points whose traffic is to traverse the tunnel. Also set the next hop as the tunnel name. When response traffic matches the PBR rule, the NetScaler appliance sends the traffic through the tunnel.

Alternatively, you can enable MBF to meet this requirement, but the functionality is limited to traffic for which the NetScaler appliance stores session information (for example, traffic related to load balancing or RNAT configurations). The appliance uses the session information to send the response traffic through the tunnel.

CLI procedures

To create a PBR rule and associate the IP-IP tunnel to it by using the CLI:

At the command prompt, type:

  • add ns pbr <pbr_name> ALLOW -srcIP = <local_subnet_range> -destIP = <remote_subnet_range> -ipTunnel <tunnel_name>
  • apply ns pbrs
  • show ns pbr <pbr_name>

To enable MAC-based forwarding by using the CLI:

At the command prompt, type:

  • enable ns mode MBF
  • show ns mode

GUI procedures

To create a PBR rule and associate the IP-IP tunnel to it by using the GUI:

  1. Navigate to System > Network > PBRs. On the PBRs tab, create a PBR rule.
  2. While creating the PBR, set the Next Hop Type to IP tunnel and IP Tunnel Name to the configured IP-IP tunnel name.

To enable MAC-based forwarding by using the GUI:

  1. Navigate to System > Settings, in Modes and Features, click Configure Modes.
  2. On the Configure Modes page, select MAC-based forwarding.

Sample configuation

Consider an example of an IPIP tunnel, NS1-NS2-IPIP, which is set up between two NetScaler appliances NS1 and NS2.

By default, for any request that NS2 receives through the tunnel, its routes the response traffic to the source instead of sending it (to NS1) through the tunnel.

You can configure policy based routes (PBRs) or enable MAC-Based Forwarding (MBF) on NS2 for enabling it to send the response through the tunnel.

In the following sample configuration on NS2, NS1-NS2-IPIP is an IPIP tunnel and NS1-NS2-IPIP-PBR is a PBR rule. For requests (with inner source IP address in the range 10.102.147.0-10.102.147.255 and inner destination IP address in the range 10.102.147.0-10.102.147.255) received by NS2 through the tunnel, NS2 sends the corresponding response through the tunnel (to NS1) instead of routing it to the source. The functionality is limited to the traffic that matches the PBR rule.

> add iptunnel NS1-NS2-IPIP 192.0.2.99 255.255.255.255 203.0.113.99–protocol IPIP

Done
> add pbr NS1-NS2-IPIP-PBR -srcIP 10.102.147.0-10.102.147.255 –destIP 10.20.1.0-10.20.1.255 –ipTunnel NS1-NS2-IPIP

Done
> apply pbrs

Done
<!--NeedCopy-->

Alternatively, MBF can be enabled on NS2. The functionality is limited to traffic for which NS2 stores session information (for example, traffic related to load balancing or RNAT configurations).

> enable ns mode MBF

Done
<!--NeedCopy-->
IP Tunnels
September 27, 2025
Contributed by: 
C S
September 27, 2025
Contributed by: 
C S

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.