Pulse Secure VPN on openSUSE

Bump to hopefully hear how galerkin1 is doing with his/her setup and hopefully to get some more eyes on this. I still haven’t figured out what I need to get past “reason 6”. Anyone have Pulse Secure Client working on another distro that could provide some insights on open ports needed?

Thanks!

You should do what the kb article suggests to first narrow down which app is causing the problem…

Test…
Any AV app
The firewall (You can easily turn off the FW using YAST)
Any other kind of malware app you may be running.

On a Linux box, most people don’t run AV or other malware protection, so it’s likely your main focus should be to disable your firewall and then try to connect. If you are successful, then you you haven’t opened the necessary FW ports. If you still can’t connect, then you know you have some additional problem.

A quick Google search doesn’t seem to return any hits simply querying for ports to be open, but at least one kb article says that early negotiation may be over ports 80 and 443, and optionally (or default?) the actual VPN is IPSEC. If that is the case then you can look up those default ports… IIRC there are a great many ports that might need to be opened.

TSU

I used YaST to turn off the firewall.

I relaunched /usr/local/pulse/pulseUi from the commandline and got the same error message, “reason = 6”. This was done as a normal user.

As superuser, I did the same and no error messages. It didn’t work either, though. Perhaps the error messages didn’t go to console?

I guess I have an additional problem, but without error messages, it’s difficult to debug… :frowning:

You’ll have to trace the process how the Pulse VPN sets up (hopefully there’s documentation, but it’s pretty sparse).
Many VPNs set up as a system configuration which means that it does require elevated (ie root, possibly sudo) permissions.

Again, depending on the type of VPN that is set up, yes you will have to open the required ports to allow the VPN to work.
But, the VPN has to work with the firewall disabled first.

I don’t personally use the Pulse VPN myself, so you’ll have to look for Pulse troubleshooting documentation to find what you can and should do.

TSU

I ended up abandoning trying to use the Pulse Secure Client software. Pulse Secure only support RedHat/centOS/Ubuntu and there is no direct help from them if you’re just a user and not the entity that licenses their software.

Thankfully, there’s an open source solution that works for me: openconnect

As of 7.05, openconnect started supporting Pulse Secure, aka Juniper, with the --juniper flag. Leap 42.1 is distributed with 7.06. Unfortunately, I needed a later version that fixes some bugs with connecting to Pulse Secure 8.2R5 my office is using. I searched and downloaded the latest source from here:

http://www.infradead.org/openconnect/download.html

The latest was 7.08. The build was easy, “configure” and “make”, for the most part. The configure part required installing a few packages for configure to complete. The make produced the working openconnect 7.08.

Logging into my company’s VPN requires two-factor authentication that uses a web interface. The Pulse Secure Client can display this interface but openconnect can not. It doesn’t know what to do with the web code sent to it. Since my logins are infrequent and I just need to get things going, I opted for a method where I log in via a web browser and then pass the DSID to openconnect. This idea can be found here:

http://www.blackhillsinfosec.com/?p=5075

  1. launch web browser (Browser needs to be non-private mode and accepts cookies.)

  2. go to company’s VPN website, i.e. company.com

  3. enter credentials and second factor authentication

  4. use web browser’s cookie manager to find listing for company’s VPN website and find the DSID cookie (On Firefox, Edit->Preferences/Privacy/Show Cookies…)

  5. copy the cookie value, which looks like this: 0362a06626eb1dd725da5cb10dda717c

  6. pass the cookie to openconnect to use the VPN:

    (as superuser/root)
    openconnect --juniper -C “DSID=0362a06626eb1dd725da5cb10dda717c” company.com

    (Make sure you’re using the compiled openconnect and not the distributed one.)

    WARNING: Juniper Network Connect support is experimental.
    It will probably be superseded by Junos Pulse support.
    Connected to xxx.xx.xx.xxx:443
    SSL negotiation with company.com
    Connected to HTTPS on company.com
    Connected as xxx.xx.xx.xx, using SSL
    dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched…
    dns-resolver: You can find my version in /etc/resolv.conf.netconfig
    ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched…
    You can find my version in /etc/resolv.conf.netconfig …
    ESP session established with server

  7. to check if things are working, i.e. if you’ve successfully added the VPN…

    (as superuser/root)
    route

    which should show some IP addresses with Iface “tun0”

That should be it.

In my case, /etc/resolv.conf didn’t get updated properly to handle looking up machines on the company network. The DNS wasn’t working.

To fix this, I added the “-v” (verbose) flag to the openconnect command:

openconnect --juniper -v -C “DSID=0362a06626eb1dd725da5cb10dda717c” company.com

The output in the console will be much more detailed and the DNS “servers” and “search domains” will be revealed. Look for “Received DNS” lines in the output, like this:

Received DNS server xx.xxx.xxx.xx
Received DNS server xx.xx.xx.xxx
Received DNS search domain company.com,remote.company.com

Add these to /etc/resolv.conf:

search company.com remote.company.com
(other search)
nameserver xx.xxx.xxx.xx
nameserver xx.xx.xx.xxx
(other nameserver)

Save and test with nslookup:

nslookup computer.company.com

If it works, you should see the Name and Address of the computer you’re trying to reach.

Hope this is helpful!