We have a customer that requires us to connect to their network through their web portal running “Pulse Connect Secure”. Once I authenticate I’m able to connect to our devices on our network.
I’m used to “traditional” VPN clients where once I log in with a username/password I get an IP address, subnet mask, gateway, and a route added to my machine. This isn’t happening when I log into their Pulse Connect Secure web portal, yet I’m still able to connect to our devices on their network with Microsoft RDP.
How does this wizardry work? I’ve been trying to find some high level technical details by searching on Google but I’m not finding much. Can anyone throw some knowledge my way? Maybe some terms I can search for that will explain how this magic works? The only thing I can think of is that the .exe application that loads on my machine redirects the traffic to their network, but how does that .exe intercept the network traffic of mstsc.exe? Is it a TCP wrapper of sorts?
Pulse Secure provides a number of different “VPN” options. What you are using is known as Clientless VPN. You login to website and use a variety of published links.
Pulse Secure has internal “apps” for certain things,. like an RDP client, Telnet/SSH, file browser, and some other stuff. This is all running on the Pulse Secure appliance itself. Some are java applets, some are HTML5.
Other internal websites and/or services are published with various proxy like methods, using Secure Application Manager in the form of WSAM (Windows Only) and JSAM. These methods launch apps on your computer to tunnel through, but it’s not a VPN adapter on the device.
There’s also a standard pass-through proxy where absolutely nothing is running on your computer, and you just proxy through the Pulse Secure appliance’s web interface to the internal website, but it’s not compatible with all websites/webapps, so it’s use cases tend to be limited.
It’s PFM 
Actually, the backend system is called the Content Intermediation Engine, and it goes through and rewrites links and all traffic in real time. Newer features allow the Pulse Secure appliance to connect to RDP sessions using just a web browser that supports HTML5.
If it’s not browser-based, then you may be using the Pulse Secure RDP Add-On that hooks into the MS RDP client and creates a miniature proxy. Your RDP client then sends RDP traffic to the localized proxy which in turn encapsulates the RDP traffic inside HTTPS, and sends the traffic to the Pulse Secure Appliance over HTTPS. From there, the appliance will de-encapsulate the HTTPS traffic and forwards the RDP traffic to the internal server. Note that this is a separate feature from WSAM/JSAM, which is more feature-rich and supports destination/port forwarding/uses different mechanisms to capture traffic to be sent to the SSL VPN. The RDP ‘proxy’ requires a windows machine with the MS-RDP client preinstalled.
The configuration can be as simple as enabling the bookmark, or you can get as complex as passing your login credentials from logging into the VPN to the RDP Server, and launching specific applications through RemoteApp.
If you’d like to know more about the capabilities, start here with the admin guide. Look at the Terminal Services chapter in particular. There’s also paid training that I cannot recommend enough for anyone administering one of these boxes.
Source: Pulse Secure Admin since 2006 (11 years!), Connect Secure/Policy Secure Certified, and Pulse Secure Instructor.
Are the addresses of the servers on their network private (rfc1918) addresses when you access them?
A typical way to implement VPNs is with a virtual interface and routes pointing to it.
Another way is to install a Winsock Layered Service Provider or Windows Filtering Platform driver that directs specified traffic across the tunnel without touching the traditional routing table.
Given that having many WFP filters installed would cause issues with Pulse Secure on Windows 7, it would seem that this is how it is actually implemented.
Are you logging into the Pulse web page, then clicking a link that launches a remote desktop session from “within” the web browser?
If so that is using RDP - it’s just that they tunnel it over SSL port :443 and use a Java or Active X client.
Pulse also supports a more traditional VPN setup where you get a private IP inside their network, but it doesn’t have to. It can present Remote Desktop connections, Intranet web pages, Terminal/SSH/Telnet, and more directly through the browser without VPN by using Java or Active X clients.
I manage a pulse secure, so I actually know this from first hand experience.
Did it require you to download any kind of client or run any executable at any point?
Pulse = Juniper SRX
It’s a dynamic automatic aggressive ipsec vpn.
This isn’t happening when I log into their Pulse Connect Secure web portal, yet I’m still able to connect to our devices on their network with Microsoft RDP.
You mean split tunnel? Cisco and others let you split tunnel as well.
Thanks for the reply! I’m going to read through the page you linked and hopefully it will give me the understanding I’m looking for
Great explanation, thank you! I’m going to read through that admin guide next, this is fascinating to me.
I think the piece I’m trying to understand is how this is able to intercept/redirect my traffic without adding an IP address to my machine, or a new network route, new virtual network adapter, etc. Not only can it intercept/redirect my mstsc.exe utility, but also netcat.exe, tcping.exe, nmap.exe, etc. How?
As an example, my computer has just 1 IP address, 192.168.1.100 on a /24 network, default gateway 192.168.1.1. If I try to connect to port 5900/vnc at IP address 10.11.12.13 I get no where. Netcat/tcping/nmap tests to port 5900 at IP address 10.11.12.13 all fail or show the port closed, etc. After I log into this web portal I still only have one IP address, the same network adapter as before, same routing table, and so on. However, netcat/tcping/nmap show port 5900 on 10.11.12.13 as open an listening, and I can successfully connect with a VNC client, all without adding a network adapter/IP address/routing table entry/etc. How does that magic work?
I guess that’s more of a Microsoft Windows question than networking, but I’m very curious. I thought I was starting to gain an intermediate level understanding of networking only to have something like this pop up and show me there’s a whole other world I didn’t know anything about.
That’s what I’m talking about in my post, there is no difference in the output of “ipconfig /all” and “route print” before I log in vs. after I log into the web portal.
It doesn’t need to for just remote desktop, it can use a java client and tunnel RDP over SSL and it sounds like OP is doing that.
Great information, this definitely gives me some key terms and names of technologies that I can search and read up on. Thanks!
One of our customers has a Pulse web page with the click-able links. But another customer has a Pulse web page and I can access our remote devices using the native VNC.exe or mstsc.exe on my local computer. That’s the one that’s basically sorcery to me right now and I’m trying to read up on and understand.
Yes, there were about 2-3 components it installed, a “host checker” and a couple of others. I’m sure it’s those components that are making this magic happen, I’m just trying to understand how they doit.
What I meant was that after I log into their web portal, my machine does not receive an additional IP address, gateway, and network route. Yet I’m still able to connect to the remote machines. I don’t understand how…
Nope. You’re thinking of the Junos Pulse Client, which had an IPSEC option used to terminate a VPN on the SRX.
This is something completely different, as it does not require a full blown SSLVPN/IPSEC VPN tunnel to access features. You can essentially proxy web sites, file shares, terminal services, and Citrix apps all from a web browser - no client needed.
If you’re using VNC as well, what you’re describing is likely WSAM then. Do you see a little gear icon in your systray when you login?
So how this works on WSAM is through an interface called Transport Driver Interface (TDI). TDI allows WSAM hook into the network stack via a driver addition.
From there, the WSAM application is configured to watch either a destination address/port, or a particular application (like MS-RDP Client or VNC). Based on the process name (optionally a process that matches a specific md5 hash) or destination address TDI intercepts the traffic before it follows the PC’s routing table, encapsulates it in SSL, and forwards the SSL-encrypted traffic to the VPN appliance, following the normal routing rules. From there, the SSLVPN decrypts the packet and sends the traffic to the proper server.
JSAM, OTOH is compatible with Windows/Linux/Unix/OSX and uses Java as the main routing component. JSAM will modify the routing table to send traffic (usually on a modified loopback address) down a one-way tunnel. So instead of connecting to 10.11.12.13:5900, you would connect to 127.0.0.2:5900. Due to the differences in OS’s we can only match destination address/port and not individual processes. This is kind of a pain in the ass, but when used in specific functions it’s pretty awesome.
For example, Citrix NFuse is a great use case - JSAM sets up loopback addresses which matches the Citrix MetaFrame Servers, and the ICA files presented by NFuse are rewritten by the SSLVPN’s rewriting engine to connect to the loopback address instead of the actual address of the MetaFrame Server.
The other customer that you can use applications on your local PC is using the SSL VPN function. You should have an IP address on their network when you connect to them.
