Problem with sshuttle over initial VPN connection

[adragomir]

My setup is as follows:
I am using a VPN to connect to an internal network. On that network, I
can see a server that I use as a landing pad for other servers. I
connect to it using sshuttle, but there are no connections forwarded,
I am exporting the 10.57 IP internal IP range.

sshuttle -vvvv -r user@lander 10.57.0.0/16

When I am in the office, so no initial VPN connection, everything
works fine. When I am at home, I have to VPN to the network first, and
sshuttle doesn't receive any connections.

I am using Snow Leopard 10.6.5, the initial VPN I am connecting to is
created using the builtin Snow Leopard VPN, it's a Cisco IPSEC.

[Gabriel Filion]

On 11/27/2010 06:02 AM, adragomir wrote:
> My setup is as follows:
> I am using a VPN to connect to an internal network. On that network, I
> can see a server that I use as a landing pad for other servers. I
> connect to it using sshuttle, but there are no connections forwarded,
> I am exporting the 10.57 IP internal IP range.
>
> sshuttle -vvvv -r user@lander 10.57.0.0/16
>
> When I am in the office, so no initial VPN connection, everything
> works fine. When I am at home, I have to VPN to the network first, and
> sshuttle doesn't receive any connections.

Lucky guess: Is it possible you don't receive the same routes over the
VPN than you have when you are in your office? (e.g. does your computer
know where to send packets for the 10.57 network when you're connected
to the VPN?)

You can check that out with 'route -n' in a terminal.

--
Gabriel Filion

[Avery Pennarun]

VPN software tends to jam itself into the network stack in odd places;
it might be that your IPsec connection has inserted itself before
sshuttle (which on MacOS uses ipfw, itself an odd place to put a
network route). If so, you might be a bit out of luck for getting
sshuttle to take precedence.

What I don't quite understand is why, if you're using IPsec anyway,
you need sshuttle. Aren't you already safely into your internal
network anyway? I can imagine using sshuttle to *replace* a Cisco VPN
- man, that thing is awful - but I don't know why you'd want to use
both.

That said, one option I could think of would be to manually narrow the
set of routes in your Cisco VPN configuration. That is, tell it to
route *only* the IP of your sshuttle gateway. Then Cisco VPN will get
first crack at each outgoing connection, but it'll let it pass unless
it's exactly the right IP. sshuttle will then get a chance to look at
it.

Please let us know if this helps.

Thanks,

Avery

[adragomir]

Well, we have a big corporate network. The servers I am trying to
access live in an external data center, and due to reasons unknown to
me, they are not exposed on the corporate network, except through a
landing pad server (the remote end of sshuttle). Changing this policy
is not a battle I want to fight :)

I'll try to add a route to the actual network adapter (not the utun0
one, the Cisco VPN) and see how that goes. I'll keep you updated.

Thanks,
Andrei

On Nov 28, 3:28 am, Avery Pennarun <apenw...@gmail.com> wrote:

[adragomir]

Fixed.

For posterity: to use sshuttle over a Cisco IPsec connection in Mac OS
X (at least using the built-in VPN client), I had to add a route for
the remote servers that I want to export to 127.0.0.1.

$ sshuttle -r user@landing 10.xx.0.0/16
$ route -n add 10.xx.0.0/16 127.0.0.1

Thank you for the idea ! And sshuttle rocks.

/A

[Avery Pennarun]

On Sat, Nov 27, 2010 at 9:36 PM, adragomir <adra...@gmail.com> wrote:
> Fixed.
>
> For posterity: to use sshuttle over a Cisco IPsec connection in Mac OS
> X (at least using the built-in VPN client), I had to add a route for
> the remote servers that I want to export to 127.0.0.1.
>
> $ sshuttle -r user@landing 10.xx.0.0/16
> $ route -n add 10.xx.0.0/16 127.0.0.1

Thanks! Hopefully your message will help future Cisco VPN users.

What did your routing table look like before that? Did you have any
route at all that still pointed to the desired destination?

Thanks,

Avery