No, it makes no difference. Pavel On 14 December 2015 at 12:57, Krzysztof Kwiatkowski <kris at amongbytes.com> wrote: > Hmmm... > > Does it change anything if you add "--no-cert-check" to openconnect > options (just temporarily for testing). > > Kris > > On 14/12/15 12:14, Pavel Kogan wrote: >> I'm not hard-coding the DSID anywhere, so I assume the wrapper script >> gets a new one each time. >> >> It kicks me off after a few seconds. Actually, I can't really be >> certain it connects properly in the first place since I haven't been >> able to access anything behind the VPN in the interim. >> >> Yes, the host I'm connecting to does require host checking. I was >> using `juniper-vpn.py` because I wanted to avoid having to download >> and use a jar. >> >> Anyway, with the tncc-wrapper.py from the openconnect repo: >> ``` >> $ sudo openconnect --juniper --useragent 'Mozilla/5.0 (Linux) Firefox' >> --csd-wrapper=tncc-wrapper.py pulse.example.com >> [sudo] password for pavel: >> WARNING: Juniper Network Connect support is experimental. >> It will probably be superseded by Junos Pulse support. >> GET https://pulse.example.com/ >> Attempting to connect to server 19X.XXX.XXX.XXX:443 >> SSL negotiation with pulse.example.com >> Connected to HTTPS on pulse.example.com >> Got HTTP response: HTTP/1.1 302 Found >> GET https://pulse.example.com/dana-na/auth/url_5/welcome.cgi >> SSL negotiation with pulse.example.com >> Connected to HTTPS on pulse.example.com >> frmLogin >> username:pavel.kogan >> password: >> POST https://pulse.example.com/dana-na/auth/url_5/login.cgi >> SSL negotiation with pulse.example.com >> Connected to HTTPS on pulse.example.com >> Got HTTP response: HTTP/1.1 302 Moved >> GET https://pulse.example.com/dana-na/auth/url_5/welcome.cgi?p=preauth&id=state_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&signinRealmId=3 >> SSL negotiation with pulse.example.com >> Connected to HTTPS on pulse.example.com >> socket opened >> GET https://pulse.example.com/dana-na/auth/url_5/welcome.cgi?p=preauth&id=state_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&signinRealmId=3 >> SSL negotiation with pulse.example.com >> Connected to HTTPS on pulse.example.com >> Got HTTP response: HTTP/1.1 302 Moved >> GET https://pulse.example.com/dana-na/auth/url_5/login.cgi?loginmode=mode_postAuth&postauth=state_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >> SSL negotiation with pulse.example.com >> Connected to HTTPS on pulse.example.com >> Got HTTP response: HTTP/1.1 302 Moved >> GET https://pulse.example.com/dana-na/auth/remediate.cgi?step=rolecheck&stateId=state_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&realmId=3&rolesremaining=0&realmsremaining=1 >> SSL negotiation with pulse.example.com >> Connected to HTTPS on pulse.example.com >> Unknown form ID 'frm' >> Dumping unknown HTML form: >> <form id="frm_142" name="frm" action="remediate.cgi"> >> >> <input id="action_31" type="hidden" name="action" value=""> >> >> <input id="signinId_2" type="hidden" name="signinId" value=""> >> <input id="realmId_10" type="hidden" name="realmId" value="3"> >> <input id="executedStep_2" type="hidden" name="executedStep" >> value="rolecheck"> >> <input id="stateId_8" type="hidden" name="stateId" >> value="state_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"> >> <input id="p_16" type="hidden" name="p" value=""> >> >> <input id="showContinue_2" type="hidden" name="showContinue" value="0"> >> <input id="showRemedOption_2" type="hidden" name="showRemedOption" >> value="0"> >> >> <input id="hostcheckTS_2" type="hidden" name="hostcheckTS" value=""> >> <input id="totalseconds_2" type="hidden" name="totalseconds" value=""> >> >> <input id="executedAction_2" type="hidden" name="executedAction" value=""> >> </form>Failed to obtain WebVPN cookie >> java.lang.NullPointerException >> at net.juniper.tnc.HttpNAR.HttpNAR.processCommands(HttpNAR.java:381) >> at net.juniper.tnc.HttpNAR.HttpNAR.run(HttpNAR.java:261) >> at net.juniper.tnc.NARPlatform.linux.LinuxHttpNAR.main(LinuxHttpNAR.java:52) >> ``` >> >> Handling this unrecognised form was actually the change I had to make >> to `juniper-vpn.py`. It seems purely informational so I just had the >> script ignore it and carry on to tncc. All the fields are read-only >> (according to the dump I did from the python script) but maybe >> something does need to be done with it? >> >> On 14 December 2015 at 10:01, David Woodhouse <dwmw2 at infradead.org> wrote: >>> On Fri, 2015-12-11 at 16:53 +0000, Pavel Kogan wrote: >>>> >>>> ``` >>>> $ sudo ./juniper-vpn.py --host pulse.example.com --user pavel.kogan >>>> --stdin DSID=%DSID% openconnect --juniper %HOST% --cookie-on-stdin >>>> --interface=tun0 >>>> Password: >>>> WARNING: Juniper Network Connect support is experimental. >>>> It will probably be superseded by Junos Pulse support. >>>> Attempting to connect to server 19X.XXX.XXX.XXX:443 >>>> SSL negotiation with pulse.example.com >>>> Connected to HTTPS on pulse.example.com >>>> SSL negotiation with pulse.example.com >>>> Connected to HTTPS on pulse.example.com >>>> Connected tun0 as 10.XXX.XXX.XXX, using SSL >>>> ESP session established with server >>>> Server terminated connection (session expired) >>>> Unknown error; exiting. >>>> WARNING: Juniper Network Connect support is experimental. >>>> It will probably be superseded by Junos Pulse support. >>>> Attempting to connect to server 19X.XXX.XXX.XXX:443 >>>> SSL negotiation with pulse.example.com >>>> Connected to HTTPS on pulse.example.com >>>> Got HTTP response: HTTP/1.1 302 Found >>>> Unexpected 302 result from server >>>> Creating SSL connection failed >>>> Waiting 10... >>>> ``` >>>> The error then repeats until I Ctrl-C. >>> >>> That's odd. I assume you're using a fresh DSID cookie each time you >>> connect? And it then kicks you off almost immediately, telling you >>> 'session expired'? How long does it remain connected for? >>> >>> I wonder if this is a problem with tncc.py from the scripts you're >>> using to authenticate. In some modes the host checker script is >>> expected to keep running all the time you're connected to the VPN, but >>> ISTR that isn't implemented in Russ's tncc.py. >>> >>> Can you try running the *real* one? OpenConnect has support for >>> spawning it... do you actually need external scripts at all for >>> authentication, in fact? Anything we can do in an external python >>> script parsing the forms, we *should* be able to add to OpenConnect's >>> own parsing hacks. >>> >>> -- >>> dwmw2 >>> >> >
