05-05-2013 10:37 AM - edited 05-05-2013 03:08 PM
Since I know BlackBerry personnel read this forum.....
There is this problem with Remote File Access where if you're on a carrier (Cell) connection and bring up the VPN it stops working. I have been trying to figure out why and I think I've determined the problem.
In short it appears that BlackBerry is using a tunnel internally to connect the phone and the PC. This means that the phone and PC have to have some means of mediating the endpoints, especially if they're using UDP for transport. After digging around some I've made a few discoveries that may bear on this.
It works (now) in my environment on the local LAN with the VPN on the phone turned on (!), which I had to screw with for a while to get to operate. It will NOT show me the files on Cellular with the VPN enabled, but will if it's not. I am using IKEv2 (through my own gateway). This problem is not related to a firewall ruleset as when I turn verbose firewall logging on I discover nothing in the logs.
This is likely related to another issue I discovered -- if you have a DHCP'd phone on the local LAN that is using 192.168.1.x/24 and bring up the VPN everything on that subnet disappears! I cannot see (accurately) the route tables that the phone has as there's no way to shell into the OS with it locked down, but the problem is local in the phone's routing table as I cannot find any packet originated from the phone's address (tunnelled or not) anywhere on the LAN with a packet sniffer which means it is not being transmitted at all. The phone instantly replies with a "not reachable" from the browser which tends to confirm this -- the routing entry for the host address is black-holed on the phone end.
Windows 7 clients with the same IKEv2 VPN connection do not do this, and I can look at their routing tables. The reason they don't do it is that the source routing table entries for the WiFi connection remain active.
That is, if the interface is named "wifi0" I have this (effectively) on the Win7 box after bringing up the VPN:
0.0.0.0 ---> [tunnel ip]
192.168.1.0/24 --> wifi0
As such access to the local LAN segment remains available. This is not true for BB10 devices and I suspect it's also what is going wrong with RFA when a VPN is active.
When you try to initiate a RFA over the VPN the following gets logged on the PC side:
09:04:17.010803 IP Karl-Desktop.Denninger.net.49229 > 68-171-241-194.rdns.blackberry.net.https: Flags [P.], seq 48:180, ack 1, win 16425, length 132
09:04:17.070271 IP 68-171-241-194.rdns.blackberry.net.https > Karl-Desktop.Denninger.net.49229: Flags [.], ack 180, win 501, length 0
I suspect what's going on is that the BlackBerry servers are trying to determine the current IP of the phone and server and they get the non-VPN'd address (that is, NOT the tunnel) for the phone. As a result the operation fails and my operating theory right now for "why" is below.
BlackBerry could fix this by having the RFA look at the tunnel's routing table entries as sent by the VPN server; if it finds a default route then it would presume that the user's intent is to "tunnel all" and the proper place to direct the RFA is the other (remote) end of the tunnel. If it does not then it presumes that the user's intent is to tunnel only the corporate access and therefore electing the original remote end is correct.
But that only solves the RFA problem. A better (IMHO) option would be to do what Windows 7 does when a VPN is active, because the disablement of access to the subnet you're attached to is a material bad thing. It is particularly troublesome where you configure VPN connectivity to "autostart" because if you do that and then do NOT apply the VPN to the WiFi link for your office the phone will elect to run all its data over the (Secured) Cell Connection rather than the WiFi link at the office! If you DO elect to apply the VPN connectivty to the office connection then you have to make sure the phone gets an IP Address from a DIFFERENT address block than anything that you want to be "visible" when the VPN is up and the phone and your gateway both get to process utterly unnecessary traffic (burning battery life and CPU cycles in the case of the gateway) mediating that which is already secure (assuming an AES-encrypted WiFi connection, which WPA2 is.)
Treating the routing table as Win7 does might also fix the problem for RFA over a cell connection with the VPN up. If not then BlackBerry should have the RFA code on the phone look at the route(s) sent down with the VPN when it comes up and determine intent by whether or not a default route (0.0.0.0) is present.
In addition BlackBerry needs to add an option to the VPN selector for WiFi connections that tells the phone "This connection is secure, treat it AS IF VPN was enabled (for "auto-connect" purposes) but do not bring up the VPN."
When one is on the inside WiFi network at your company running AES encryption on the WiFi link you definitely do not need the VPN active into the same place! That does nothing other than waste battery power and CPU cycles along with severely complicating routing setup.
05-05-2013 03:09 PM
To BB employees -- please note last paragraph I just added in clarification