Workaround for Juniper VPN Split Tunneling Restriction
Split Tunneling is a networking concept which allows the user to access the corporate private network via the VPN link, and connect to the local LAN via the same or different interface. This service is usually facilitated through a program such as VPN client software application. One such application is the Juniper Network Connect.
Juniper VPN solution is also used at my workplace for secure remote access. The bad thing is that the Split Tunneling option is turned off by the administrator. With Split Tunneling turned off, the local LAN cannot be accessed during an active VPN session.
In the course of my work, I am often required to work on equipment located at our customer premises. As such, whenever I am on site, I always find it easier to connect to my company’s corporate network via VPN and at the same time, work on our customer equipment by connecting to their LAN switches. In this way, I am able to work on the equipment, check on my company’s knowledge base site for solutions, and respond to important emails, all at the same time. This however requires that Split Tunneling feature to be enabled.
Fortunately though, there is a workaround for Split Tunneling for Juniper VPN solutions. Read on…
Juniper Network Connect and the Routing Table Updates
Once the client successfully establishes a VPN session, it will add a conflicting route for all the existing routes. The new routes will have the route metric (cost of destination) value set to 1. The old original routes will have a route metric value bigger than 1. This will cause all the traffic to pass through the VPN tunnel. A route monitor will then monitor the routes for any changes. If a manual routing change is detected, it will immediately terminate the VPN session.
Bug in Juniper Network Connect VPN Client
Even though the route monitor process will monitor all the routes on the client PC, it will ignore route changes if the only change was the route’s metric. This bug is however fixed in Juniper Network Connect version 6.2R3-1 Build # 13687.
Workaround for Juniper Network Connect prior to version 6.2R3-1
To exploit the route metric bug, perform the following steps:
- Connect to LAN and configure the IP address and routes as required
- Connect to your corporate network using the Juniper Network Connect client
- Open a Command Prompt window with Administrator privileges
- Determine the Juniper Network Virtual Adapter Interface Index number
C:Windowssystem32>route print -4 =========================================================================== Interface List 24 ...xx xx xx xx xx xx ...... Juniper Network Connect Virtual Adapter 9 ...xx xx xx xx xx xx ...... Intel(R) PRO/Wireless 3945ABG Network Connection 8 ...xx xx xx xx xx xx ...... Broadcom NetXtreme Gigabit Ethernet ===========================================================================
The Index number is 24 in this case.
- Take a look at your routing table. It will have routes something like this:
C:Windowssystem32>route print -4 ... IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric ... 192.168.1.0 255.255.255.0 On-link 192.168.1.13 281 192.168.1.0 255.255.255.0 On-link x.x.x.x 1 => duplicate route pointing to VPN tunnel ... - Modify the 2nd route pointing to the VPN tunnel as follows:
C:Windowssystem32>route change 192.168.1.0 mask 255.255.255.0 x.x.x.x metric 9000 if 24 OK!
- You should be able to access the nodes on the 192.168.1.0/24 network now!
Workaround for Juniper Network Connect from version 6.2R3-1
As the bug is fixed from version 6.2 onwards, the Juniper Network Connect Service (note that this is not the client) needs to be downgraded or patched to allow route metric changes to be performed.
If you take a look at your Windows Services, you will find a service called “Juniper Network Connect Service” that will be installed together with the Juniper Network Connect client application.
To use the route metric workaround, the executable for the Windows Service has to be downgraded to a version prior to 6.2R3-1. The route metric workaround was still working when I tested with Juniper Network Connect client version 6.3.0 and Juniper Network Connect Service 5.5.0. Your mileage may vary.
If you are more adventurous, you can instead try to patch the Juniper Network Connect Service executable to make it assume that there are no routes to monitor. You may require a tool similar to the IDA Pro Disassembler to assist you in patching the executable.
Tips on patching the Juniper Network Connect Service
This tip is based on the version 6.3.0. It might differ for other versions.
- Generate assembly code for the executable using IDA Pro
- Search for a push instruction that references the string “no routes to monitor” and determine the function name
- Look for a conditional jump instruction before that instruction. This instruction has to be patched with the famous nop (No Operation) instruction or 0×90
- Locate the function in IDA Pro and determine the hexadecimal data surrounding the jump instruction
- Open the executable in a Hex Editor and search for the hexadecimal data and patch the jump instruction to 0×90
The service should now assume that there are no routes to monitor. As the program flow could change in the future, please only use the above guide as a general reference.
If you are using the VPN client on Linux or Mac OS, IDA Pro might still prove to be of some use to you.
Workaround for Juniper Network Connect version 6.4 and 6.5
I got a couple of mails requesting for help to get version 6.4 and 6.5 working, therefore I am adding this section. From version 6.4, Juniper has started using digital signatures for the Network Connect Service. Once the file is patched, you will get an invalid signature error.
To overcome that error, open IE and goto Tools -> Internet Options, and click on the ‘Advanced’ tab. Enable the option that says “Allow software to run or install even if the signature is invalid”.
There are also some routing table changes from version 6.4 onwards, which makes the routing changes a bit more harder (Juniper removes the directly connected routes). You can either opt to patch the Network Connect Service version 6.4 or 6.5 or you could just simply downgrade the Network Connect Service to version 6.3 instead. Downgrading to version 6.3 will get you back the route modification flexibility.
Update (2-Mar-2011): Added workarounds for Juniper VPN 6.4 and 6.5
DISCLAIMER: THE ABOVE ARTICLE IS MEANT FOR EDUCATIONAL PURPOSES ONLY. I DO NOT PROMOTE OR SUPPORT ANY KIND OF REVERSE ENGINEERING OF COPYRIGHTED MATERIAL OR CONTENTS. THIS IS JUST A PROOF OF CONCEPT AND I AM NOT RESPONSIBLE FOR ANY LEGAL ISSUES YOU ENCOUNTER IF YOU FOLLOW THE ABOVE GUIDES/INSTRUCTIONS. I AM NOT RESPONSIBLE OF ANY OUTCOME, LOST OF DATA OR ANY DAMAGES RESULTED DUE TO THE ACT OF YOU PROCEEDING WITH THE ABOVE GUIDES/INSTRUCTIONS.
| Tags | : bug, disassembly, juniper, network, patch, route monitor, split-tunneling, vpn, workaround |
Well written tutorial. Thanks. Works for me too
I used your suggestion to patch 6.5 with great success, unfortunately which specific build does not come to me right now (and I’m not at that computer). That was on the linux build. Going to try again with the MAC version now
Could someone help me with this? I’m using Network Connect 6.5, but my route table seems more complicated than the example. I ‘patched’ the service and then tried
route change 0.0.0.0 mask 0.0.0.0 x.x.10.125 metric 9000 if 13but that breaks the connection right away.Heres my ipv4 route table:
My local machine is 192.168.1.29, and my local gateway is 192.168.1.254
===========================================================================
Interface List
13…00 ff 10 d0 2b 0f ……Juniper Network Connect Virtual Adapter
11…48 5b 39 a7 3b 3d ……Realtek PCIe GBE Family Controller
1………………………Software Loopback Interface 1
12…00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
16…00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
15…00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 On-link x.x.10.125 1
x.x.10.125 255.255.255.255 On-link x.x.10.125 257
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
y.y.34.53 255.255.255.255 192.168.1.29 x.x.10.125 6
y.y.34.53 255.255.255.255 192.168.1.254 192.168.1.29 5
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link x.x.10.125 257
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.29 258
255.255.255.255 255.255.255.255 On-link x.x.10.125 257
===========================================================================
Persistent Routes:
None
Someguy: I do not quite see the situation behing such route change – could you explain it a bit?
In my case I am just adding new route and it works perfectly.
Took me days to figure out, but first discovered I had patched wrong (was confused between address and offset in IDA and probably changed wrong location in hex editor).
By the way – version 6.5.0.15507 patch for me was
C:\Program Files (x86)\Juniper Networks\Common Files\dsNcService.exe
Offset 148A3: 75 to 90
Offset 148A4: 3A to 90
Once that was done, just had to find a combination of routes that worked for me (will likely be different for every company)
route delete 0.0.0.0
route delete y.y.34.53
route add 0.0.0.0 mask 0.0.0.0 192.168.1.254 metric 100 if 10
route add x.0.0.0 mask 255.0.0.0 0.0.0.0 metric 5 if 12
route add mask 255.255.255.255 0.0.0.0 metric 5 if 12
route add mask 255.255.255.255 0.0.0.0 metric 5 if 12
I couldn’t figure out how to have 2 default routes, so I got rid of the juniper default route, made my local network the default route with a metric of 100, and then mapped the specific corporate resources I need with a lower metric for priority.
I’m still new to route tables, so if you see a simpler way please let me know.
- Rob
Mine solution was a bit different: after a patch I have just added a route to my local network and I am using a http proxy server on ddwrt router to redirect ordinary traffic away from vpn gateway…
Hi all,
I tryied patching version 6.5.0.14599 (Offset 147FE, 147FF) and I did not work. It says “digital certification issue”. Anybody can help me? Thanks
@MtR, the article has been updated to include the digital certificate issue. please do check if it helps you.
Good update. Just to clarify if anyone isn’t that familiar with the assembly language, in step 3 of the patching instructions, the Jump instruction uses 2 bytes (1 ‘word’) so you actually change 2 consecutive blocks in the hex editor to the nop command (which is 1 byte)… so you will end up with 90 90.
I am still fine tuning my route table to work with NC 6.5, I had to come up with a script to run right after connecting and another script to run after disconnecting. I’m also experimenting with persistent routes. My question is: does the route with the lowest metric always take priority – regardless of the route type (default route vs specific route)? I am confused how anything gets past the Juniper default of 0.0.0.0 0.0.0.0 On-link x.x.10.125 1 – which seems to indicate that all network resources can be found within the immediate network with no gateway required.
The problem is when “Allow software to run or install even if the signature is invalid” is disabled by a policy
Thanks for really great instructions, was very, very helpful. Now I can normally split routing as I wish. There are some things to add here for some less ‘technical’ people, and some that don’t know ASM (like me).
1. There is no bug i NC version 5.4.0.11621. This version should be also patched.
2. Under XP interface numbers are hexadecimal, so we can use interface name ex. 0×1005 not 24. Also -4 switch does not work. To display interface list we need to add any number after ‘route print’, like ‘route print 4′.
3. File can be patched also using OllyDbg – it’s freeware windows debugger. Simple steps to do this (in version 2.0):
– open a file (dsNcService.exe)
– right click on the code, and select ‘Search for -> All referenced strings’
– new window should appear – find there string ‘no routes to monitor’ using default CTRL+F combination
– after localizing double click line containing this string
– now you are placed at the code again
– search for JNE instruction before occurrence of that string. Please note that there can be some JE before. DO NOT edit that jump, but JNE one.
– right-click on JNE instruction – select ‘Edit -> Fill with NOPs’
– this should leave two NOP instructions instead of JNE one
– now select all the code (for example going to the top of it using HOME, and then while holding SHIFT tap END key
– right click on the selection and ‘Edit -> copy to executable’
– new window should appear
– right-click there and select ‘save to file’ – select desired name (dsNcService.exe – after backing up the original one!), and click save
4. There is NOTHING about this in tutorial above, but you have to go to Windows Services (start -> run -> services.msc) and RESTART Juniper network connect service. Without it there are no changes applied, since reboot…
Best regards
I’m slowly becoming more knowledgable on the subject… My latest struggle has been with DNS – I can’t seem to find the right settings so that the correct DNS server (or network broadcast) is used.
For instance I have a wireless printer on my local network named PRINTER7840 (no domain name as far as I am aware). When I am not VPN’d I can ping PRINTER7840. Once I run Juniper and run my split tunnel script, pinging PRINTER7840 becomes ‘pinging PRINTER7840.corporate.domain’ because of the append DNS suffix settings in TCP/IP config probably, obviously the printer is not on the corporate network and is not reachable. If I remove that suffix however, I can ping PRINTER7840 but not SOMESERVER (SOMESERVER.corporpate.domain) without specifying the fully qualified domain name.
Any ideas how to set this up correctly?
Has anyone gotten it to work in 7.0 ? I cant seem to locate the string no routes to monitor. Nor do I know if 6.5 would work because I have no idea where I can download the client. Seems like its a cab file and I havent found a hosted version of an exe.
@Daniel, I managed to get 7.0.0.18107 working. Drop me a message via the feedback form or the Facebook page and I can mail you a copy if necessary.
Great post.
Is there any way to get any of that fixed versions 6.5 or 7 emailed?
Thanks in advance.
Any luck with 7.1?
I have Network Connect 6.5.0.14951 and OllyDbg can’t find the string ‘no routes to monitor’, not even the word route or monitor. Anybody lucky?
@Kodak, I am still on 7.0. I have not had any chance to try out 7.1.
@Thibaud, I can find the string in both 6.5.0.15255 and 7.0.0.17925. This means that the string should also be found in 6.5.0.14951. You can confirm this by trying to search for the string after opening the executable in a hex editor such as UltraEdit.
Can someone help me out here? I have version 6.5.0.14951. I have very basic ASM knowledge)
I am able to find the string “no route to monitor” using IDA, I go to the associated function (sub_414890) and I do see the jump that is right before the push. The jump is “jnz short loc_4148DF”… I look in hex view and this jump is “75 3A” (75 is the opcode for jnz so I know I am looking in the right spot.)
So the next step (Open the executable in a Hex Editor and search for the hexadecimal data and patch the jump instruction to 0×90) is where I am slightly confused, and I have tried noping (90) both the 75 and 3A. Each time I try to connect to the VPN I get an error saying that the program has quit unexpectedly. Am I missing something?
Ok I figured out the problem- you have to nop out the entire jump conditional (so 75 3A -> 90 90)…
I was only noping out 75 OR 3A, not both.
It works! When I open dsNcService.exe in OllyDbg I didn’t realize it was showing the code for ntdll. I had to go into the Modules window and select dsNcService.exe. Then I successfully disassembled, NOP’d, re-assembled, and tested, following the instructions above. Thanks a lot!!
After patching 6.5, I have the same problem @someguy has. When I try to modify the routes juniper disconects.
Can anyone help me please?
That was my post actually, this forum is not labeled very well and puts the authors name after the post (with a confusing linebreak).
You likely did not alter the file correctly, see my post #4 for details.
I mean #5, lol – see how confusing it is.
Thanks. Thing is I was pathing the wrong file
dsNetworkConnect.exe shares code with the service executable, so the hex values I was looking for (6c 24 0c c6 44 24 07 00 ->75 3a<- 68 74) were there.
It's working now! Thank you all