Changes between Version 2 and Version 3 of Ticket #195

29 Jul 2010, 16:37:54 (10 years ago)


  • Ticket #195

    • Property Status changed from assigned to closed
    • Property Resolution changed from to pending
  • Ticket #195 – Description

    v2 v3  
     1{{{Oddly, I have not been able to complete VPN negotiations in the hotel  network since early morning today (I was able to do so prior).  }}}
    2 {{{
    3 Oddly, I have not been able to complete VPN negotiations in the hotel
    4 network since early morning today (I was able to do so prior).  Also,
    5 I have still gotten the Swisscom authenticate page.  Previously, in
    6 response to my complaints about being dropped continuously, Swisscom
    7 did something to theoretically permanently authenticate my laptop by
    8 MAC address.  I wonder if this is overriding the use of the IETF
    9 network?
     3I'm not sure we can resolve this. Some background info:
     4The hotel wifi system consists of a bunch of AP's and a "controller" box. The old controller is limited to 80 sessions max, and was literally falling over when IETF-ers started using the network.
    11 What happens is my Juniper VPN client (Network Connect) seems to
    12 authenticate, but then reports a timeout and failure.
     6What we did was three-fold:
     7- Bring more bandwith in (the old hotel network was an ADSL line  that we maxed out). The new bandwith is the orange cable
     8- Get a bigger controller box that can handle more sessions
     9- Clean out the new controller as much as possible, so it can handle the large number of sessions we need. Think "factory default" with minimal changes" and "minimal work for the controller".
    14 --
    15 Randall Gellens
    16 Opinions are personal;    facts are suspect;    I speak for myself only
    17 -------------- Randomly selected tag: ---------------
    18 There's nothing wrong with me.  Maybe there's something wrong with
    19 the universe.       --'Dr. Beverly Crusher' in ST:TNG _Remember Me_.
    20 }}}
     11What I suspect is happening, is that your VPN client has particular requirements on NAT-ting that are not met with the NAT the controller is now providing. I'm sure I don't need to explain about the difficulties of NAT, IPsec, and sharing IP's: it's not a pretty sight.
     13The wifi-controller is quite obscure and we spent many, many hours tuesday night to make it do what we need it to do: make the AP's talk, nothing else. There is not a knob to "un-break IPsec" or anything obvious.
     15So, this isn't a case of flipping a switch, but a case of fiddling with a box that will likely break the whole hotel network, and I'd rather not do that unless we really need to, and only when we have a better understanding of why the netscreenbox is failing, including logs on both ends, etc.
     17The long and short is that I'm not sure we can fix it before the IETF network dies (21 hours from now). Perhaps you can use the ietf-nh AP if your room faces the MECC, or access the network in the MECC itself?
     19Otherwise, pls do swing by in room 0.11 and we'll see what can be done, but realistically speaking I'm not hopeful.
     21I do apologise for breaking something to you but I hope you understand the improvement we made to the NH-IETF community as a whole.
     25Geert Jan