Routing recommendations for sharing VPN connection between VBox guest and host

Routing recommendations for sharing VPN connection between VBox guest and host

[Lewis G Rosenthal]

Greetings, all.

If I could pick the collective brain for a moment, I'd like to solicit
some thougths as to how I might approach the following scenario:

I have a client who requires VPN access from OS/2 (eComStation) to an
IBM zOS image, using the TN3270 client (and associated applications
require OS/2 on the client side). The VPN connection is a Cisco
AnyConnect, which is supported by openConnect on Linux, but for which
there is no OS/2 client (as far as I know, and I do a considerable
amount of OS/2 consulting).

His SonicWALL router predates the SSL-capable units, doing only IPSec,
and while we are on site-to-site IPSec VPN between us, and my Astaro
Security Gateway (now Sophos UTM) can connect and then route the traffic
through for him, I'm looking to create more of a self-contained solution
for him. So...

My idea is to install Ubuntu 12 (or openSUSE; I'm a Novell guy, so SUSE
is more familiar to me) as a VirtualBox guest under the OS/2 host (yes,
we do have VirtualBox support for OS/2). Using openConnect, assuming it
works similarly to other SSL VPNs I've used on Linux, it should create a
ppp0 interface upon connection. My thinking is to enable forwarding
between interfaces (I would configure the guest to use bridged
networking, so that host and guest are on the same subnet), and then on
the OS/2 side, build a few static routes in the table to direct traffic
from the host machine destined for the protected remote subnet(s)
through the Linux guest. I only need IPv4 support (OS/2 does not have an
IPv6-aware stack, anyhow).

My initial tests (using a Fortinet SSL VPN connection to a test network,
only because it was convenient) would not allow the traffic to pass
(after configuring the ppp0l IP as a destination host via the guest's
IP, and testing ping, attempting to add the remote protected subnet
yielded me the dreaded "SIOCADDRT: network unreachable" on the host (the
OS/2 IP stack was ported from BSD 4.3, IIRC, so it's pretty standard).
I'm thinking that there's something else I need to do on the guest side
(under Linux, which is why I'm posting this here) to enable forwarding.
Do I need to masquerade the ppp0 interface?

Any and all thoughts are welcome.

TIA

-- 
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, RTRP, EA
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
Need a managed Wi-Fi hotspot?                www.hautspot.com
Warpstock 2013 - Atlanta, GA - Oct 4-6      www.warpstock.org
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------

Re: Routing recommendations for sharing VPN connection between VBox guest and host

[Scott Edwards]

You can enable forwarding via echo 1 > /proc/sys/net/ipv4/ip_forward
(or something like that, I'm a road warrior right now, no linux box in
sight)

As for masqurading, that may be necessary, as Cisco is more strict on
the IPsec VPN tunnel. The ACL that directs traffic to the VPN is also
responsible for dropping traffic that does not match.  The only way to
be rather flexible with that, is to do IPsec over GRE, but this
clashes with your design needs on a few different angles.

If the Linux host has success communicating to the IPsec peer, then it
should be able to say,
iptables -A OUTPUT -o ppp0 -j MASQUERADE

I would also check "iptables-save -c" for hit counts, and forwarding,
and other policy.

HTH,


Scott.

Re: Routing recommendations for sharing VPN connection between VBox guest and host

[Lewis G Rosenthal]

Hi, Scott... Thanks for the quick reply.

On 08/29/13 08:13 pm, Scott Edwards thus wrote :
> You can enable forwarding via echo 1 > /proc/sys/net/ipv4/ip_forward
> (or something like that, I'm a road warrior right now, no linux box in
> sight)
>
Indeed, this is how I did it, as well as:

echo 1 > /proc/sys/net/ipv4/ppp0/ip_forward

(and ensuring the ipv4/eth0/ip_forward was present)
> As for masqurading, that may be necessary, as Cisco is more strict on
> the IPsec VPN tunnel. The ACL that directs traffic to the VPN is also
> responsible for dropping traffic that does not match.  The only way to
> be rather flexible with that, is to do IPsec over GRE, but this
> clashes with your design needs on a few different angles.
>
Yes.
> If the Linux host has success communicating to the IPsec peer, then it
> should be able to say,
> iptables -A OUTPUT -o ppp0 -j MASQUERADE
>
I think this is where I fell short somehow. I believe I entered this as
a POSTROUTING rule; perhaps that was my error vs OUTPUT (see
http://www.tldp.org/HOWTO/html_single/Masquerading-Simple-HOWTO/ per the
dial-up connection summary). I did not NAT it, however (as mentioned in
the example). Hmmm...
> I would also check "iptables-save -c" for hit counts, and forwarding,
> and other policy.
>
Good tip; thanks! It surely helps to be able to *see* what's going on
(especially when things don't work as expected!).
> HTH,
>
Indeed. Thanks again for the quick follow-up. I'll give some of this a
test tomorrow and see how I make out.

Cheers

-- 
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, RTRP, EA
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
Need a managed Wi-Fi hotspot?                www.hautspot.com
Warpstock 2013 - Atlanta, GA - Oct 4-6      www.warpstock.org
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------

Re: Routing recommendations for sharing VPN connection between VBox guest and host

[Lewis G Rosenthal]

Got it.

On 08/29/13 10:44 pm, Lewis G Rosenthal thus wrote :
> Hi, Scott... Thanks for the quick reply.
>
> On 08/29/13 08:13 pm, Scott Edwards thus wrote :
>> You can enable forwarding via echo 1 > /proc/sys/net/ipv4/ip_forward
>> (or something like that, I'm a road warrior right now, no linux box in
>> sight)
>>
> Indeed, this is how I did it, as well as:
>
> echo 1 > /proc/sys/net/ipv4/ppp0/ip_forward
>
> (and ensuring the ipv4/eth0/ip_forward was present)
>
Under openSUSE 12.3 (as guest), I ensured that
/proc/sys/net/ipv4/ip_forward was enabled, as was
/proc/sys/net/ipv4/conf/all/forwarding (which ensures that when ppp0 is
created, forwarding is enabled on that interface).
>> As for masqurading, that may be necessary, as Cisco is more strict on
>> the IPsec VPN tunnel. The ACL that directs traffic to the VPN is also
>> responsible for dropping traffic that does not match.  The only way to
>> be rather flexible with that, is to do IPsec over GRE, but this
>> clashes with your design needs on a few different angles.
>>
> Yes.
>> If the Linux host has success communicating to the IPsec peer, then it
>> should be able to say,
>> iptables -A OUTPUT -o ppp0 -j MASQUERADE
>>
> I think this is where I fell short somehow. I believe I entered this as
> a POSTROUTING rule; perhaps that was my error vs OUTPUT (see
> http://www.tldp.org/HOWTO/html_single/Masquerading-Simple-HOWTO/ per the
> dial-up connection summary). I did not NAT it, however (as mentioned in
> the example). Hmmm...
>
Yep. Got it:

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

(this can be saved across boot sessions by using, e.g.,
/etc/sysconfig/scripts/SuSEfirewall2-custom)

Then, in the host (and I tested this under eComStation, too, as it's
quite simple):

route add -net <remote_protected_subnet> netmask
<netmask_of_remote_protected_subnet>  gw <local_IP_or_FQDN_of_guest>

or, for eComStation (OS/2):

route add -net <remote_protected_subnet> <local_IP_or_FQDN_of_guest>
-netmask <netmask_of_remote_protected_subnet>

Done!

Thanks for kicking this around with me, Scott.

Cheers

-- 
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, RTRP, EA
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
Need a managed Wi-Fi hotspot?                www.hautspot.com
Warpstock 2013 - Atlanta, GA - Oct 4-6      www.warpstock.org
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------