Prev: Global Warming fake science and what you can do to against it
Next: reliance netconnect
From: C. on 29 Jan 2010 07:39
On Jan 26, 8:33 am, David Brown <da...(a)westcontrol.removethisbit.com>
wrote:
> On 25/01/2010 20:32, Greg Russell wrote:
>
> > We have an iptables firewalling router setup here that is working well,
> > as we've stress-tested it from external sites using all the attack tools
> > we can find.
>
> > We have several users that are "on the road" and require connectivity
> > from various sites such as motels, coffeehouses, airports and dialup to
> > various ISPs. We'd like to have a secure tunneling connection for these
> > users, and we'd like to ask what might be a viable solution that works
> > for all these various connection points?
>
> > By viable I mean that even username and password wouldn't be sniffable
> > during connection initiation.
>
> ipsec solutions are certainly secure (with correct configuration, of
> course), but can be a real pain for routing, NAT traversal, and so on.
<snip>
>
> ssh is for remote shell access.  You /can/ do port forwarding with it to
> give access to other resources, but it is not great for the purpose - it
> won't make the best use of the bandwidth, and it is far from convenient
> to specify the forwarding connections if there are many of them.
<snip>
>
> openvpn is, IMHO, an extremely useful way to handle remote connections.
<snip>
>
> I use openvpn whenever we need secure external access to a server, along
> with a ssh backdoor for maintenance purposes.

It really depends on whether the remote users are running linux/Unix
or may be using Microsoft - the latter can really restrict your
options.

IPSEC is rather difficult to set up, particularly between non-fixed
points (and particularly where it may be crossing NAT boundaries).
OpenSwan has some extensions for supporting 'road warriors' though.

I haven't used openVPN but if support for Microsoft may be important
then its definitely worth thinking about.

Note that you **can** create a tunnelled connection using SSH (not
just port forwarding) by running ppp through the connection - I've
previously done this using stunnel rather than ssh and it proved very
reliable with only a very slight impact on bandwidth (we even used
VOIP across the VPN with no noticeable delay).

I've also previously used stunnel to provide on-demand port-forwarding
for MS clients - again very reliable and a no-brainer for the end-
users. There's a bit of overhead in setting up your own CA / or buying
in certs but if I can set up a CA and IKE infrastructure anyone can!

C.
From: Pascal Hambourg on 30 Jan 2010 06:10
Hello,

C. a �crit :
>
> Note that you **can** create a tunnelled connection using SSH (not
> just port forwarding) by running ppp through the connection

OpenSSH also supports native IP tunnelling through the use of TUN
interfaces (not to be confused with the classic TCP port forwarding).
See the -w option or the Tunnel directive. However I have seen warnings
about issues regarding tunnelling of IP over TCP and packet loss (TCP is
stream-oriented, so a single lost packet blocks the reception of all
subsequent packets until it is successfully retransmitted). This applies
to PPP over SSH too.
From: David Brown on 30 Jan 2010 09:15
C. wrote:
> On Jan 26, 8:33 am, David Brown <da...(a)westcontrol.removethisbit.com>
> wrote:
>> On 25/01/2010 20:32, Greg Russell wrote:
>>
>>> We have an iptables firewalling router setup here that is working well,
>>> as we've stress-tested it from external sites using all the attack tools
>>> we can find.
>>> We have several users that are "on the road" and require connectivity
>>> from various sites such as motels, coffeehouses, airports and dialup to
>>> various ISPs. We'd like to have a secure tunneling connection for these
>>> users, and we'd like to ask what might be a viable solution that works
>>> for all these various connection points?
>>> By viable I mean that even username and password wouldn't be sniffable
>>> during connection initiation.
>> ipsec solutions are certainly secure (with correct configuration, of
>> course), but can be a real pain for routing, NAT traversal, and so on.
> <snip>
>> ssh is for remote shell access. You /can/ do port forwarding with it to
>> give access to other resources, but it is not great for the purpose - it
>> won't make the best use of the bandwidth, and it is far from convenient
>> to specify the forwarding connections if there are many of them.
> <snip>
>> openvpn is, IMHO, an extremely useful way to handle remote connections.
> <snip>
>> I use openvpn whenever we need secure external access to a server, along
>> with a ssh backdoor for maintenance purposes.
>
> It really depends on whether the remote users are running linux/Unix
> or may be using Microsoft - the latter can really restrict your
> options.
>
> IPSEC is rather difficult to set up, particularly between non-fixed
> points (and particularly where it may be crossing NAT boundaries).
> OpenSwan has some extensions for supporting 'road warriors' though.
>
> I haven't used openVPN but if support for Microsoft may be important
> then its definitely worth thinking about.
>

OpenVPN clients are extremely easy to work with in Windows (assuming you
install the gui - on older versions of OpenVPN, the windows gui was a
separate program, but these days it is in the main installation
package). In fact, I haven't seen anything as convenient for activating
OpenVPN tunnels in Linux - not that I have looked very hard, since I am
happy using the command line for that sort of thing, and my colleagues
who want a point-and-click gui use windows.

> Note that you **can** create a tunnelled connection using SSH (not
> just port forwarding) by running ppp through the connection - I've
> previously done this using stunnel rather than ssh and it proved very
> reliable with only a very slight impact on bandwidth (we even used
> VOIP across the VPN with no noticeable delay).
>

You certainly /can/ do that sort of thing with ssh - it's a swiss army
knife tool. But OpenVPN is dedicated to the task, and it's easier.

> I've also previously used stunnel to provide on-demand port-forwarding
> for MS clients - again very reliable and a no-brainer for the end-
> users. There's a bit of overhead in setting up your own CA / or buying
> in certs but if I can set up a CA and IKE infrastructure anyone can!
>

I've not used stunnel - it looks like it could do the job, but OpenVPN
is (to my knowledge) a more complete package.

See also <http://www.linuxjournal.com/article/7881>

From: Greg Russell on 30 Jan 2010 21:14
In news:w8SdnQpmPKXhovnWnZ2dnUVZ8qidnZ2d(a)lyse.net,
David Brown <david.brown(a)hesbynett.removethisbit.no> typed:

>> I haven't used openVPN but if support for Microsoft may be important
>> then its definitely worth thinking about.
>>
>
> OpenVPN clients are extremely easy to work with in Windows (assuming
> you install the gui - on older versions of OpenVPN, the windows gui
> was a separate program, but these days it is in the main installation
> package). In fact, I haven't seen anything as convenient for
> activating OpenVPN tunnels in Linux - not that I have looked very
> hard, since I am happy using the command line for that sort of thing,
> and my colleagues who want a point-and-click gui use windows.
>
>> Note that you **can** create a tunnelled connection using SSH (not
>> just port forwarding) by running ppp through the connection - I've
>> previously done this using stunnel rather than ssh and it proved very
>> reliable with only a very slight impact on bandwidth (we even used
>> VOIP across the VPN with no noticeable delay).
>
> You certainly /can/ do that sort of thing with ssh - it's a swiss army
> knife tool. But OpenVPN is dedicated to the task, and it's easier.

After all the recommendations, we've chosen openvpn, and it was indeed very
eay to install, configure and administer, using the web-based admin GUI on
the Linux server. It correctly configured the iptables firewall too, which
was a concern.

To test, we used a Windows 2000 machine on dialup, connect to the client
interface on the Linux web host, downloaded the M$ installer and the
user-specific client profile. Everything was indeed very easy.

The trouble is that it doesn't work for some strange reason. The Windows
client connects, authentication completes, but the Windows client then
disconnects after about 5-15 seconds for no discernible reason.

The openvpn server shows that the client is still connected with an assigned
IP address though, but a "route print" on the Windows machine has no route
for the vpn packets, and "ipconfig /all" shows the virtual TUN interface
with no assigned IP address and no gateway address, and the task tray icon
shows the TUN interface as "cable unplugged".

We've copied the log entries from the openvpn linux server to the "live
chat" tech support at openvpn, and they can see nothing wrong with the
connection, nor can they offer any possible reason for the failure of the M$
client to be properly configured with the necessary vpn DHCP information.

For the moment at least, we're defeated.


From: Tauno Voipio on 31 Jan 2010 02:25
Greg Russell wrote:
> In news:w8SdnQpmPKXhovnWnZ2dnUVZ8qidnZ2d(a)lyse.net,
> David Brown <david.brown(a)hesbynett.removethisbit.no> typed:
>
>>> I haven't used openVPN but if support for Microsoft may be important
>>> then its definitely worth thinking about.
>>>
>> OpenVPN clients are extremely easy to work with in Windows (assuming
>> you install the gui - on older versions of OpenVPN, the windows gui
>> was a separate program, but these days it is in the main installation
>> package). In fact, I haven't seen anything as convenient for
>> activating OpenVPN tunnels in Linux - not that I have looked very
>> hard, since I am happy using the command line for that sort of thing,
>> and my colleagues who want a point-and-click gui use windows.
>>
>>> Note that you **can** create a tunnelled connection using SSH (not
>>> just port forwarding) by running ppp through the connection - I've
>>> previously done this using stunnel rather than ssh and it proved very
>>> reliable with only a very slight impact on bandwidth (we even used
>>> VOIP across the VPN with no noticeable delay).
>> You certainly /can/ do that sort of thing with ssh - it's a swiss army
>> knife tool. But OpenVPN is dedicated to the task, and it's easier.
>
> After all the recommendations, we've chosen openvpn, and it was indeed very
> eay to install, configure and administer, using the web-based admin GUI on
> the Linux server. It correctly configured the iptables firewall too, which
> was a concern.
>
> To test, we used a Windows 2000 machine on dialup, connect to the client
> interface on the Linux web host, downloaded the M$ installer and the
> user-specific client profile. Everything was indeed very easy.
>
> The trouble is that it doesn't work for some strange reason. The Windows
> client connects, authentication completes, but the Windows client then
> disconnects after about 5-15 seconds for no discernible reason.
>
> The openvpn server shows that the client is still connected with an assigned
> IP address though, but a "route print" on the Windows machine has no route
> for the vpn packets, and "ipconfig /all" shows the virtual TUN interface
> with no assigned IP address and no gateway address, and the task tray icon
> shows the TUN interface as "cable unplugged".
>
> We've copied the log entries from the openvpn linux server to the "live
> chat" tech support at openvpn, and they can see nothing wrong with the
> connection, nor can they offer any possible reason for the failure of the M$
> client to be properly configured with the necessary vpn DHCP information.
>
> For the moment at least, we're defeated.

Did you check the Linux logs?

If I were you, I'd next install a network sniffer on the
Linux machine and catch two traffic streams at the time
of the unsiccessful connection:

- The dial-up connection (PPP?), called tunnel outside,
- The VPN connection, called tunnel inside.

For sniffers, my favourite is Wireshark, but the raw capture
can be done with tcpdump. If it is not possible to run
X on the server, I'd capture the traffic with tcpdump's
write to file option and decode the captures on a workstation
with Wireshark.

--

Tauno Voipio
tauno voipio (at) iki fi
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Global Warming fake science and what you can do to against it
Next: reliance netconnect