FortiClient VPN Problems With OSX 10.11 El Capitan

[danjahner]

I installed the GM candidate of Mac OS X 10.11 El Capitan and my FortiClient VPN has stopped working. It completes the login, but after connection, no data is transferred - the incoming and outgoing freeze. It is a split tunnel connection and neither network or internet traffic works. 

I tried disabling the firewall and System Integrity Protection, but neither had any effect. 

[lzs · Accepted solution]

I've been trying since the first public beta, and now on the final GM Candidate. The VPN problem is there. Basically, what is wrong is that OS X's resolver is sending traffic out through the primary (original) network interface, even though the route table correctly shows that the VPN tunnel (ppp0) should be used.

When you use a command like nslookup, the DNS traffic goes through the VPN tunnel (ppp0) properly.

DNS name resolution  fails because my VPN client is told to use my corporate DNS server, but my corporate DNS server refuses to serve name queries from outside the corporate network. When the FortiClient VPN is connected, OS X's name resolution traffic arrives at the DNS server with the client's public Internet IP address, and hence is refused by my DNS server.

Technically, this looks like an OS X bug. Or, perhaps there really is something wrong that FortiClient is dong. Either way, I hope FortiNet can rectify or take it up with Apple to fix El Capitan.

[Sridhar · Accepted solution]

Facing the same issue. Latest FortiClient(5.3*) did not fix it.

But, FortiClient 4.0.2082 did not have any such issues(though it occasionally stops tunneling on its own).

Waiting for a fix like everyone, but 4.0.2082 is letting me work for time being.

[hansbogert · Accepted solution]

I've gotten it to "work" by getting the DNS to use ppp0 and some route magic. Explanation is on: http://serverfault.com/questions/728702/how-to-get-forticlient-working-in-osx-el-capitan/728707#7287...

Let's hope either party fixes this, because running scripts after establishing VPN is quite cumbersome.

[Chris_Lin_FTNT · Accepted solution]

There is a new private build here:

https://dl.dropboxusercontent.com/u/58793690/mac/FortiClient_5.4.0.493_macosx.dmg

Would you guys give it a try?

[kevinboos · Accepted solution]

Chris.Lin wrote:

There is a new private build here:

https://dl.dropboxusercontent.com/u/58793690/mac/FortiClient_5.4.0.493_macosx.dmg

Would you guys give it a try?

It works for now! Thanks!

[tommy765 · Accepted solution]

Just ran El Capitan updates and it still does not work - bummer

[shenight · Accepted solution]

Chris.Lin wrote:

Here is another interim build b499.

https://dl.dropboxusercontent.com/u/58793690/mac/FortiClient_5.4.0.499_macosx.dmg

5.4.1 release may be available at the end of February.

P.S. b493 from previous post is different from the official 5.4.0 b493. Developer made the change after 5.4.0 was released.

Thanks ! I had same problems that other people since 3 months with forticlient and this new build fixes the issue!!! Great job!

[Chris_Lin_FTNT · Accepted solution]

Try this. A more recent build.

https://www.dropbox.com/s...bpx1VjzYAmiK00S9a?dl=0

[brudy]

Hi there

I did investigate a little bit more. The problem is that the DNS server associated with the tunnel is not associated to ppp0, but (in my case) to en0 and therefore does not route the traffic into the tunnel. So DNS requests for the SSL VPN nameserver leave the system using the regular interface. 

1. The Query never reaches the server

2. It leaves with the wrong source address

The funny thing is, that using the command dig gives the right results.

"scutil --dns" shows how the Mac resolve names.

As long as I connect using IP addresses, the tunnel works.

I'm using 5.2.4.377

[logimano]

brudy wrote:

Hi there

I did investigate a little bit more. The problem is that the DNS server associated with the tunnel is not associated to ppp0, but (in my case) to en0 and therefore does not route the traffic into the tunnel. So DNS requests for the SSL VPN nameserver leave the system using the regular interface. 

1. The Query never reaches the server

2. It leaves with the wrong source address

The funny thing is, that using the command dig gives the right results.

"scutil --dns" shows how the Mac resolve names.

As long as I connect using IP addresses, the tunnel works.

I'm using 5.2.4.377

Same thing with 5.2.3.370!

[brudy]

I just tried El Capitan with the built in Cisco IPSec VPN client. Same behavior. IP does work, DNS fails. 

In this case no 3rd party software is involved. It is pure Mac. Looks like the problem needs to fixed in El Capitan and not in the FortiClient.

[brudy]

Some more Tests:

Routing all traffic into the tunnel solves the problem.

Using FortiClient without split tunnel does work. Maybe not the best solution, but at least a work around. Better than no VPN at all.

[logimano]

brudy wrote:

Some more Tests:

Routing all traffic into the tunnel solves the problem.

Using FortiClient without split tunnel does work. Maybe not the best solution, but at least a work around. Better than no VPN at all.

Could you help me with that? How can I route all traffic into the tunnel with Mac OS X?

[brudy]

You have to specify it in the Portal. 

On your Fortigate: VPN -> SSL -> Portal: there you remove "split tunnel". On the IPv4 policy you accept destination "all" traffic to the inside.

In this case you have to create a policy from "ssl.root to wan" destination "all" too, to allow outgoing traffic to the Internet. Here you must not forget to set NAT.

[logimano]

Thanks, brudy. But I do not have any access to the Portal/Fortigate.

Is there any work around for FortiClient only?

[brudy]

you can create manually a default route on your Mac, which directs all traffic into your tunnel interface.

on the Mac you run: 

"sudo route add default -interface ppp0"

That forces all your traffic into the tunnel. In this case you have to be aware, that conneting to some sites on the internet will fail, if the Forti is not configured accordingly.

[logimano]

Thanks for all the help. If I type:

sudo /sbin/route add default -interface ppp0

I get the following result:

route: writing to routing socket: File exists add net default: gateway ppp0: File exists

ifconfig -a states:

...

ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1354 inet .....IP-ADRESS...... --> 1.1.1.1 netmask 0xff000000

[brudy]

In this case you already send all your traffic into the tunnel.

can you do a "netstat -rn" then you should see 2 times default. One going to your real gateway and another going to your ppp0 interface.