Why more than 1 hole in FW for IPSec

Hi,

if my VPN GW is behind the firewall, why is it - generally, in theory -
neccessary to have the firewall open IP 50, 51 and UDP 500 (ISAKMP). Why
- in theory - is hasn't everything been designed to use ONE single
connection through one port and protocol? Why not e. g. use SSL/TLS with
PKI and that's it? Higher and lower level traffic can be packed and
tunneled through even a higher network layer, can't it?

Greetings,

René

René Matthäi wrote:

> Hi,
>
> if my VPN GW is behind the firewall, why is it - generally, in theory
> - neccessary to have the firewall open IP 50, 51 and UDP 500 (ISAKMP).

Usually you only need to open esp and isakmp. But it is not uncommon to
have the endpoints on firewalls. That way you can control on the
firewall itself if traffic is allowed or not.

> Why - in theory - is hasn't everything been designed to use ONE single
> connection through one port and protocol? Why not e. g. use SSL/TLS
> with PKI and that's it? Higher and lower level traffic can be packed
> and tunneled through even a higher network layer, can't it?

If you have a look at openvpn you will see that everthing is done over
one (nattable) port. It is design philosophy. Can't argue with that.
;-).

EJ
--
Remove the obvious part (including the dot) for my email address

Hi.

Stephen J. Bevan wrote:
> René Matthäi <(E-Mail Removed)> writes:
>
>>Why - in theory - is hasn't everything been designed to use
>>ONE single connection through one port and protocol? Why not e. g. use
>>SSL/TLS with PKI and that's it? Higher and lower level traffic can be
>>packed and tunneled through even a higher network layer, can't it?
>
> SSL/TLS was designed to run over a reliable transport (e.g. TCP) it
> wasn't designed to run over unreliable ones (any type of datagram).
> Also running TCP over TCP, as would be necessary if you tunnel
> everything via SSL, has various documented drawbacks.

You're right. But why then not choose layer 2 as protocol layer like L2TP?

In the internet I found both IPSec over L2TP and L2TP over IPSec. The
latter is what M$ favors. But why not prefer the other?

With L2TP (or tun or CIPE or tinc) you can connect any two networks
_really_ transparently (layer 3). FTP, LDAP, H.323 will work at once!

Cannot understand that... :-(

Would rather have understood if the IETF had proposed IPSec over L2TP
and not vice versa. What I have won with L2TP over IPSec are some things
of minor importance I think than what I spoke about above (FTP, LDAP
etc.). Ok - with that standard you facilitate setups with Road warriors
and so on.

René

René Matthäi <(E-Mail Removed)> writes:
> You're right. But why then not choose layer 2 as protocol layer like L2TP?

Choose in what sense? If I want to secure TCP packets from A->B I
need an IP packet containing some kind of header and the rest of the
data encrypted. That's what ESP is. If you need to connect multiple
networks then you can either use tunnel mode ESP or just use transport
mode to protect IP or GRE tunnels. The former is supported as default
by IKE daemons, the latter is not and only really works if you can
define the IP/GRE tunnels manually or are willing to hack on the IKE
daemon to have it do that instead of doing tunnel mode.

> In the internet I found both IPSec over L2TP and L2TP over IPSec. The
> latter is what M$ favors. But why not prefer the other?

Why use L2TP at all? So far you've spent more space discussing what
you think the solution to your problem is (L2TP) rather than saying
*exactly* what the problem is. By "exactly" I mean a network diagram
with addesses that make it clear what needs to be connected to what,
who gets to initiate connections, what NAT/PAT ... etc. devices
are between the endpoints, and between which points must traffic be
secured and which points can be in the clear.

René Matthäi wrote:

> Hi,
>
> sorry that I haven't yet written in this thread about my exact network
> config etc.
>
> Stephen J. Bevan wrote:
>>
>> Why use L2TP at all? So far you've spent more space discussing what
>> you think the solution to your problem is (L2TP) rather than saying
>> *exactly* what the problem is. By "exactly" I mean a network diagram
>> with addesses that make it clear what needs to be connected to what,
>> who gets to initiate connections, what NAT/PAT ... etc. devices
>> are between the endpoints, and between which points must traffic be
>> secured and which points can be in the clear.
> Our network looks as follows (first one branch office, then the other
> one):
>
> 192.168.0.0/24 --- FW/NAT --- DMZ --- FW/Portforwarding/NAT --- (INET)
>
> (INET) --- FW/Portforwarding/NAT --- 192.168.100.0/24
>
> I am still not sure where to put the VPN-GW for connecting the two
> branches. I want to have a setup in the end where traffic between any
> two of the hosts in any of the two subnets is secured via VPN.
>
> If we had only linux as OS, one could easily experiment with OE. But of
> course we have many M$ machines as well so help is required and
> appreciated As we are a medium IT company of about 20 hosts altogether,
> we want to do it ourselves. If possible, with open source. But hardware
> solutions and commercial software (client?!) products are possible, too.
>
> Regards,
>
>
> René Matthäi

Perhaps you should take a look at openvpn (http://openvpn.sourceforge.net),
it's licensed under the GPL... and it works fine for me... I only need to
open one UDP port on my firewalls... (and only if the traffic is comming
from the other IP-address)

prompt

--
Nico Declerck - netwerkbeheerder
UZGent - Dienst voor Inwendige Ziekten - afdeling Pneumologie
(E-Mail Removed) - 09/2402626

(E-Mail Removed) (Stephen J. Bevan) wrote in message news:<(E-Mail Removed)>...
> René Matthäi <(E-Mail Removed)> writes:
> > if my VPN GW is behind the firewall, why is it - generally, in theory
> > - neccessary to have the firewall open IP 50, 51 and UDP 500
> > (ISAKMP).
>
> The ESP protocol is used to carry encrypted traffic. There is no
> requirement that you use ISKAMP/IKE (and hence UDP 500) to setup the
> connection, though it is certainly by far the most common approach.
>
> > Why - in theory - is hasn't everything been designed to use
> > ONE single connection through one port and protocol? Why not e. g. use
> > SSL/TLS with PKI and that's it? Higher and lower level traffic can be
> > packed and tunneled through even a higher network layer, can't it?
>
> SSL/TLS was designed to run over a reliable transport (e.g. TCP) it
> wasn't designed to run over unreliable ones (any type of datagram).
> Also running TCP over TCP, as would be necessary if you tunnel
> everything via SSL, has various documented drawbacks.

OpenVPN is designed to multiplex SSL/TLS + actual IP datagrams over a
single UDP port. It does this by:

(1) Providing a reliability layer similar to TCP so that the SSL/TLS
connection can operate over UDP. SSL/TLS sees this reliability layer
which is indistinguishable from TCP but much more secure (64 bit
sequence number + HMAC authentication using SHA1 or any other secure
hash provided by OpenSSL).

(2) The SSL/TLS connection is used for remote host authentication and
initial key exchange.

(3) The EVP layer in the OpenSSL library is used to encrypt and
authenticate individual IP or ethernet packets which are then sent as
UDP datagrams.

(4) All packets are protected by encryption, HMAC, explicit IV, and
sliding window replay protection.

James

René Matthäi <(E-Mail Removed)> writes:
> 192.168.0.0/24 --- FW/NAT --- DMZ --- FW/Portforwarding/NAT --- (INET)
>
> (INET) --- FW/Portforwarding/NAT --- 192.168.100.0/24
>
> I am still not sure where to put the VPN-GW for connecting the two
> branches. I want to have a setup in the end where traffic between any
> two of the hosts in any of the two subnets is secured via VPN.

If you want traffic between any two *hosts* to be secure then you
cannot use a VPN-GW you have to do host<->host encryption. If on the
other hand you just want to make sure the traffic is secure across the
INET then you can use a VPN-GW on each side. The logical place to put
it would be to run it on the same box that does the
FW/Portforwarding/NAT on each side. Or if you don't want your traffic
to be in plain text in your DMZ then run it on the FW/NAT on and make
sure that the FW/Portforwarding/NAT box forwards all IPsec traffic to
that FW/NAT box.

(E-Mail Removed) (Stephen J. Bevan) wrote in message news:<(E-Mail Removed)>...
> (E-Mail Removed) (James Yonan) writes:
> > (E-Mail Removed) (Stephen J. Bevan) wrote in message news:<(E-Mail Removed)>...
> > > SSL/TLS was designed to run over a reliable transport (e.g. TCP) it
> > > wasn't designed to run over unreliable ones (any type of datagram).
> > > Also running TCP over TCP, as would be necessary if you tunnel
> > > everything via SSL, has various documented drawbacks.
> >
> > OpenVPN is designed to multiplex SSL/TLS + actual IP datagrams over a
> > single UDP port. It does this by:
> >
> > (1) Providing a reliability layer similar to TCP so that the SSL/TLS
> > connection can operate over UDP. SSL/TLS sees this reliability layer
> > which is indistinguishable from TCP but much more secure
>
> If it is indistinguishable then presumably it still suffers from the
> same timing related problems that occur when TCP is run over TCP. If
> not then it is distinguishable.

No, only the TLS/SSL connection is provided with a reliable transport
layer (as it is designed to operate over). The actual IP packets
after being encrypted and signed with an HMAC are tunnelled over UDP
without any reliability layer. So in no case are IP packets being
tunneled over a reliable transport.

SSL/TLS -> Reliability Layer -> \
\
\
> Multiplexer ----> UDP
/ Transport
IP Encrypt and Sign /
Tunnel -> using OpenSSL EVP --> /
Packets interface.

This model has the benefit that SSL/TLS sees a reliable transport
layer while the IP packet forwarder sees an unreliable transport layer
-- exactly what both components want to see.

The exception to "UDP Transport" is if the user explicitly chooses TCP
as a tunnel transport protocol. UDP is always recommended as a first
choice, but TCP is provided for cases where UDP isn't feasible.

James

Stephen J. Bevan wrote:

> (E-Mail Removed) (James Yonan) writes:
>> > SSL/TLS was designed to run over a reliable transport (e.g. TCP) it
>> > wasn't designed to run over unreliable ones (any type of datagram).
>> > Also running TCP over TCP, as would be necessary if you tunnel
>> > everything via SSL, has various documented drawbacks.
>>
>> OpenVPN is designed to multiplex SSL/TLS + actual IP datagrams over a
>> single UDP port. It does this by: ...
>
> With your other followup it is now clear that what you mean by SSL/TLS
> and what I mean by it are not quite the same thing. When I write
> SSL/TLS I mean the whole protocol, not just the part that does keying.
> Taking just the keying part and marrying it with your own format for
> encrypting IP packets is is an interesting approach. However, it
> isn't entirely clear to me how this an improvement over using
> IKE+IPsec. I have the same reaction to a bunch of other VPN solutions
> :-
>
> CIPE http://sites.inka.de/bigred/devel/cipe.html
> SLAN http://sourceforge.net/projects/slan/
> TINC http://tinc.nl.linux.org/
> VPND http://sunsite.dk/vpnd/
> VTUN http://vtun.sourceforge.net/
> YAVIPIN http://yavipin.sourceforge.net/
> ZEBEDEE http://www.winton.org.uk/zebedee/
>
> BTW it is not that I think IKE+IPsec is perfect by any means, it is
> just that it isn't clear to me that any of the alternative are better.

It is not so much that they are 'better', but sometimes better suited to
fit the needs. IKE+IPsec (and in particular some implementations like
frees/wan) do not really like nat. This is where one of the others come
in.

EJ
--
Remove the obvious part (including the dot) for my email address

(E-Mail Removed) (Stephen J. Bevan) writes:
[...]
> BTW it is not that I think IKE+IPsec is perfect by any means, it is
> just that it isn't clear to me that any of the alternative are
> better.

FWIW, N. Ferguson and B. Schneier did an analysis on IPsec and a
summary of their conclusion is:

We are of two minds about IPsec. On the one hand, IPsec is far
better than any IP security protocol that has come before:
Microsoft PPTP, L2TP, etc. On the other hand, we do not believe
that it will ever result in a secure operational system. It is
far too complex, and the complexity has lead to a large number of
ambiguities, contradictions, ine ciencies, and weaknesses. [...]
We strongly discourage the use of IPsec in its current form for
protection of any kind of valuable information, and hope that
future iterations of the design will be improved. However, we
even more strongly discourage any current alternatives, and
recommend IPsec when the alternative is an insecure network. Such
are the realities of the world.

http://www.counterpane.com/ipsec.html

--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI