script-tun forwarding doesn't work with rdesktop

[Benn Snyder]

Aha, that's what I was missing.  Thanks to your advice, I now have a
working solution now using openconnect + ocproxy + proxychains.  I
first added a line to /etc/proxychains.conf.

    socks5 127.0.0.1 1090

And my script looks like this.

    #!/bin/bash
    trap "trap - SIGTERM && kill -- -$$" SIGINT SIGTERM EXIT
    exec 3< <(/usr/sbin/openconnect --juniper AUTHSITE.com -S --script
"~/code/ocproxy/ocproxy -D 1090")
    grep -m 1 "Connected (script) as" <&3 ; sleep 1s
    proxychains rdesktop HOST.DOMAIN.net -g workarea -u USER -d DOMAIN


Regards,
Benn

On Fri, Jan 29, 2016 at 3:15 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Fri, 2016-01-29 at 00:26 -0500, Benn Snyder wrote:
>>
>> If I connect normally
>>
>>     # openconnect --juniper AUTHSITE.com
>>
>> then run my script from another shell, everything works perfectly.
>> But I want only rdesktop to be forwarded and all other traffic to go
>> straight to the internet, so I tried the --script-tun flag:
>>
>>     $ openconnect --juniper AUTHSITE.com --script-tun --script
>> /mnt/scripts/rdesktop-HOST.sh
>>
>> The juniper connection goes fine and I get a startup message from
>> rdesktop, but it never connects.  Am I missing something?  Do I need
>> another piece of code in between?
>
> That isn't how script-tun works.
>
> The "tunnel script" is a special program (in fact it could never really
> be just a script) which takes binary IP packets and spits them out.
> Basically, instead of creating a local "tun0" device and registering it
> with the system, OpenConnect shovels packets between the VPN server and
> this "tunnel script" instead.
>
> I assume your /mnt/scripts/rdesktop-HOST.sh doesn't do that, and it's
> just running rdesktop to make a TCP connection to $HOST?
>
> Your best option is probably to use tunsocks or ocproxy, Those create a
> local SOCKS proxy which is used to talk to VPN hosts. Then get rdesktop
> to communicate with $HOST via that local SOCKS proxy. Does rdesktop
> have a native option for using a proxy? If not, then you might need to
> achieve *that* part with something like tsocks.
>
> Alternatively, a simpler option might be to let OpenConnect create the
> tunnel as usual, but instead of using the VPN for all DNS and IP
> routing, just route the *one* IP address of $HOST to the VPN. And don't
> do DNS at all; add $HOST's IP address to your /etc/hosts file.
>
> You can do that with a simple wrapper around vpnc-script, which looks
> something like this (typed into email, untested):
>
> #!/bin/sh
>
> # Override the routing/DNS information that the VPN gave us and
> # which OpenConnect put into the environment variables. We only
> # want to route for $HOST and nothing else.
>
> HOST=foo.example.com
> HOSTIP=$(grep $HOST /etc/hosts | cut -f1 -d\ )
>
> unset INTERNAL_IP4_DNS
> unset INTERNAL_IP6_DNS
> export CISCO_SPLIT_INC=1
> export CISCO_SPLIT_INC_0_ADDR=$(HOSTIP)
> export CISCO_SPLIT_INC_0_MASK=255.255.255.255
> export CISCO_SPLIT_INC_0_MASKLEN=32
>
> exec /etc/vpnc/vpnc-script
>
> --
> David Woodhouse                            Open Source Technology Centre
> David.Woodhouse at intel.com                              Intel Corporation
>