Re: ssh, openswan, openvpn or ...?

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.
You are also, as far as I know, limited to a single ipsec tunnel
endpoint for each ip address, though there can be many connections to
the same tunnel end point at the time. By that I mean that you can have
many clients connecting to the server, but they are all attached to the
same virtual network port on the server. Similarly, each client can
only be connected to only one server at a time. (Hopefully someone will
correct me if that's not true.)

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.
However, it is extremely handy for doing ad-hoc connections and giving
yourself a "backdoor" into your system (put it on a non-standard port so
the bad guys don't keep knocking on it). You can either pre-share the
cryptographic keys or use passwords, or both.

openvpn is, IMHO, an extremely useful way to handle remote connections.
It can take a bit of learning to figure out how the configuration is
done, but when you've done it once you just copy and modify the
configuration file for others. It's a no-brainer for the clients - on
windows you get an icon in your tray and you just select "connect" from
the menu as needed. On Linux you can use the command line or a gui as
you fancy. You can configure it on the server with all sorts of
options, and happily have multiple tunnels on different ports. That way
you can have different groups connected to different virtual network
ports on the router, and use iptables and routing to connect them to
different parts of the network. Security is solid, with cryptographic
keys and optional passwords, and support for various other
identification systems.

I use openvpn whenever we need secure external access to a server, along
with a ssh backdoor for maintenance purposes.

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.

In news:(E-Mail Removed),
David Brown <(E-Mail Removed)> 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.

Greg Russell wrote:
> In news:(E-Mail Removed),
> David Brown <(E-Mail Removed)> 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

Sidney Lambe wrote:
> On comp.os.linux.networking, Tauno Voipio <(E-Mail Removed)> wrote:
>> Greg Russell wrote:
>>
> [delete]
>> 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.
>>
>
> Interesting thread.
>
> Tethereal, which comes with ethereal (X app), is a great console
> packet sniffer. I run it in its own window all the time.
>
> Sid


Forget Ethereal and friends, it is Wireshark and tshark now.

--

Tauno Voipio

On 2010-01-31, Sidney Lambe <(E-Mail Removed)> wrote:
> On comp.os.linux.networking, Tauno Voipio <(E-Mail Removed)> wrote:
>> Sidney Lambe wrote:
>>> On comp.os.linux.networking, Tauno Voipio <(E-Mail Removed)> wrote:
>>>> Greg Russell wrote:
>>>>
>>> [delete]
>>>> 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.
>>>
>>> Interesting thread.
>>>
>>> Tethereal, which comes with ethereal (X app), is a great console
>>> packet sniffer. I run it in its own window all the time.
>>
>> Forget Ethereal and friends, it is Wireshark and tshark now.
>
> Unless you explain why this is supposedly the case,

You're joking, right? The name of the program changed from
Ethereal to Wireshark years ago. Any remotely recent version
will be called wireshark (or tshark).

> your words will be ignored by me and everyone else with a
> functioning mind.

Yet you paid them attention, thus belying your own statement.

> As they would be if your explanation was inadequate.
>
> I use tethereal and it works wonderfully.

Bully for you, but running out-of-date software puts you at
risk of attack. Tshark is what the program has been called for
something like 4 years now. You might want to update your
software every year or three, Sid -- especially stuff that uses
root privledges like "ethereal".

--
Grant

On 2010-01-31, Sidney Lambe <(E-Mail Removed)> wrote:
> On comp.os.linux.networking, Joe Pfeiffer <(E-Mail Removed)> wrote:
>>
>>> What the hell does that mean? If I'm not some kind of loser
>>> who spends his life tracking the development of every application
>>> on his OS then I'm a "joke"?
>>
>> No, you're making such an obviously ludicrous statement that Grant is
>> making the kindest possible assumption: you aren't as big an idiot as
>> you're claiming to be, and you're telling a joke instead.
>
> Did it give your little weenie a hardon to say that, you stupid
> punk?
>
> Killfiled.
>
> And I'll bet it's not the first time.

Just for the sake of curiosity, how many times does somebody
need to be "killfiled" by you before you stop replying to their
posts?

--
Grant Edwards grante Yow! My nose feels like a
at bad Ronald Reagan movie ...
visi.com

On Sat, 30 Jan 2010 18:14:55 -0800, Greg Russell wrote:

> 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.

Was this problem ever resolved?

In news:(E-Mail Removed),
J G Miller <(E-Mail Removed)> typed:

>> 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.
>
> Was this problem ever resolved?

No, I'm sorry to report. Wireshark on both the client and CentOS 5.4 server
show nothing unusual. The problem seems to be that the M$-Windows 2000
client virtual interface simply won't accept the DHCP configuration for
unknown reasons.

Greg Russell wrote:

> In news:(E-Mail Removed),
> J G Miller <(E-Mail Removed)> typed:
>
>>> 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.
>>
>> Was this problem ever resolved?
>
> No, I'm sorry to report. Wireshark on both the client and CentOS 5.4
> server show nothing unusual. The problem seems to be that the M$-Windows
> 2000 client virtual interface simply won't accept the DHCP configuration
> for unknown reasons.

Pity.
I tested it on a virtual W2K SP4 machine, and it works without problem in a
net-to-net configuration with TAP adapters and separate subnet for the VPN.
(CentOS4 server).

Only remarkable thing is that I get an error in the W2K logs about the
address refused by the DHCP server, but the TAP interface gets it's
address....


Do you have no information in the Windows event viewer?


Kind regards,