SSL VPN Architecture



By: ncashell

December 14, 2007 11:05 am

Reads: 932

Comments:0

Rating:0

Introduction
  SSLVPN Solution Options
Architecture and High-level Flow of Events
Kiosk Mode – Overall Architecture
  SSLVPN Kiosk Mode – Server-side Components
  SSLVPN Kiosk Mode – Client-side Components
  Kiosk Mode Authentication Flow
  Kiosk Mode Data Transfer Flow
Enterprise Mode – Overall Architecture
  SSLVPN Enterprise Mode – Server-side Components
  SSLVPN Enterprise Mode – Client-side Components
  Enterprise Mode Authentication Flow
  Enterprise Mode Data Transfer Flow


Introduction

With more and more individuals working outside traditional office settings, the need for secure remote access to corporate resources has become more important than ever. No matter where users are — whether traveling nationally or internationally, working from home or on site at a partner location — they should be able to access corporate resources without compromising security. The Novell Access Gateway SSL VPN (Secure Socket layer Virtual Private Network) is the product that allows secure “anywhere-, anytime-access.”

Novell’s SSL VPN is a new type of VPN based on the secure sockets layer (SSL) protocol used in e-commerce. SSL has been traditionally and widely deployed for securing web-based applications in the form of HTTPS. SSL is embedded in most IP stacks and occupies the architectural base of the application layer. It can be installed directly on the Linux Access Gateway, or on any host running SLES 9 or 10 (check out http://www.novell.com/documentation/novellaccessmanager/installation/index.html?page=/documentation/novellaccessmanager/installation/data/bookinfo.html#bookinfo for deployment scenarios).

This document will look at the architecture of the Novell Access Manager SSLVPN solution, the flow of events within an SSLVPN session and look at troubleshooting tools available to help troubleshoot SSLVPN issues in your environment.

SSLVPN Solution Options

Novell’s SSLVPN solution encompasses two options:

1. Kiosk mode (uses a combination of the stunnel and dante open source projects at http://www.stunnel.org/ and http://www.inet.no/dante/): In the Kiosk mode of SSL VPN, only a limited set of applications are enabled for SSL VPN. A non-admin or a non- root user who does not have the administrator access can connect to SSL VPN in the Kiosk mode. In Kiosk mode, applications that were opened before the SSL VPN connection was established are not SSL-enabled.

The Kiosk mode supports TCP and UDP applications only, and no ICMP. This mode is better suited for machines that are not managed by an organization, such as home computers and computers in Web-browsing kiosks. You cannot force Kiosk mode when connected as a user with root or admin privileges.

2. Enterprise mode (uses the OpenVPN open source project at http://openvpn.net/): You can access SSL VPN in the Enterprise mode if you have admin or root user access to the workstation, if you know the admin or root user credentials, or if you have preinstalled the client components on the workstation.

In Enterprise mode, all applications, including those on the desktop and the toolbar are SSL-enabled, regardless of whether they were opened before or after connecting to SSL VPN. In this approach, a thin client is installed on your workstation. This thin client takes care of the administrator activities required for the Enterprise mode of SSL VPN. In the Enterprise mode, the IP Forwarding feature is enabled by default on the server.

The Enterprise mode is recommended for devices that are managed by an organization, such as a laptop provided by the organization for its employees. The Enterprise mode of SSL VPN supports the following applications, which have problems in Kiosk mode:

* Protocols such as ICMP, NetBIOS and Microsoft RPC (used with outlook mail client)
* Applications that open TCP connections on both sides, such as VoIP, PCAnywhere and active FTP.
* Enterprise applications such as CRM and SAP*.
* Applications such as Windows File Sharing systems, the Novell Client™ and Novell SecureLogin.


Architecture and High-level Flow of Events

Before delving into the details of the various operation modes, one must look into the flow of events required to get an SSLVPN workstation connected to the server. This connection should be done in such a way that it can transmit data to the non HTTP application it is protecting. The diagram below shows a basic SSLVPN architecture where the SSLVPN server is running on its own hardware platform, with a non HTTP based application sitting behind it. In order to access this non- HTTP application from the SSLVPN client, the following steps need to take place.

Figure 1 – Accessing a non- HTTP application from the SSLVPN client

1. The SSLVPN client workstation will hit the SSLVPN server protected resource on the Access Gateway. The Access Gateway must have a proxy service defined for the SSLVPN server so that all initial requests from a browser to the SSLVPN server (for path /sslvpn/login) will go to the Access Gateway.

2. If the user is not already authenticated for that protected resources, the user will be redirected to the Novell Identity Server (IDP) to login. The user will be presented with a login page where the credentials are entered and submitted. The credentials will then be validated against a back-end user store (eDirectory in the above example). Assuming the user’s credentials are validated, an artifact gets sent from the Identity server to the browser.

3. The browser redirects the artifact to the Access Gateway. The Access Gateway sends the artifact back to the Identity server over the SOAP backchannel (direct communication between Access Gateway and IDP), and the IDP server responds with an assertion, including user specific details. After the Access Gateway consumes this assertion it sends another HTTP redirect back to the browser. A session cookie is sent back for use with subsequent requests for this SSLVPN resource, telling the browser to send the request to the SSLVPN server (/sslvpn/login).

4. The browser sends the request to the SSLVPN /sslvpn/login via the Access Gateway. The Access Gateway, with the SSLVPN Identity Injection enabled for this resource, adds the required headers (user information, sessionID and roles) to the HTTP headers of the outgoing request. For the header details, see:

http://www.novell.com/documentation/novellaccessmanager/adminguide/index.html?page=/documentation/novellaccessmanager/adminguide/data/b322a0l.html

The SSLVPN server receives this request from the Access Gateway, identifies the user/role and locates the policy information for the role. This user policy information, as well as the SSLVPN client binaries (including the stunnel client) is sent back to the browser via the Access Gateway.

5. The SSLVPN client software is initialized on the client, and a connection to the SSLVPN server is made. This connection is direct from the SSLVPN client to the server, and not via the Access Gateway. (The only SSLVPN specific traffic that continues through the Access Gateway are regular keep-alives to make sure the SSLVPN server and browser client are still active). When an application on the client tries to access a protected resource behind the SSLVPN server, the application data is tunneled to the server. It is then proxied or forwarded to the client, depending on the mode of operation. More details are discussed below.

Before looking at the flow in more detail, let’s look at the two SSLVPN modes of operation and the components associated with each.


Kiosk Mode – Overall Architecture

The Kiosk, or stunnel mode of operation is based on the open source project at http://www.stunnel.org/. The diagram below shows the components associated with the Kiosk mode.

Figure 2 – Kiosk mode architecture

The following briefly describes each of the components found in the solution:

SSLVPN Kiosk Mode – Server-side Components

Servlet: The SSLVPN servlet component can be run on any tomcat or servlet engine, and it need not be installed on the actual SSLVPN server itself. If not installed on the SSLVPN server, administrators must modify the config.txt file in the /var/opt/novell/tomcat4/webapps/sslvpn/WEB-INF/ directory (see ‘Configuring Load Balancing Through Servlets’ under http://www.novell.com/documentation/novellaccessmanager/adminguide/index.html?page=/documentation/novellaccessmanager/adminguide/data/b6820mb.html). This servlet package name is novl-sslvpn-servlet-3.* (Note: * depends on version). For the most part, this includes the /var/opt/novell/tomcat4/webapps/sslvpn/* files required by the servlet environment.

The servlet receives the authenticated users sessions specific information from the Access Gateway. The goal of the servlet is to:

- Handle incoming HTTP requests from the Access Gateway destined for the SSLVPN login (/sslvpn/login) page.
- Run individual communication channel with applet for the direct control of the client session, making sure that the session is open and valid, or closed and cleared.
- Send/receive control messages to/from SSLVPN connection manager. For example, this would include sending the user credentials, sending roles to the connection manager components, and processing the traffic policies coming back for that user.

Connection Manager: This is a TCP-based application running on a SLES server that listens out on TCP port 2010 and communicates with the above servlet. This component, as well as the others below, are all part of the novl-sslvpn-3.* (* depends on version). The connection manager service is in /opt/novell/sslvpn/bin/connman. It’s main functions include the following:

- Managing a server socket (UNIX domain) to communicate with
o Admin Console to synchronize the configuration changes
o Socks and stunnel servers pushing changes out
o Monitoring and Auditing module for interfacing into the NSure Auditing system

- Dynamic connection management, such as
o Pulling out the policies from configuration database for a particular identity
o Communicating the change in data for Socks Server

Policy Engine: There is a policy enforcer component at the server as well as on the client. Given a specific request passed to it by the socks server, this component checks against the policies saved in the policy.txt file at /etc/opt/novell/sslvpn. Depending on whether a match is found, the traffic is either allowed or denied.

Socks Server: This is a TCP-based application running on a SLES server that listens on TCP port 1080. The socks service is in /opt/novell/sslvpn/bin/sockd. The SOCKS 5 Server acts as a generic proxy between the SOCKS Client and the end host, which resides in the protected network. This component, together with Stunnel stack, provides the core SSL VPN functionality.

Stunnel Server: This is a TCP-based application running on a SLES9 server, listening on TCP port 7777 by default. The stunnel service is in
/opt/novell/sslvpn/bin/stunnel. The stunnel program is designed to work as an SSL encryption wrapper between the remote client and a local (socks) server. The concept is that by having non-SSL aware daemons running on your system you can easily setup them to communicate with clients over a secure SSL channel.

VCC/JCC: This is the protocol used to interface into the Access Manager configuration store so that all changes to the configuration are synchronized with the SSLVPN server components via the Connection Manager.

SSLVPN Kiosk Mode – Client-side Components

Browser: The browser is initially required to contact the SSLVPN servlet via the Access Gateway. Once connected, keep-alive probes are continuously sent from the browser to the SSLVPN servlet to make sure that the existing session remains valid.

Application Redirector: On the workstation, all the outgoing traffic needs to be intercepted and treated differently, if it is destined for SSLVPN protected network. The mechanism used to intercept this traffic will be implemented differently for Linux and Windows workstations. On a Linux workstation, the LD_PRELOAD environmental variable is modified to load our own libsock.so library to handle the connect socket calls. On windows workstation, a similar approach of hooking into library is used.

Policy Enforcer: When the redirector intercepts the application level request, it checks with the policy enforcer to determine whether the request needs to out out through the SSLVPN tunnel. This component checks the policies associated with this authenticated and checks whether the outgoing request conforms to the policies allowed for that user. Depending on the response, it allows or denies them.

Socks Client: Assuming that the policies allow the authenticated user access the remote application, the application level request is sent to the socks client on the workstation. This socks client appends a socks v5 header and proxies the application data within the socks payload. Once done, the request is passed to the Stunnel client on the same host.

Stunnel Client: With the socks data ready to be sent to the remote application server, the final step involves encrypting this data and packaging it within a new seat of headers. This is the role of the stunnel client. The stunnel client simply encrypts the socks data passed to it and adds information required to build transport and network layer headers. The main transport layer headers include the TCP destination port of 7777 by default. The corresponding IP header includes the IP address of the SSLVPN server external IP address, and not the IP address of the application server we are trying to communicate with.

The stunnel client listens on both TCP and UDP. If the client host has been configured to use port X, it spawns a listener on both TCP and UDP port X. This avoids connection issues later if the transport layer has been changed on the SSLVPN server side.

Kiosk Mode Authentication Flow
(assuming user is authenticated and accesses SSLVPN login page)

1. Proxy sends a request to the SSLVPN servlet (cookie and authenticated identity information are passed to the Servlet through this message).

2. The Servlet informs Connection Manager of a successful connection and awaits the user policies and client binaries.

3. At this time, Connection Manager becomes aware that a user has been successfully authenticated for SSL VPN session by an external authenticating agent (Access Gateway). The info it gets from the servlet at this stage includes the following:

- User identity
- Cookie for the http session between authenticating agent and browser
- Client/browser identity (IP address and port ), which can also be the dynamic NAT’s identity
- Time of connection

4. The Connection Manager validates such a connection request and the does the following:

- Checks for the duplication of connection from the same client machine
- Builds the policy list (traffic and cic) for this particular user
- Sends the policies back to the servlet

5. The servlet, upon receiving the above information from the connection manager

- Generates a web page with Active-X controls or a Java Client applet (depending on whether client browser is IE or not). It includes the user policies and client binaries as a self-extractable download. The client binaries depend on the platform the client is running on (Windows, Linux, MAC) and include such things as an openssl, socks, stunnel client. The files may be found under the
/var/opt/novell/tomcat4/webapps/sslvpn/ directory of SSLVPN server.
- Sends a 200 OK HTTP response back to the browser via the Access Gateway proxy, with the contents of the above web page

6. The Access Gateway proxy sends the response back to the browser.

7. The browser processes the response and runs the self- extractable image it downloaded. The Client components are installed and Java Applet or Active-X controls starts running. Assuming everything initializes correctly, the Socks client will try to communicate with the Socks server. As this is a secure path, stunnel initiates the SSL negotiation.

8. The Stunnel client does not do the the SSL negotiation (exchanging certs, generating session keys) with the server to form the SSL channel until data is sent. In Kiosk mode, when the Java applet (UI) indicates that the SSL VPN connection is established, it’s just an indication that the services have initialized successfully. The Enterprise mode client below works very differently at this stage.

Kiosk Mode Data Transfer Flow
(application data sent to remote host)

When data is sent from the client application to the remote server, this application data is tunneled by the Kiosk mode SSLVPN client. Looking at the packet types visible on the network, when such a client tries to talk to a remote application server in Kiosk mode, you can see that the default transport layer protocol is TCP.

In the example below, a user on the workstation running the SSLVPN Kiosk mode client has tried to initiate an SSH session to the SSH server at 11.0.0.1, which is located on an internal network only accessible behind the SSLVPN private interface. The 147.2.36.147 is the IP address of the SSLVPN workstation where the client application is running. The SSLVPN server has two interfaces: the publicly accessible interface at 147.2.16.109, and the private interface 10.0.0.1 that is the next hop to all SSLVPN protected networks.

Packet 373 shows the SSH data being tunneled from the workstation to the public IP address of the SSLVPN server (147.2.16.109). The default SSLVPN configuration parameters are used, so the data is sent within a TCP segment destined for port 7777.

Figure 3 – Packet 373, port 7777

With tcpdump on a SLES host, you can trace packets on the loopback interface (e.g., using ‘tcpdump -i any -n -s 0′). What we can see in packet 374 is the resulting packet after the SSLVPN server has unencrypted the packet (the Socks v5 data). The latest versions of Wireshark will decode the Socks headers and show the authentication process. An example of the Socks authentication process that goes on between the SSLVPN client and server would show the following: The client offers various authentication modes and server chooses most appropriate (username/pwd below). The client then sends the credentials specific for this users session and assuming that the Socks server can validate, then the client and server are authenticated, as shown below:

Socks client <--------------------> Socks Server

Figure 4 – Validation of credentials by Socks server

Once Socks authentication has been validated between the socks client and server, the socks payload (the ssh application data) can then by proxied to the remote host.

Figure 5 – Proxying the Socks payload to the remote host

Packet 374 shows the data passed to the Socks server from the stunnel server. This is the SSH client request to the remote SSH server at 11.0.0.1 on TCP port 22. Note that this request is sent via the loopback interface to the SOCKS server on TCP port 1080.

Figure 6 – Packet 374: Data passed to the Socks server from the stunnel server

Packet 377 now shows the TCP connect request at the application layer (triggered by packet 374) – visible through a TCP SYN from 10.0.0.1 (private interface of SSLVPN server) to 11.0.0. Because it is proxied, all outgoing requests to application servers on the private network will have a source IP address in the outgoing requests of 10.0.0.1. This is very different from the Enterprise mode client, which we will describe later.

Figure 7 – Packet data transmission

When the response comes back from the SSH server (packet 378), we need to reverse the process before sending it back to the client. We need to pass it to the Socks application first (packet 380); then the Socks server builds the Socks data and passes it to the Stunnel server. The stunnel server encrypts the data and builds the response to send back to the SSLVPN client. This is shown in packet 382 above where the SSLVPN server (147.2.16.109) sends the tunneled data back to the SSLVPN client at 147.2.36.147.

Communication continues in this mode until the application client or server terminates the connection. If the application server terminates the connection via a TCP FIN, a corresponding Socks close request will be issued from the SSLVPN server to the client. This allows the TCP session on the client for this application session to be closed. If the application client terminates the request, the Socks close request will be sent to the Socks server side, so that the back-end application server is eventually notified of the close request. Note that this only terminates the session at the application layer – the SSLVPN client connection to the server still remains.


Enterprise Mode – Overall Architecture

The Enterprise, or OpenVPN mode of operation is based on the open source project at http://openvpn.net/. It is targeted for enterprise users. A high degree of user experience is achieved through this mode of access. In this mode, the user must either have administrator privileges in the machine, or an administrator privileged service needs to accepted when connecting to the SSLVPN server from a non-administrator privileges account. It also works at the IP layer, versus the Kiosk mode application layer, and routing becomes a key issue as we will see later.

The diagram below shows the components associated with the Enterprise Mode.

Figure 8 – Enterprise Mode components

SSLVPN Enterprise Mode – Server-side Components

Servlet: The SSLVPN servlet component can be run on any tomcat or servlet engine, and it need not be installed on the actual SSLVPN server itself. If it is not installed on the SSLVPN server, administrators must modify the config.txt file in the
/var/opt/novell/tomcat4/webapps/sslvpn/WEB-INF/ directory (See ‘Configuring Load Balancing Through Servlets’ under http://www.novell.com/documentation/novellaccessmanager/adminguide/index.html?page=/documentation/novellaccessmanager/adminguide/data/b6820mb.html). This servlet package name is novl-sslvpn-servlet-3.* (* depends on version.) For the most part includes the /var/opt/novell/tomcat4/webapps/sslvpn/* files required by the servlet environment.

The servlet receives the authenticated users sessions specific information from the Access Gateway. The goal of the servlet is to

- Handle incoming HTTP requests from the Access Gateway destined for the SSLVPN login (/sslvpn/login) page.
- Run an individual communication channel with the applet for the direct control of the client session, making sure that the session is open and valid, or closed and cleared.
- Send/receive control messages to/from the SSLVPN connection manager. For example, this would include sending the user credentials, sending roles to the connection manager components, and processing the traffic policies coming back for that user.

Connection Manager: This is a TCP-based application running on a SLES server that listens on TCP port 2010 and communicates with the above servlet. This component, as well as the others below, are all part of the novl-sslvpn-3.* (* depends on version). The connection manager service is in /opt/novell/sslvpn/bin/connman. Its main functions include the following:

- Managing a TCP socket to communicate with
o Admin Console, to synchronize the configuration changes
o Openvpn Server, pushing changes out
o Monitoring and Auditing module, for interfacing into the NSure Auditing system

Note: In Enterprise mode, the Connection Manager communicates with OpenVPN using the TCP socket. The port number is dynamically chosen and supplied to OpenVPN through its configuration file. In OpenVPN this is known as the management port.

- Dynamic connection management such as
o Pulling out the policies from configuration database for a particular identity
o Communicating the change in data for openvpn server

Policy Engine: As with the Kiosk mode solution, there is a policy enforcer component at the server as well as on the client. Given a specific request passed to it by the OpenVPN server, this component checks against the policies saved in the policy.txt file at /etc/opt/novell/sslvpn from policy store (obtained via the Connection Manager). Depending on whether a match is found, the traffic is either allowed or denied.

Traffic Redirector: The component sits at the kernel level as a network driver. The drivers used here are tun/tap drivers. Tun/Tap drivers are already installed on Linux systems, whereas by default the drivers for Windows system are delivered during the initial connection from the SSLVPN server that includes binaries. The Tun driver simply forwards traffic from stack to a userspace client (openvpn), and the openvpn server does the actual encryption/decryption service.

Although both Tun and Tap drivers exist, Access Manager uses the Tun interface with no option to use Tap. The Tun mode uses a routing method, whereas the Tap mode uses bridging. The advantages of the routing mode include:

- Efficiency and scalability (scales well with more devices added)
- Better tuning of MTU for efficiency (very important when working with disparate networking topologies).

The disadvantage is that routes must be set up linking each subnet.

OpenVPN Server: This component is responsible for encrypting and tunneling data destined for one of the SSLVPN protected networks, and it is done at the network stack level. This component is only used for enterprise mode access, where the user needs to have a root privilege or the user system is already deployed with a thin service (Install Enabler). If a connected user has root privileges, the Enterprise mode is performed automatically; for users that do not have root privileges, the option to use Enterprise mode still exists through the ‘Priveleged enabler’ client component (see below).

VCC/JCC: This is the protocol used to interface into the Access Manager configuration store. All changes to the configuration in the DeviceManager are synchronized with the SSLVPN server components via the Connection Manager.

SSLVPN Enterprise Mode – Client-side Components

Browser: The browser is initially required to contact the SSLVPN servlet via the Access Gateway. Once connected, keep-alive probes are continuously sent from the browser to the SSLVPN servlet to make sure that the existing session remains valid.

Privilege Enabler: This component is used to bypass the normal user limitations for Enterprise mode clients. When a non-privileged user connects to the SSLVPN server for the first time, that user is prompted for administrator credentials to provide the user the option of using Enterprise mode (see below). Administrator rights are required because the OpenVPN stack tunneling the data is required to redirect traffic at the network level. This service handles dynamic OpenVPN client launching and other privileged operations, which requires root privileges.

Figure 9 – Admin/root privileges for SSL VPN

OpenVPN Client: The OpenVPN client is a client daemon that associates itself to a Tun device and manages it. It is the primary component necessary for implementing SSL tunneling in enterprise mode access. When policies dictate that the traffic must be sent through the tunnel, the OpenVPN client sends the encrypted data out the Tap interface to go out the wire.

Policy Enforcer: When the OpevVPN client intercepts the application level request, it checks with the policy enforcer to determine whether the request needs to out out through the SSLVPN tunnel. This component checks the policies associated with this authentication and checks whether the outgoing request conforms to the policies allowed for that user. Depending on the response, it allows or denies them.

Traffic Redirector: In case of enterprise mode access, the traffic redirector sits at the kernel level as a network driver. The drivers used here are Tun/Tap drivers. Tun/Tap drivers are already installed on Linux systems, whereas the drivers for Windows systems are delivered from the SSLVPN server via the binary download. The Tun driver forwards traffic from the stack to a userspace client (OpenVPN), and this OpenVPN client does the actual encryption/decryption of application-level data.

Enterprise Mode Authentication Flow
(assuming user authenticated and accesses SSLVPN login page)

The flow for the Enterprise mode is exactly the same as that of the Kiosk mode, up to step 7. As the applet starts running, the following sequence of events start occuring in Enterprise mode:

1. The applet evaluates the user privileges on the system being accessed. If the system has administrator privileges, or the user provides a valid user ID/password for an administrator account during the privileged enabler prompt, the applet starts the enterprise mode access.

2. The applet downloads all necessary components for enterprise mode access.

3. The applet launches the installation of the Tap driver if the driver has not already been found.

4. The applet launches the installation of a ‘novell-sslvpn-service’ service if such a service is not already found, or if the thin service is out of version compared to the one available in server.

5. The applet asks this novell-sslvpn-service service to launch the openvpn client binary by providing the necessary parameters. These could include the username and password received from the servlet through the browser, and a session token for the SSL negotiation.

6. The OpenVPN client then initiates an SSL negotiation for this user to the back end SSLVPN server external IP address. During this handshake, the openvpn client verifies the server certificate.

7. The OpenVPN server receives the username and password from the client and verifies it against the authentication store residing at the Connection Manager.

8. Assuming credentials are valid, the server sends a Success message to the client and then to applet.

9. The SSLVPN user interface displays a message that the connection is successful.

Enterprise Mode Data Transfer Flow
(application data sent to remote host)

When data is sent from the client to the server, the application data is tunneled by the Enterprise mode client. Unlike the Kiosk mode client, the default transport layer protocol is UDP, as we can see below. In this example, a user on the workstation running the SSLVPN Enterprise mode client has tried to initiate an SSH session to the SSH server at 11.0.0.1, which is located on an internal network only accessible behind the SSLVPN private interface. The 147.2.92.2 is the IP address of the SSLVPN workstation where the client application is running.

Packet 163 shows the SSH data being tunneled from the workstation to the public IP address of the SSLVPN server (147.2.16.109). The default OpenVPN configuration parameters are used, so the data is being tunneled on UDP port 7777. OpenVPN uses UDP by default (benchmarks suggest that OpenVPN offers better performance when using UDP), but security policies within your organization may dictate that TCP is required (better control at the firewall with the stateful transport layer).

Figure 10 – SSH data tunneled from the workstation to the public IP address of the SSLVPN

The OpenVPN server, listening out on UDP 7777 processes this incoming request, validates the SSL headers, and extracts the application data. Because it acts as a router, it forwards the original request to its destination.

In packet 1064, we see that forwarding take place. The source IP address of the outgoing request is 10.8.0.14 – the OpenVPN IP address assigned by DHCP on the SSLVPN server. This is the IP address assigned to the Tap interface on the workstation. The destination IP address is that of the SSH server itself, on the private network (11.0.0.1). Because SSH is a TCP-based application, the request is now sent to TCP port 22 on the SSH server.

Figure 11 – Forwarding the original request to TCP port 22 on the SSH server

Packet 1065 shows the TCP response to packet 1064. The key point here is that the response has come back to the SSLVPN client IP address via the SSLVPN server! If the routing table on the SSH server did not have an entry for the OpenVPN subnet (10.8.0.0/16) pointing to the SSLVPN server as the next hop, the response might a) never reach the SSLVPN client, or b) reach the SSLVPN client but be unencrypted, at which point the TCP segment would be dropped. It is imperative that all responses from the application server going to the SSLVPN client do so via the SSLVPN server.

Packet 1066 shows the SSLVPN encrypted response to the client. Again, we are back to UDP at the transport layer, and the source and destination IP addresses are that of the SSLVPN server public IP address and client IP address, respectively.

Figure 12 – SSLVPN encrypted response to the client

This example is not very realistic, as all remote hosts on the network need to know that the route back to the OpenVPN subnet address is done through the SSLVPN server private interface. A more practical example is shown below, where we use IPTABLES to rewrite the source IP address of the outgoing requests to the remote application servers. By executing the following on the SSLVPN server:

iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -j SNAT --to 10.0.0.1

all IP datagrams with a source IP address on the 10.8.0.0/16 subnet will get rewritten to 10.0.0.1. Because the 10.0.0.1 address is part of the internal network, all hosts should have a route back to this address.

Figure 13: Re-writing 10.8.0.0/16 subnet datagrams to 10.0.0.1

Looking at the same request this time around, we see that Packet 10749 shows the tunneled request from the SSLVPN client to the SSLVPN server external IP address.

Packet 10750 shows what we saw in earlier traces above – the OpenVPN decrypts the application request and now tries to forward to the SSH application server on 11.0.0.1. The source IP address is 10.8.0.10, and the IP address is assigned to the Tap interface.

Packet 10751 shows the result of the IPTABLES command above – the 10.8.0.10 source IP address has been rewritten to the private IP address of the SSLVPN server. For the SSH application server to respond to such a request, it will most likely not require any modifications to its routing table. This is the best approach to take.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: ,
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.

Comment