- 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 has been added (conflicts with our route to, disconnecting”

    BR / ahd71

  • Workarounds:
    1. Disable route change monitor
    2. Exclude these two 'nets from the 192.168.x.x pool in NC networks. This is what I did since most home wireless access points or routers use this range by default. Details on request.

    I’m guessing some home device is vying for the IP space.

  • Hi and thanks,

    We can’t disable route monitoring or allow any split tunneling because of security reasons. I have to find out what is messing with the routingtable intermittently (on MANY clients) but haven’t got any idéeas to monitor which application, or Vista itself, that change the routing table. Any idéeas are welcome! (i’m having a supportcase with Juniper too but no luck yet)

    BR / Anders

  • Why not just exclude these two networks from the NC networks? You can still maintain your security stance.

    Instead of /16 use this and then /24 ad /24 are not included:

  • Hi,

    I’m afraid that it isn’t possible, the 192.168.x.x was just an example, it happends to clients on “every possible subnet” (including public ip addresses) so allowing split tunneling to some nets are not possible as it would require all nets in that case which isn’t allowed for security reasons….

    Just to make sure we understand each other, it isn’t a conflict with addresses in the NC pool range, we have public ip addresses in our pools, the problem exist on client side where something adds a route to the local subnet (at any time) and route monitoring then fires an event disconnecting the tunnel.

    BR / ahd71

  • Pretty unusual for many hosts to be modifying the route tables.
    What code are you running? And what client software could be causing this?
    I’d break out a sniffer.

  • Thanks, yes thats pretty strange behaviour. The “Bonjour problem” has the same symtoms (routing table changes, route monitoring disconnect session) but we haven’t got bonjour running….i will try sniffing the interface and see if it gives something. Thankyou again for trying to help us. It is even harder to find as it happends randomly.

    BR /ahd71

  • we have that problem too, many of our users are getting disconnected with this or the 23791 error-message, pretty strange. our clients have no bonjour installed!

    we still have no solution for this error, junipersupport doesnt either, would be great if anyone has a tipp on this one.

    looks like the same behaviour as app.23791, which is a bigger problem for us, cause many user have it without any regularity.

  • Hi,

    Interesting to know that we not are alone,

    Which OS on the clients and which IVE release are you running?

    BR / ahd71

  • Hey,

    the clients are using WinXP SP2 with IE6.x.

    Version: 6.0R3.1 (build 12507).

    But notice that the 23711 is more rare that the 23791, which is really annoying.

    It comes with the message:
    [ERROR] getSessionTimeout getReminderTime returned failure.

    Even the junipersupport has no idea what that errormessage is supposed to mean, seems like the programmer has gone and nothing was documented, haha. like always…

    best regards,

  • In the past we had a few problems with 23791 like if the nc ip pool doesn’t have enough addresses (should be shown directly after connection, not after a random time though)
    Have you checked the auto-detect proxy setting which is - or at least was -not working well with NC giving the 23791. IVE 6.0R1 had a problem with ACL ports separated with comma giving this error too, if it still is an issue use one port per line as a workaround.

  • hmm our nc ip pool has about 180 addresses for max. 50 concurrent users and that error occures after a random time.

    there is no auto detection for proxysettings enabled, we are using a .pac-file!

    one port per line, that should be worth a try. tanks a lot!

    we had that 23711 error when a clientfirewall was enabled. we have that symantec client security and it was blocking the NC in some way. after a explicit allow-rule it worked. have you proofed that already?

    best regards,

  • Hi,

    Just to check, were the 23711 happening at “random time” even thou the firewall were the problem for you?

    BR /ahd71

  • no, at connection-start!

  • Hi,

    With “connection start” is that “directly” or “within a few minutes”?

    BR /ahd71

  • directly - that doesnt count for 23971 though!

  • any news on this? did you had a client firewall and could you solve those problems?

  • Hi,

    No we still have the problem, i’ll update the thread if we find anything.

    BR /ahd71

  • I had this same problem for a very long time, after yelling at JTAC for awhile, they escalated the ticket to engineering and they accecpted as a bug and will have a fix released in 6.0R7 which will be released on Aug 14th last I heard.

  • Did you get a Bug ID? If not, get one.