This is a bit old school, but you might want to try using expect for
this instead of bash. I think expect would support a more robust
solution (e.g., login error checking) and address the nasty
stdin/stdout/tty issues. A similar expect script might look something
like the following:
#!/usr/bin/env expect
set hosts {host1 host2}
set password ""
set username ""
proc tryConnect {hostname} {
global username
global password
set timeout -1
spawn /usr/bin/openconnect --script /etc/vpnc/vpnc-script
--no-cert-check https://${hostname}
expect {
"Login error." {
set username ""
set password ""
exp_continue
}
"USERNAME:" {
if {$username == ""} {
expect_user -re "(.*)\n" {
set username $expect_out(1,string)
}
}
exp_send "$username\r"
exp_continue
}
"Password:" {
if {$password == ""} {
stty -echo
expect_user -re "(.*)\n" {
set password $expect_out(1,string)
}
stty echo
}
exp_send "$password\r"
exp_continue
}
}
}
foreach host $hosts {
tryConnect $host
puts "Connecting lost. Trying $host..."
}
On Mon, Jan 9, 2012 at 9:20 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Mon, 2012-01-09 at 08:34 -0500, Eric Leadbetter wrote:
>> Hi,
>>
>> I am using openconnect with a VPNC connection on a point-to-point
>> network that (by design) is slightly inconsistent. This means that the
>> connection to the primary server is lost occasionally. I would like to
>> be able to configure openconnect to "fall back" to a secondary server
>> when the connection to the primary server is lost, but have not found
>> a way to do this. Does OpenConnect support this feature?
>
> Let me start with some background on how the protocol works...
>
> OpenConnect works in two phases. First you fill in some HTTPS forms to
> authenticate, at which point you're rewarded by an HTTP cookie that you
> use to make the actual connection.
>
> OpenConnect can re-use that cookie, and will automatically reconnect to
> the *same* server if it loses the connection. But *only* that server.
>
> Connecting to a second server *isn't* going to give you a seamless
> change-over. You'll get a different IP address on the VPN, and all your
> existing connections will break (or just time out).
>
> So unless I'm missing something, it sounds like you might as well use a
> shell script which *invokes* openconnect repeatedly; trying one server
> and then the other until it succeeds. It might look something like this:
>
> #!/bin/bash
>
> SERVER1=xxx
> SERVER2=yyy
> read -p "Enter VPN username:" VPNUSER
> read -s -p "Enter VPN password:" VPNPASS
>
> NEXTTRY=$(($(date +%s) + 60))
>
> while true; do
> ? for SERVER in xxx yyy; do
> ? ? openconnect -u "$VPNUSER" --passwd-on-stdin <<< "$VPNPASS" --script /etc/vpnc/vpc-script $SERVER
> ? done
> ? NOW=$(date +%s)
> ? if [ $NOW -lt $NEXTTRY ]; then
> ? ? ? ?sleep $(($NEXTTRY - $NOW))
> ? fi
> ? NEXTTRY=$(($NOW + 60))
> done
>
>> If not, an alternative that I have thought of (but not yet tested)
>> would be to make simultaneous VPN connections to the primary and
>> secondary servers and bond the created tunnel interfaces. Do you think
>> this would work?
>
> Not unless there's something very special about the servers, and you
> actually get the same IP address from each... and they somehow advertise
> the route to that IP address internally according to which server you're
> connected to?
>
> --
> dwmw2
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel
>
