Nc.windows.app.23711 - route table changed, disconnecting - no "Bonjour" running



  • We are having problems with Network Connect disconnecting within seconds, minutes or hours “randomly”. In the logs i can find that route monitoring are disconnecting the tunnel but I can’t figure out what is causing the route change in the first place. (We do not have Bonjour on the clients having this problem.)

    “Unauthorized new route to 192.168.1.0/192.168.1.100 has been added (conflicts with our route to 0.0.0.0), disconnecting”

    BR / ahd71



  • This only happend if Split Tunneling is disabled. 😛





  • Hello guys,
    I know this is an old topic, but it may help for somebody browsing the internet and looking for an answer as I did 🙂

    So here are my 2 cents  :lol:

    I have attached the link to juniper site with list of errors. I had very same problem,(23711). By the mentioned document I was sure something was changing my route table. It can be verified. Start “NC Troubleshooting” software, which can be found in your Start>Programs>Juniper Networks>Network Connect. On second tab I have selected routing table and with “Network connect” established connection and was observing what will follow. When my session was terminated and I refreshed my routing table, the table was changed.

    So one of the solutions is go one by one of services you can suspect of changing these entries. I was aware that might be also VMware stuff, or Teamviewer. So I started with it. Killing Teamviewer didn’t help, but when I was disabling network adapter created and managed by VMware it did help. The problematic one was “VMware Network Adapter VMnet8” which is responsible for NAT. When I connected with Juniper NC and I enabled mentioned adaptor the connection was terminated right away. Without that it was working great. The other indicator was, when you are connected with your NC sw, you have in network connections one additional NIC created by Juniper NC. When you enable VMware adaptor or you do the reconnection when it dropped while enabled VMware adaptor you may observe this Juniper’s NIC card indicated state “Unauthenticated” and after some time the connections dropps again. When VMware NIC is disabled all the time, the VPN connection is stable and Juniper’s NIC is not showhing “Unauthenticated” state. As I was lucky with identifying what is causing dropps at very first stage of investigation I didn’t dig deeper.

    Just to mention my sys. specs: Win 7 64b SP1, Network Connect 7.4.0.30611, VMware Workstation 10.

    Hopefully it helps.  😉



  • I know this thread has been dead for a while, but I’m hoping some of you all might have any pointers for me.

    I’ve run into several several Windows XP SP3 machines and running into the same issue, however none of these machines have Wireless cards on them.    From the logs, I see this each time the 23711 error is thrown:
    "‘rmon’ Unauthorized new route to 192.168.1.50/192.168.1.52 has been added (conflicts with our route to 0.0.0.0), disconnecting"

    We’re runing v6.3.0 and from what I’m told we won’t be upgrading to 6.4 anytime soon.



  • @ahd71: symantec client fw. it just does not accept the changed md5 checksum of the new file (NC, HC).



  • I just downgraded my Intel WiFi Link 4965AGN from 11.5 to 11.1 and it seems to have done the trick!  Thanks for the tip, this has been such a pain in the ass.

    FYI, I’m running Vista 64 Home Premium.



  • Which client firewall are you using? I guess that you can allow NC to be accepted even during upgrades if configured correctly.

    BR / Ahd71



  • which is bad, cause we cant just update the whole system. about 700 notebookusers’ clientfirewalls wont allow access after upgrade. GREAT



  • non public hotfix from juniper, but will be public availible in upcoming official releases…

    BR / ahd71



  • so what is that private workaround?



  • Hi,

    Intresting that the driver release of the network card makes a different, which make it even more hard to troubleshoot this behaviour.

    I would say that the correct behaviour is that the metric SHOULD change if speed changes, but the way the route monitoring function in the IVE is currently implemented it trigs on this behaviour with a “false positive” which isn’t acceptable from a user perspective. Juniper are aware of this and a private workaround exist but so far no public availible workaround.

    BR / ahd71



  • I was a bit fast on saying 11.x worked. We are using 11.1.0.86 on Windows Vista and that one is working with a solid metric of 25. (or atleast it have so far)

    11.5 Doesnt work when I tested it… metric change. VPN disconnect in seconds to few mins.
    12.0 (latest) doesnt work, metric change. Same deal.

    The 11.1 driver is 1.5 years old, so its a bit odd that none have fixed this. The Intel 4965AGN aint exactly an exotic network card.



  • Hi,

    Interesting, i have Windows Vista and Intel WiFi 4965AGN with driver release 11.5.1.15 and the routing metric keeps changing between 281 and 286 when the signal strength changes.
    I guess you have XP as you have a metric of 25?

    BR / Ahd



  • Ok, I had a sitdown with a few fellas from Lenovo the other day and we have solved the problem.
    Its the 12.x Intel driver thats causing it on our 4965AGN wireless adapters. We used a 11.x version that was 1.5 years old, and the problem went away. The metric with the 12.x driver keep changing from 40 -> 30 -> 25 depending on signal strength, while with the older one its stable at 25.

    Hope this helps. 😃



  • Hi,

    No public releases yet as I know about that addresses this issue.

    The problem with error 23711 i’m referring happends only when using route monitoring in the IVE and using NC with Windows Vista and WiFi when signal strength changes and passing specific thresholds causing Vistas ip stack to change the route metric which fires the route monitoring which disconnects the tunnel….

    BR /ahd71



  • I work for a company with about 1000 users, and we are having the same problem. Vista keep disconnecting at random when using wireless and NC 6.2.

    Is there any progress with this? Whats going on?  😞



  • yes, correct ;-(



  • but those releases require to shut down the cluster und upgrade each device manually, right? hmm, that causes problems on our users notebooks, cause new releases are changing the file information, so the client-firewall does not know the new file and denies the access…that sucks



  • Finally, i know why we get a lots of 23711. When WiFi signal strength changes the routing metric also changes causing this behavior in Vista (with XP it doesn’t change metric or me).
    This only happend if Split Tunneling is disabled and route monitoring is active.

    Juniper has developed a new release of NC to address this issue which not yet is released.

    BR / ahd71


 

32
Online

38.4k
Users

12.7k
Topics

44.5k
Posts