-chuck-
asked on
Traffic Stops Passing over Juniper SSL VPN from Verizon Wireless 4G LTE Client using CradlePoint Router
Any suggestions are greatly appreciated.
My issue is as follows:
My setup:
CradlePoint MBR1400 router firmware v. 4.4.0 hardware v. 2.0. Ethernet connection to Laptop running Windows 7 Enterprise SP1 as user (no admin rights). I have tried two modems: the CradlePoint MC200LE-VZ firmware v.03.05.10.09 and a Pantech. ISP is Verizon Wireless. I have the Sure Call direct amplifier and I have tried both the SureCall omni & Wilson panel directional antennas. I believe I can pick up signals from two towers about 100 degrees apart. In all antenna/amp setups the signal is strong 4G LTE (RSSI:-42; but SINR fluctuates quite a bit: 1-9). Router is currently in "Force 4G LTE" mode which seems to perform the best. When not connected to the VPN, speedtest.net generally reports 10-15 Mbps up & down w/ 35-40ms ping. The Laptop is connecting to a Juniper Network Connect SSL VPN v.7.3 via Internet Explorer v. 9.0.x.
My symptoms:
VPN connects initially, runs a login script (slower than I would like but it is slow imo even on my previous 100Mbps Fios package). All systems that rely on the VPN work fine for either a few minutes or a few hours. At some point the VPN "stalls," meaning it appears to remain connected according to the icon in the system tray and the web browser but traffic does not pass. (by traffic I mean connections to Network Shares, various databases (over http), MS Lync/Cisco UC, MS Exchange (via MS Outlook) & Internet)
My discussions with CradlePoint & my internal tech support:
According to the VPN tech, the Juniper VPN should support 4G connections starting with v. 7.1. He said NAT'd devices should not be a problem. However, other 4G users have experienced problems, so much so that they are considering banning use of the technology altogether (in other words: I'm on my own to figure this out). CradlePoint support has been a bit all over the place. First they said lower MTU, then they said I must make VPN settings on the CP match the VPN settings on Juniper. That didn't make any sense to the VPN tech because the CP was asking for all sorts of settings I'm told the Juniper SSL VPN doesn't use. I think that setup is for a router-to-router VPN but I'm not really sure--I don't know the settings to try it. Then CP told me to enable static NAT. I told them that option wasn't in my firmware version. So, CP sent me a rolled back firmware. However, the router rejected it as incompatible with my hardware version. I have sent everyone log files for everything and no one has been able to pinpoint the issue. Although, the log files do appear to contain various errors & warnings. I don't really know enough to be able to interpret them. I would post them, but I'm not sure if they contain sensitive information that should not be distributed.
My present workaround:
There seems to be two issues: one, the connection drops; two, the VPN does not recognize the drop and reconnect. I think I am manually fixing the second issue by executing a one-line command (...cmd.exe /c ipconfig /release *9) to force the (virtual?) adapter to release the VPN IP assigned. This prompts Network Connect to ask if I want to reconnect to the VPN and I click yes and it does. So, there does not appear to be an interruption in Internet service. However, if I'm on a VOIP (MS Lync) phone call, I can't make the reconnect happen fast enough for the other party not to hang up thinking the call is dropped (if they wait around the call will usually resume).
Things I've tried
Outdoor antenna & amplifier. When I first tried the directional antenna it worked for two full days with no stalls so I thought it might have just been a signal strength or tower switching issue. Then the next time I tried it, it would not connect to the Internet at all and reported Carrier:Down. I replaced the directional antenna with the omni. I also inserted the amp. But, all that just left me back where I started.
I believe that I have verified that there is no IP change associated with the stall (thinking it might be NAT issue).
On the Router I have tried:
Lowering MTU
Port forwarding & IP protocol filter (according to Juniper VPN guide)
Force LTE mode, Force 3G mode
Disable IPv6
Active/Static DNS (opendns)
Toggle Force DNS through router
IP reservation for laptop
DMZ for laptop
Active Ping failure check mode
Toggle on Demand mode
Toggle aggressive reset mode
Toggle Force NAT mode
Toggle Standard/NAT/IP passthrough mode
Please let me know if I can provide any further information.
Thanks for any suggestions.
My issue is as follows:
My setup:
CradlePoint MBR1400 router firmware v. 4.4.0 hardware v. 2.0. Ethernet connection to Laptop running Windows 7 Enterprise SP1 as user (no admin rights). I have tried two modems: the CradlePoint MC200LE-VZ firmware v.03.05.10.09 and a Pantech. ISP is Verizon Wireless. I have the Sure Call direct amplifier and I have tried both the SureCall omni & Wilson panel directional antennas. I believe I can pick up signals from two towers about 100 degrees apart. In all antenna/amp setups the signal is strong 4G LTE (RSSI:-42; but SINR fluctuates quite a bit: 1-9). Router is currently in "Force 4G LTE" mode which seems to perform the best. When not connected to the VPN, speedtest.net generally reports 10-15 Mbps up & down w/ 35-40ms ping. The Laptop is connecting to a Juniper Network Connect SSL VPN v.7.3 via Internet Explorer v. 9.0.x.
My symptoms:
VPN connects initially, runs a login script (slower than I would like but it is slow imo even on my previous 100Mbps Fios package). All systems that rely on the VPN work fine for either a few minutes or a few hours. At some point the VPN "stalls," meaning it appears to remain connected according to the icon in the system tray and the web browser but traffic does not pass. (by traffic I mean connections to Network Shares, various databases (over http), MS Lync/Cisco UC, MS Exchange (via MS Outlook) & Internet)
My discussions with CradlePoint & my internal tech support:
According to the VPN tech, the Juniper VPN should support 4G connections starting with v. 7.1. He said NAT'd devices should not be a problem. However, other 4G users have experienced problems, so much so that they are considering banning use of the technology altogether (in other words: I'm on my own to figure this out). CradlePoint support has been a bit all over the place. First they said lower MTU, then they said I must make VPN settings on the CP match the VPN settings on Juniper. That didn't make any sense to the VPN tech because the CP was asking for all sorts of settings I'm told the Juniper SSL VPN doesn't use. I think that setup is for a router-to-router VPN but I'm not really sure--I don't know the settings to try it. Then CP told me to enable static NAT. I told them that option wasn't in my firmware version. So, CP sent me a rolled back firmware. However, the router rejected it as incompatible with my hardware version. I have sent everyone log files for everything and no one has been able to pinpoint the issue. Although, the log files do appear to contain various errors & warnings. I don't really know enough to be able to interpret them. I would post them, but I'm not sure if they contain sensitive information that should not be distributed.
My present workaround:
There seems to be two issues: one, the connection drops; two, the VPN does not recognize the drop and reconnect. I think I am manually fixing the second issue by executing a one-line command (...cmd.exe /c ipconfig /release *9) to force the (virtual?) adapter to release the VPN IP assigned. This prompts Network Connect to ask if I want to reconnect to the VPN and I click yes and it does. So, there does not appear to be an interruption in Internet service. However, if I'm on a VOIP (MS Lync) phone call, I can't make the reconnect happen fast enough for the other party not to hang up thinking the call is dropped (if they wait around the call will usually resume).
Things I've tried
Outdoor antenna & amplifier. When I first tried the directional antenna it worked for two full days with no stalls so I thought it might have just been a signal strength or tower switching issue. Then the next time I tried it, it would not connect to the Internet at all and reported Carrier:Down. I replaced the directional antenna with the omni. I also inserted the amp. But, all that just left me back where I started.
I believe that I have verified that there is no IP change associated with the stall (thinking it might be NAT issue).
On the Router I have tried:
Lowering MTU
Port forwarding & IP protocol filter (according to Juniper VPN guide)
Force LTE mode, Force 3G mode
Disable IPv6
Active/Static DNS (opendns)
Toggle Force DNS through router
IP reservation for laptop
DMZ for laptop
Active Ping failure check mode
Toggle on Demand mode
Toggle aggressive reset mode
Toggle Force NAT mode
Toggle Standard/NAT/IP passthrough mode
Please let me know if I can provide any further information.
Thanks for any suggestions.
ASKER
Thank you for your suggestion. As a user/client and not an admin, I don't have access to the server-side settings. I'm told that these types of settings were checked and the VPN should make reconnects when the dead connection is detected. But, maybe you are right in that the connection is not "dead enough" to try to reconnect.
I contacted the antenna vendor and she advised that my SINR should be above 7. I initially positioned the antennas for best RSSI. I have repositioned them and I'm getting 8-14 SINR and the RSSI has dropped only slightly. It has been working for about 4 hours today. I will research SINR/VPN issues and report back after some more time. (fingers crossed)
I contacted the antenna vendor and she advised that my SINR should be above 7. I initially positioned the antennas for best RSSI. I have repositioned them and I'm getting 8-14 SINR and the RSSI has dropped only slightly. It has been working for about 4 hours today. I will research SINR/VPN issues and report back after some more time. (fingers crossed)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Seems to be working now based on the suggestion from the antenna vendor to try to improve SINR
https://kb.juniper.net/InfoCenter/index?page=content&id=TN127