By Sarath Chandrika

1. Introduction
2. Prerequisites
3. IPtables for SSL VPN
     3.1 IPtables for ESP-Enabled SSL VPN server
          3.1.1 When Corporate Network is Behind NAT
          3.1.2 ESP+SSL VPN (clustered) behind an L4 device
     3.2 IPtables for Traditional SSL VPN setup
          3.2.1 Corporate network behind NAT
          3.2.2 Traditional SSL VPN behind L4+NAT device

1. Introduction

This document describes the source NAT (SNAT) configuration for the Novell SSL VPN server, when full tunnel mode is enabled. Full tunnel mode is a feature announced in the 3.1 SP1 Version of Access Manager. In full tunnel mode, the client connection is completely secure as any traffic initiated at the client is tunneled to SSL VPN server and then directed to the respective networks. While redirecting, SSL VPN server makes use of the source NAT configuration to reach the public and private networks.

The following sections explain some deployment scenarios and the SNAT configurations required to get the full tunnel mode of SSL VPN functional. This document does not describe the traffic policy configuration or any other configuration of Full tunnel.

2. Prerequisites

  • Enable NAT in L4 device (if used)
  • Enable NAT on all the interfaces in the NAT routers.

3. IPtables for SSL VPN

3.1 IPtables for ESP-Enabled SSL VPN server:

To enable the SSL VPN server in Enterprise mode for full tunneling, configure a default route with firewall/NAT device as the gateway.
Configure the source NAT entries for each corporate network and one SNAT rule for the rest of the traffic.

For example,

Public network: subnet
Openvpn subnet:
Subnet accessible to Firewall/NAT gateway: connecting to firewall gateway)
Corporate networks:;

Openvpn subnet address can be read from the basic gateway configuration page in the devman UI for SSL VPN server configuration.

‘Ifconfig/ip addr’ command issued at the shell prompt in the server gives the corporate/DMZ network addresses.

The server provides remote access to DMZ networks. At the same time, public web access is tunneled to SSL VPN server through to Internet.

In this setup, you must configure three SNAT rules for full tunneling to work.

Iptables -A POSTROUTING -s <openvpn subnet/mask> -d <corporate network> -j SNAT -to--source <corporate interface/alias Ipaddress>

Iptables -A POSTROUTING -d -j SNAT -to--source <public interface/alias IPaddress>

In the above example,

Iptables –A POSTROUTING -s -d -j SNAT -to--source< or alias Ipaddress>

Iptables –A POSTROUTING -s -d -j SNAT -to--source< or alias Ipaddress>

Iptables –A POSTROUTING -s -d -j SNAT -to--source < or alias Ipaddress>

The order of the SNAT rules are very important. The SNAT rules to the DMZ networks should always precede the (SNAT rule to public network) rule.

In Kiosk mode, though socks server takes care of initiating data connections, the second SNAT rule takes command and all the traffic to the DMZ networks might go with the public IP address. So, for full tunnel mode to support both Enterprise mode and Kiosk modes, the first SNAT rule in section 3 can be modified for ANY SOURCE option (-s for each corporate network as follows:

Iptables -A POSTROUTING -s <> -d <corporate network> -j SNAT -to--source <corporate interface/alias Ipaddress>

In the above example the iptable rules required for both Enterprise and Kiosk modes are:

Iptables –A POSTROUTING -s -d -j SNAT -to--source< or alias Ipaddress>

Iptables –A POSTROUTING -s -d -j SNAT -to--source< or alias Ipaddress>

Iptables –A POSTROUTING -s -d -j SNAT -to--source < or alias Ipaddress>

3.1.1 When Corporate Network is Behind NAT

In a deployment where the corporate network is shielded by a NAT device, the iptables rules for the corporate/DMZ access can be as mentioned in section 3.

In that case, network specific routes for private network should be configured in the SSL VPN server with the NAT device as the gateway. Access to Internet will be taken care by the default gateway which is the Firewall/NAT device.

Ex: Routes at SSL VPN server,

route add –net gw <Nat device IPaddress>
route add default gateway <Firewall gateway IPaddress>

3.1.2 ESP+SSL VPN (clustered) behind an L4 device

Make sure that NAT is enabled in L4 on all the interfaces.

SSL VPN server should be configured with a default route to L4 device.

Configure the SNAT rules as shown in the above Figure. As this deployment contains a cluster of SSL VPN devices, each device should be configured with the SNAT rules with their respective openvpn subnets.

A default route should be configured in each of the servers with IP address of L4 as the gateway.

As L4 is configured to monitor the health of SSL VPN device, there might be issues when using software L4( this is applicable for Linux based software) in handling the data traffic that is redirected by the SSL VPN server.

Monitor if the data traffic coming from the SSL VPN server is being forwarded and also routed back through the L4’s public interface. If the return packet is not being forwarded to the SSL VPN server, then the following SNAT rule should be configured on top of any other SNAT/NAT rules(if any) in L4:

Iptables -A POSTROUTING -s -d <SSLVPN server IPaddress/mask > -j ACCEPT

3.2 IPtables for Traditional SSL VPN setup

For the above setups where the server is accelerated by an Access Gateway, the required SNAT rules are same as those explained in section 3.Ensure that SSL VPN server has a default route with the (Firewall+NAT) router’s IPaddress as the gateway.

3.2.1 Corporate network behind NAT

The description made for section 3.1.1 is applicable to this section.

3.2.2 Traditional SSL VPN behind L4+NAT device

The configuration details mentioned in section 3.1 are applicable here as well.

P.S: Usually hardware L4 with NAT enabled takes care of traffic routing. Software L4 should be monitored closely for any issues and SNAT settings should accordingly be changed.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Categories: News

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

No Comments
Jul 21, 2009
12:53 pm
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow