I purchased the Jetpack 8800L specifically because it is advertised as supporting a built-in OpenVPN client. At a remote location, I have a security camera and other devices that I want to attach over vpn back to the home office's private network.
I got it all setup with the configuration files from my VPN server loaded onto the 8800L through the "advanced" screen. It all seems to work and it connects up to my VPN server without any apparent issues or errors in the log, etc..
However, although I see in the VPN log that it accepts the pushed routes from my VPN server, it does not appear to be routing. For example, I see that the Jetpack is assigned an IP address of 10.8.0.7 by the VPN server. When I connect to the Jetpack's WIFI with my laptop, I can ping 10.8.0.7 just fine, but I cannot ping the VPN server on the other side of the tunnel (10.8.0.1), nor can I ping anything else either on the private network nor the internet.
The VPN server is configured correctly and the same configuration works fine with multiple clients, including the same laptop when connected directly using it's own VPN cleint. The only "difference" really is that I configured the LAN on the Jetpack to use a different subnet (10.9.0.0/24) and also configured the VPN server to route that new subnet. On the jetpack side that part seems to be at least somewhat working. When I connect to the Jetpack's WIFI, I am assigned a DHCP address on the 10.9.0.0/24 subnet, and I can ping the Jetpack both on 10.9.0.1 and 10.8.0.7, but as I said I cannot ping anything on the other side of the tunnel.
I called Verizon "technical" support and after several hours (no exageration) of waiting on hold, the last person I talked to straight up told me that he couldn't help me, and that he didn't even have a way to escalate my issue and open a ticket because "VPN is not an option on the pull-down in my ticket applicatiion". Perfect.
Anybody else have this built-in VPN client working and/or know the secret? Otherwise, I will just have to return it and figure something else out, as it is useless to me butt is.
Awesome, I was not aware they were delivering Jetpacks with VPN clients built in. This would resolve a lot of problems with the VZW NAT Firewall if it works correctly. Though I still suspect that Jetpacks will not function very well as a 24x7 connection device as they always have. Hopefully the auto connect feature is effective enough to survive the various reboot and restart situations that Jetpacks have always struggled with in the past compared to other devices like 4G LTE routers and USB modems.
Looking over the User Guide it seems that you have completed a connection to the VPN Server correctly. The status should tell you right away if you connected to the VPN server or not. I suspect that is not the issue for your case.
Once you are connected to the VPN server the VZW network is effectively removed from the situation. All communication is now dependant on the configuration between VPN client and VPN server.
Custom subnets have caused issued with Jetpacks on previous models. Jetpacks usually default to 192.168.x.x instead of 10.x.x.x. Although manufacturers provide the functionality to change subnets but they dont really work outside of the defaults. Try resetting this area back to the defaults and see if it helps.
LAN configurations wouldnt normally be a problem unless the VPN server was configured to disable LAN connections from the VPN client (your jetpack). Our corporate Cisco VPN client disables local network resources as a security feature. Only the IP of the VPN client is allowed to communicate we dont allow our VPN clients to share connectivity with other devices by policy. This is something to check into with your OpenVPN Server. I suspect in all of your other cases the VPN client is installed directly onto the intended device so LAN resources from those devices are not necessary.
Another clue would be to see if your VPN Server can ping one of the VPN connected clients after a connection. This may help us confirm how the VPN server sees your Jetpack connected devices, as a unique device with its own IP, or as an extension of the Jetpacks IP through a port. I would expect that a properly connected PC would have both an IP address from the LAN under 10.9.0.0 and a VPN server IP under 10.8.0.0 at the same time. If so then clients must force traffic to go through the 10.8.0.0 connection for WAN or other VPN server resources.
Also, check out your Port Filtering area under the Advanced Menu of the Jetpacks admin page. I would suspect that you would want port filtering turned Off from the Jetpack as the more effective port filtering will apply from the VPN Server.
Let us know what you can find out while we explore this new feature.
> I would expect that a properly connected PC would have both an IP address from the LAN under 10.9.0.0 and a VPN server IP under 10.8.0.0 at the same time.
I suppose this statement does not apply as the Jetpack connected client in this situation does not have a virtual network adapter for the VPN client. All the Jetpack connected client would have is a single IP Address from the Jetpack.
I stumbled across this post with a similar question:
The OP writes that he configured each device for VPN access and is attempting to update the MiFi so that it will do it for him. This feeds my theory that normal DHCP from the jetpack is not enough to route clients into the VPN Server. Additional configuration on the Jetpack connected client like static IP, subnet and default gateways may be necessary for them to communicate with VPN server resources.
LAN configurations wouldnt normally be a problem unless the VPN server was configured to disable LAN connections from the VPN client (your jetpack).
Another clue would be to see if your VPN Server can ping one of the VPN connected clients after a connection. Also, check out your Port Filtering area under the Advanced Menu of the Jetpacks admin page. I would suspect that you would want port filtering turned Off from the Jetpack as the more effective port filtering will apply from the VPN Server.
II have the LAN on the server side setup to accept, route and NAT the new subnet (10.9.0.0/24), so that should not be a problem. From the server I can NOT ping the jetpack on 10.8.0.7 or 10.9.0.1, although I can ping other VPN clients that are directly connected (not through the jetpack).
When connected to the jetpack's WIFI I can ping the jetpack on either 10.8.0.7 or 10.9.0.1, but not the VPN server or anything on the other side. Attempting to run a traceroute to 10.8.0.1 (the vpn server) shows it going to 10.9.0.1 (the jetpack) and then nothing after that.
I don't have anything in port forwarding or filtering configured on the jetpack, and per the user guide as well as hints printed on those config screens, these options are ignored anyway when using VPN.
It's almost as if they have ip forwarding disabled on the jetpack. But if that's the case, its hard to see what use the built-in VPN client would actually serve?
I have sent an email to inseego (the manufacturer) technical support....will see if I get an answer.
burrm, I appreciate the details you've provided. To confirm, have you tried removing and reloading your VPN files? Looking forward to hearing back.
Hi, I was able to get mine to work after changing my config from this
Partially-related question: what format did you use to upload your VPN config files? I keep getting an error when I upload .ovpn or .zip files generated by Mullvad VPN.
Thanks in advance for any guidance!
We want to make sure your service is working as you wish, brianchernish. What issues are you running into specifically? When did they begin? -ChrisM_VZW
Which configuration file extensions are accepted by the Jetpack 8800L to configure the VPN? .ovpn does not seem to be supported and I cannot locate any documentation to understand which formats are supported.