Networking Forums

Networking Forums > Computer Networking > Linux Networking > VPNclient, protocol ESP, AH and firewall

Reply
Thread Tools Display Modes

VPNclient, protocol ESP, AH and firewall

 
 
Matthias Apitz
Guest
Posts: n/a

 
      07-11-2005, 08:38 AM


I've setup a connection to a remote side using Cisco VPNclient on
Linux SuSE 8.1 which is working and I have some question.

My side is connected to the Internet with an application gateway
firewall, having to NIC, one for the inner side 193.31.10.90 and
one for the outer space; all traffic which wants to go out have to
be directed to the inner NIC and in the firewall there are applications,
in the case of IPsec for VPN it is 'udprelay', redirecting the
IP traffic to the real direction, my Linux box has the addr 193.31.10.34
and so the picture goes like this:

193.31.10.34 ---> 193.31.10.90 firewall 193.31.11.194 ----> remote VPNserver

for the Cisco VPNclient I've created two rules to forward UDP 500
and UDP 4500 to the remote VPNserver (the later one I've figured out
with tcpdump to make VPNclient happy); as I said: it works and
the VPN comes up like this:

$ vpnclient connect ....
Cisco Systems VPN Client Version 4.0.1 (A)
Copyright (C) 1998-2003 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Linux
Running on: Linux 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686

Initializing the VPN connection.
Contacting the gateway at 193.31.10.90
User Authentication for XXXX-XXXX-XXX...

Enter Username and Password.
Username [XXXXXXXX]: Password []:
Authenticating user.
Negotiating security policies.
Securing communication channel.
****XXXXXXXXXXXXX****

Authorized access only.

Do you wish to continue? (y/n):
Your VPN connection is secure.

VPN tunnel information.
Client address: xxx.xxx.xxx.xxx
Server address: 193.31.10.90
Encryption: 128-bit AES
Authentication: HMAC-SHA
IP Compression: None
NAT passthrough is active on port UDP 4500
Local LAN Access is disabled
...

These are the 'good news', now the questions because I want
to switch over to the use of FreeS/WAN and before doing this I want
to understand the things.

1.
All IPsec pages I've read, for example in Google, to bring IPsec
through a firewall say something about the UDP 500 port but also
about two more protocols 50 (ESP) and 51 (AH); I thought I will
never get IPsec to work with my type of firewall because I've no
idea how to bring ESP and AH through; but it works without these
and I also can't see any traffic for these protocols in the tcpdump
below; can someone bring a bit light into it?

2.
Regarding the port 4500, I don't configured this in my file
describing the connecting, so it must be chosen by the server,
isn't it?

3.
The tcpdump shows the startup of the VPN and later I was pinging
an addr over there:

- What kind of package are these 'isakmp'?
- When I do the ping for the addr xxx.xxx.xxx.xxx at remote site,
I can see the outgoing pkg as ICMP and the incoming as UDP on
port 4500, why I can't see both ICMP and both UDP (as result of
the transport of the ICMP in IPsec tunnel)?

Thanks in advance for any hint.

Matthias


# tcpdump -ni eth0 esp or udp port 500 or udp port 4500 or icmp
tcpdump: listening on eth0
09:00:46.710947 193.31.10.34.500 > 193.31.10.90.500: isakmp: phase 1 I agg: [|sa
] (DF)
09:00:49.201392 193.31.10.90.500 > 193.31.10.34.500: isakmp: phase 1 R agg: [|sa
]
09:00:49.267577 193.31.10.34.4500 > 193.31.10.90.4500: udp 160 (DF)
09:00:49.267671 193.31.10.34.4500 > 193.31.10.90.4500: udp 1 (DF)
09:00:49.336426 193.31.10.90.4500 > 193.31.10.34.4500: udp 104
09:00:49.389773 193.31.10.34.4500 > 193.31.10.90.4500: udp 88 (DF)
09:00:49.769371 193.31.10.90.4500 > 193.31.10.34.4500: udp 64
09:00:49.769720 193.31.10.34.4500 > 193.31.10.90.4500: udp 64 (DF)
09:00:49.771287 193.31.10.34.4500 > 193.31.10.90.4500: udp 176 (DF)
09:00:50.805442 193.31.10.90.4500 > 193.31.10.34.4500: udp 968
09:00:50.808433 193.31.10.34.4500 > 193.31.10.90.4500: udp 1032 (DF)
09:00:50.932794 193.31.10.90.4500 > 193.31.10.34.4500: udp 96
09:00:50.933076 193.31.10.90.4500 > 193.31.10.34.4500: udp 184
09:00:50.933378 193.31.10.34.4500 > 193.31.10.90.4500: udp 56 (DF)


09:00:56.259496 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:00:56.313022 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:00:57.265278 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:00:58.265278 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:00:58.689975 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:00:58.692997 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:00:59.275277 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:00:59.318850 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:01:00.285283 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:01:00.722175 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:01:01.295280 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:01:02.295284 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:01:02.688849 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:01:02.694542 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:01:03.305276 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:01:03.458722 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:01:04.315286 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:01:04.482212 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:01:05.325277 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:01:05.485970 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
09:01:06.335274 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
09:01:06.772958 193.31.10.90.4500 > 193.31.10.34.4500: udp 132



09:01:10.554121 193.31.10.34.4500 > 193.31.10.90.4500: udp 72 (DF)
09:01:10.554419 193.31.10.34.4500 > 193.31.10.90.4500: udp 88 (DF)
09:01:10.638364 193.31.10.90.4500 > 193.31.10.34.4500: udp 88
09:01:10.638426 193.31.10.34 > 193.31.10.90: icmp: 193.31.10.34 udp port 4500 un
reachable [tos 0xc0]

40 packets received by filter
0 packets dropped by kernel
 
Reply With Quote
 
 
 
 
Philippe WEILL
Guest
Posts: n/a

 
      07-11-2005, 10:42 AM


Matthias Apitz wrote:
>
> These are the 'good news', now the questions because I want
> to switch over to the use of FreeS/WAN and before doing this I want
> to understand the things.
>
> 1.
> All IPsec pages I've read, for example in Google, to bring IPsec
> through a firewall say something about the UDP 500 port but also
> about two more protocols 50 (ESP) and 51 (AH); I thought I will
> never get IPsec to work with my type of firewall because I've no
> idea how to bring ESP and AH through; but it works without these
> and I also can't see any traffic for these protocols in the tcpdump
> below; can someone bring a bit light into it?
>


When you have NAT it use udp on port 4500 ( Ipsec Nat Traversal ) for
transport and not ESP ( Encapsulated Security Payload ) or AH (
Authentication Header)

> 2.
> Regarding the port 4500, I don't configured this in my file
> describing the connecting, so it must be chosen by the server,
> isn't it?
>
> 3.
> The tcpdump shows the startup of the VPN and later I was pinging
> an addr over there:
>
> - What kind of package are these 'isakmp'?


ISAKMP is used for Key exange

> - When I do the ping for the addr xxx.xxx.xxx.xxx at remote site,
> I can see the outgoing pkg as ICMP and the incoming as UDP on
> port 4500, why I can't see both ICMP and both UDP (as result of
> the transport of the ICMP in IPsec tunnel)?


to see traffic in the tunnel you need to make your tcpdump on the tunnel
interface (ipsec0) not on the real interface

>
> Thanks in advance for any hint.
>
> Matthias
>
>
> # tcpdump -ni eth0 esp or udp port 500 or udp port 4500 or icmp
> tcpdump: listening on eth0
> 09:00:46.710947 193.31.10.34.500 > 193.31.10.90.500: isakmp: phase 1 I agg: [|sa
> ] (DF)
> 09:00:49.201392 193.31.10.90.500 > 193.31.10.34.500: isakmp: phase 1 R agg: [|sa
> ]
> 09:00:49.267577 193.31.10.34.4500 > 193.31.10.90.4500: udp 160 (DF)
> 09:00:49.267671 193.31.10.34.4500 > 193.31.10.90.4500: udp 1 (DF)
> 09:00:49.336426 193.31.10.90.4500 > 193.31.10.34.4500: udp 104
> 09:00:49.389773 193.31.10.34.4500 > 193.31.10.90.4500: udp 88 (DF)
> 09:00:49.769371 193.31.10.90.4500 > 193.31.10.34.4500: udp 64
> 09:00:49.769720 193.31.10.34.4500 > 193.31.10.90.4500: udp 64 (DF)
> 09:00:49.771287 193.31.10.34.4500 > 193.31.10.90.4500: udp 176 (DF)
> 09:00:50.805442 193.31.10.90.4500 > 193.31.10.34.4500: udp 968
> 09:00:50.808433 193.31.10.34.4500 > 193.31.10.90.4500: udp 1032 (DF)
> 09:00:50.932794 193.31.10.90.4500 > 193.31.10.34.4500: udp 96
> 09:00:50.933076 193.31.10.90.4500 > 193.31.10.34.4500: udp 184
> 09:00:50.933378 193.31.10.34.4500 > 193.31.10.90.4500: udp 56 (DF)
>
>
> 09:00:56.259496 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:00:56.313022 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:00:57.265278 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:00:58.265278 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:00:58.689975 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:00:58.692997 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:00:59.275277 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:00:59.318850 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:01:00.285283 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:01:00.722175 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:01:01.295280 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:01:02.295284 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:01:02.688849 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:01:02.694542 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:01:03.305276 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:01:03.458722 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:01:04.315286 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:01:04.482212 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:01:05.325277 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:01:05.485970 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
> 09:01:06.335274 193.31.10.34 > xxx.xxx.xxx.xxx: icmp: echo request (DF)
> 09:01:06.772958 193.31.10.90.4500 > 193.31.10.34.4500: udp 132
>
>
>
> 09:01:10.554121 193.31.10.34.4500 > 193.31.10.90.4500: udp 72 (DF)
> 09:01:10.554419 193.31.10.34.4500 > 193.31.10.90.4500: udp 88 (DF)
> 09:01:10.638364 193.31.10.90.4500 > 193.31.10.34.4500: udp 88
> 09:01:10.638426 193.31.10.34 > 193.31.10.90: icmp: 193.31.10.34 udp port 4500 un
> reachable [tos 0xc0]
>
> 40 packets received by filter
> 0 packets dropped by kernel

 
Reply With Quote
 
Matthias Apitz
Guest
Posts: n/a

 
      07-11-2005, 11:04 AM
Philippe WEILL <(E-Mail Removed)> writes:

Thanks for your quick and kind answer;

>Matthias Apitz wrote:
>>

...
>> 1.
>> All IPsec pages I've read, for example in Google, to bring IPsec
>> through a firewall say something about the UDP 500 port but also
>> about two more protocols 50 (ESP) and 51 (AH); I thought I will
>> never get IPsec to work with my type of firewall because I've no
>> idea how to bring ESP and AH through; but it works without these
>> and I also can't see any traffic for these protocols in the tcpdump
>> below; can someone bring a bit light into it?
>>


>When you have NAT it use udp on port 4500 ( Ipsec Nat Traversal ) for
>transport and not ESP ( Encapsulated Security Payload ) or AH (
>Authentication Header)


On my site there is no router-NAT involved; the VPNclient is connecting
the inner NIC of my firewall and 'udprelay' put all UDP 500 and 4500
to the remote side. I don't have any information about the remote
end. In the config file of the VPNclient there is a line saying:

EnableNat=1

perhaps this triggers the use of NAT by the VPNclient; after establishing
the VPN it says something like:

VPN tunnel information.
Client address: xxx.xxx.xxx.xxx
Server address: 193.31.10.90

and xxx.xxx.xxx.xxx belongs to the same class-C network as the real
remote destination; but I can't see any interface or any routing
localy;

>> 3.
>> The tcpdump shows the startup of the VPN and later I was pinging
>> an addr over there:
>>
>> - What kind of package are these 'isakmp'?


>ISAKMP is used for Key exange


I've read a the docs of FreeS/WAN and it seems that ESP and AH
can be tunneled through UDP 500 and the daemon 'pluto' of FreeS/WAN
is doing that;

This is my main concern: Will it be enough for FreeS/WAN to have
UDP 500 open to the remote side?

>> - When I do the ping for the addr xxx.xxx.xxx.xxx at remote site,
>> I can see the outgoing pkg as ICMP and the incoming as UDP on
>> port 4500, why I can't see both ICMP and both UDP (as result of
>> the transport of the ICMP in IPsec tunnel)?


>to see traffic in the tunnel you need to make your tcpdump on the tunnel
>interface (ipsec0) not on the real interface


I don't have an interface ipsec0

matthias
 
Reply With Quote
 
Philippe WEILL
Guest
Posts: n/a

 
      07-12-2005, 07:44 AM


Matthias Apitz wrote:
> Philippe WEILL <(E-Mail Removed)> writes:
>
> Thanks for your quick and kind answer;
>
>
>>Matthias Apitz wrote:
>>

> ...
>
>>>1.
>>>All IPsec pages I've read, for example in Google, to bring IPsec
>>>through a firewall say something about the UDP 500 port but also
>>>about two more protocols 50 (ESP) and 51 (AH); I thought I will
>>>never get IPsec to work with my type of firewall because I've no
>>>idea how to bring ESP and AH through; but it works without these
>>>and I also can't see any traffic for these protocols in the tcpdump
>>>below; can someone bring a bit light into it?
>>>

>
>
>>When you have NAT it use udp on port 4500 ( Ipsec Nat Traversal ) for
>>transport and not ESP ( Encapsulated Security Payload ) or AH (
>>Authentication Header)

>
>
> On my site there is no router-NAT involved; the VPNclient is connecting
> the inner NIC of my firewall and 'udprelay' put all UDP 500 and 4500
> to the remote side. I don't have any information about the remote
> end. In the config file of the VPNclient there is a line saying:
>
> EnableNat=1


This line say that the client should use ESP encapsulation over UDP
http://www.osronline.com/ddkx/network/209offl_4tev.htm


>
> perhaps this triggers the use of NAT by the VPNclient; after establishing
> the VPN it says something like:


This line say that the client should use ESP encapsulation over UDP

this setup allow ipsec to work over most network setup you could find
for the client

>
> VPN tunnel information.
> Client address: xxx.xxx.xxx.xxx
> Server address: 193.31.10.90
>
> and xxx.xxx.xxx.xxx belongs to the same class-C network as the real
> remote destination; but I can't see any interface or any routing
> localy;
>
>
>>>3.
>>>The tcpdump shows the startup of the VPN and later I was pinging
>>>an addr over there:
>>>
>>>- What kind of package are these 'isakmp'?

>
>
>>ISAKMP is used for Key exange

>
>
> I've read a the docs of FreeS/WAN and it seems that ESP and AH
> can be tunneled through UDP 500 and the daemon 'pluto' of FreeS/WAN
> is doing that;
>
> This is my main concern: Will it be enough for FreeS/WAN to have
> UDP 500 open to the remote side?


it's depend on the config

>
>
>>>- When I do the ping for the addr xxx.xxx.xxx.xxx at remote site,
>>> I can see the outgoing pkg as ICMP and the incoming as UDP on
>>> port 4500, why I can't see both ICMP and both UDP (as result of
>>> the transport of the ICMP in IPsec tunnel)?

>
>
>>to see traffic in the tunnel you need to make your tcpdump on the tunnel
>>interface (ipsec0) not on the real interface


in cisco client it's perhaps tun0

>
>
> I don't have an interface ipsec0
>
> matthias



When you have work with ipsec, you find after that OpenVPN is a great
thing ;-)
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cisco vpnclient 4.8.00 on x86_64 FC5: Failed to establish a VPN connection Otto J. Makela Linux Networking 5 05-17-2007 08:36 AM
Enable VPN PPTP protocol in firewall logs out MS-Messenge Icarus Windows Networking 1 11-14-2005 10:22 PM
HOW FIREWALL WORKS WITH URL FILTERING SERVER USING UFP PROTOCOL siddurampure@yahoo.co.in Linux Networking 0 01-25-2005 05:59 AM
ADSL Firewall not passing Web protocol Dave Stauffer Linux Networking 1 12-23-2003 12:08 PM
VPN using ESP protocol, problems with firewall Jon Rook Linux Networking 1 08-14-2003 06:39 AM



1 2 3 4 5 6 7 8 9 10 11