From cernekee at gmail.com  Sun Dec  2 14:35:09 2012
From: cernekee at gmail.com (Kevin Cernekee)
Date: Sun, 2 Dec 2012 11:35:09 -0800
Subject: Routing setup with --script-tun
Message-ID: <CAJiQ=7CFBYK4CkkhO_Mku-wS7mcbuxu3i1vAEACfsvGyAzdPeg@mail.gmail.com>

David W,

Is it reasonable to assume that an IPv4 tunnel script (such as
ocproxy) only really needs to look at these settings:

INTERNAL_IP4_ADDRESS / INTERNAL_IP4_MTU (basic IP configuration)
INTERNAL_IP4_DNS / CISCO_DEF_DOMAIN (if DNS is used)
INTERNAL_IP4_NBNS (if Windows networking is used)

And that INTERNAL_IP4_NETMASK, INTERNAL_IP4_NETADDR,
INTERNAL_IP4_NETMASKLEN, VPNGATEWAY, CISCO_SPLIT_* can be safely
ignored, because all IP datagrams, regardless of destination subnet,
are sent the same way over the VPN tunnel?

I ran a quick sanity test that seemed to confirm this, but I'd like to
make sure there aren't any other cases to worry about.

All of this assumes that the user will not try to send local (non-VPN)
traffic through the proxy.

Thanks.


From dwmw2 at infradead.org  Sun Dec  2 16:44:06 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 02 Dec 2012 21:44:06 +0000
Subject: Routing setup with --script-tun
In-Reply-To: <CAJiQ=7CFBYK4CkkhO_Mku-wS7mcbuxu3i1vAEACfsvGyAzdPeg@mail.gmail.com>
References: <CAJiQ=7CFBYK4CkkhO_Mku-wS7mcbuxu3i1vAEACfsvGyAzdPeg@mail.gmail.com>
Message-ID: <1354484646.24281.20.camel@shinybook.infradead.org>

On Sun, 2012-12-02 at 11:35 -0800, Kevin Cernekee wrote:
> All of this assumes that the user will not try to send local (non-VPN)
> traffic through the proxy.

Given that assumption, it's fairly sane ? with the potential exception
of $CISCO_PROXY_PAC... but if you're doing a SOCKS proxy, and not an
HTTP proxy, then it's not clear what you would do with that anyway.

I could contrive a scenario in which your assumption isn't valid ? for
example if you want stuff to 'just work' regardless of whether you're
contacting a machine inside or outside the VPN, and don't want to have
to manually enable/disable SOCKS support. A user might want to just
configure their software to use SOCKS for everything, and have it the
SOCKS proxy do the right thing.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20121202/8aca1b80/attachment.bin>

From dme at dme.org  Mon Dec  3 05:17:27 2012
From: dme at dme.org (David Edmondson)
Date: Mon, 3 Dec 2012 10:17:27 +0000
Subject: Routing setup with --script-tun
In-Reply-To: <1354484646.24281.20.camel@shinybook.infradead.org>
References: <CAJiQ=7CFBYK4CkkhO_Mku-wS7mcbuxu3i1vAEACfsvGyAzdPeg@mail.gmail.com>
 <1354484646.24281.20.camel@shinybook.infradead.org>
Message-ID: <F2935040-2A00-44A9-9DB4-A7175CBC84AB@dme.org>


On 2 Dec 2012, at 21:44, David Woodhouse <dwmw2 at infradead.org> wrote:
> I could contrive a scenario in which your assumption isn't valid ? for
> example if you want stuff to 'just work' regardless of whether you're
> contacting a machine inside or outside the VPN, and don't want to have
> to manually enable/disable SOCKS support. A user might want to just
> configure their software to use SOCKS for everything, and have it the
> SOCKS proxy do the right thing.

This would imply that the SOCKS server is running when the VPN is down. That's not the case with ocproxy. One could chain a normal SOCKS proxy in front of ocproxy, of course, but then the configuration that you describe would be part of that proxy rather than ocproxy.



From dwmw2 at infradead.org  Mon Dec  3 05:29:41 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 03 Dec 2012 10:29:41 +0000
Subject: Routing setup with --script-tun
In-Reply-To: <F2935040-2A00-44A9-9DB4-A7175CBC84AB@dme.org>
References: <CAJiQ=7CFBYK4CkkhO_Mku-wS7mcbuxu3i1vAEACfsvGyAzdPeg@mail.gmail.com>
 <1354484646.24281.20.camel@shinybook.infradead.org>
 <F2935040-2A00-44A9-9DB4-A7175CBC84AB@dme.org>
Message-ID: <1354530581.24281.70.camel@shinybook.infradead.org>

On Mon, 2012-12-03 at 10:17 +0000, David Edmondson wrote:
> On 2 Dec 2012, at 21:44, David Woodhouse <dwmw2 at infradead.org> wrote:
> > I could contrive a scenario in which your assumption isn't valid ? for
> > example if you want stuff to 'just work' regardless of whether you're
> > contacting a machine inside or outside the VPN, and don't want to have
> > to manually enable/disable SOCKS support. A user might want to just
> > configure their software to use SOCKS for everything, and have it the
> > SOCKS proxy do the right thing.
> 
> This would imply that the SOCKS server is running when the VPN is
> down. That's not the case with ocproxy. One could chain a normal SOCKS
> proxy in front of ocproxy, of course, but then the configuration that
> you describe would be part of that proxy rather than ocproxy.

Or you run a traditional SOCKS server normally, and kill it when you
bring the VPN up.

Or you can relatively easily configure all your software with a big
switch that turns SOCKS on or off, and do that automatically when the
VPN goes up or down. But not "Use SOCKS for this site, but not for that"
which is harder. Browsers can do that with a PAC script, but not a lot
else.

I'm not necessarily advocating that we should *care* about this
scenario; merely observing that it exists. I'm happy with the behaviour
suggested in Kevin's original email ? if someone later wants to add
"split tunnelling" functionality to ocproxy, let them worry about it
then.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20121203/49479994/attachment-0001.bin>

