[LONG] ipsec connection up, pinging other end impossible

This is a discussion on [LONG] ipsec connection up, pinging other end impossible within the Linux Networking forums, part of the Linux Forums category; Hi, [This going to be a rather lenghty post, so please read on, if you'd like. I've tried ...


Go Back   Usenet Forums > Linux Forums > Linux Networking

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 03-03-2004
Patrick Vervoorn
 
Posts: n/a
Default [LONG] ipsec connection up, pinging other end impossible


Hi,

[This going to be a rather lenghty post, so please read on, if you'd like.
I've tried to include as much information as possible.]

I'm trying to set up an ipsec connection between a Linux system at home,
and another Linux system somewhere else. The home-system is behind a NAT
router (a ZyXEL 650R33 ADSL modem in router mode). A quick sketch of it:

Linux home --- router --- internet --- firewall --- linux-server

After a lot of trying and configuring, I'm now running a rather old 2.4.24
kernel with the FreeSwan stuff (including their ipsec implementation) on
the home system (called 'test' ;), and can consistently get an ipsec
connection up. However, while nothing in the logs on both the home system
as well as the server system indicate anything goes wrong, I cannot ping
the linux-server from the home system once the connection is reported up.
Pinging the server is possible again once I ipsec auto --down the
connection.

I've been searching using Google, and have exhausted the knowledge of the
local people, so I'm now posting this here in the hope someone can help
me, by for instance pointing in the right direction.

Anyway, when bringing down the connection at both sides, and restarting it
from the home-system I see the following output (edited a bit):

# ipsec auto --up <conn>
104 "<conn>" #267: STATE_MAIN_I1: initiate
106 "<conn>" #267: STATE_MAIN_I2: sent MI2, expecting MR2
108 "<conn>" #267: STATE_MAIN_I3: sent MI3, expecting MR3
004 "<conn>" #267: STATE_MAIN_I4: ISAKMP SA established
112 "<conn>" #268: STATE_QUICK_I1: initiate
004 "<conn>" #268: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0xe575e767 <0x331d8d39}

(I can repeat this many times)

The /var/log/auth.log on the home Linux system shows the following (some
lines deleted):

Mar 3 14:32:37 test pluto[642]: "<conn>" #267: initiating Main Mode
Mar 3 14:32:38 test pluto[642]: "<conn>" #267: Peer ID is
ID_DER_ASN1_DN: '<key info>'
Mar 3 14:32:38 test pluto[642]: "<conn>" #267: crl update is
overdue since Feb 07 18:33:22 UTC 2003
Mar 3 14:32:38 test pluto[642]: "<conn>" #267: ISAKMP SA established
Mar 3 14:32:38 test pluto[642]: "<conn>" #268: initiating Quick
Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#267}
Mar 3 14:32:38 test pluto[642]: "<conn>" #268: sent QI2, IPsec SA
established {ESP=>0xe575e767 <0x331d8d39}

The log on the Linux server I'm making the connection with:

Mar 3 14:33:26 <name> pluto[2101]: "<conn>" #14732: responding to Main Mode
Mar 3 14:33:26 <name> pluto[2101]: "<conn>" #14732: Main mode
peer ID is ID_DER_ASN1_DN: '<conn>'
Mar 3 14:33:26 <name> pluto[2101]: "<conn>" #14732: Next CRL
update was expected on Feb 07 18:33:22 UTC 2003
Mar 3 14:33:26 <name> pluto[2101]: "<conn>" #14732: Next CRL
update was expected on Feb 07 18:33:22 UTC 2003
Mar 3 14:33:26 <name> pluto[2101]: "<conn>" #14732: sent MR3,
ISAKMP SA established
Mar 3 14:33:26 <name> pluto[2101]: "<conn>" #14733: responding to
Quick Mode
Mar 3 14:33:26 <name> pluto[2101]: "<conn>" #14733: IPsec SA established

So far so good; or in any case, I've been assured the above indicates a
successful ipsec connection has been made between these systems. However,
when I was running a 2.6.x.x kernel, I noticed the same thing: the
connection up, but no ping to the server was possible. Since I was using
the Linux native ipsec code, I was told it could be that that was the
problem (the server uses an older 2.2.x kernel, using the FreeSwan ipsec
code), so I downgraded to a 2.4.24ispec debian kernel, which included the
FreeSwan code, but am now experiencing the exact same problem.

So, I checked the other statuses. ipsec auto --status gives for instance
the right information for for instance the route, in any case, both show
something like (of course reversed for the server):

000 "<conn>": 192.168.1.12/32===192.168.1.12[<key-info>]---192.168.1.1...
<firewall-ip>---<linux server ip>[<key-info>]; erouted; eroute owner: #268

Should be OK?

The only strange thing is the output of the route command on the linux
server. It has a line:

192.168.1.12 <firewall-name> 255.255.255.255 UGH 0 0 0 ipsec0

where 192.168.1.12 is the internal IP of the Linux 'test' machine.
However, this route command shows for other, similar, connections not the
internal IP of that address, but the name of the system in question. So
that's maybe part of the problem? I have however no idea how to fix this.

On the home system, route shows:

Destination Gateway Genmask Flags Metric Ref Use Iface
<name> 192.168.1.1 255.255.255.255 UGH 0 0 0 ipsec0

Finally, the ipsec.conf's:

On the home-system:

conn <conn>
left=<linux server ip>
leftnexthop=<firewall-ip>
right=%defaultroute
rightsubnet=192.168.1.12/32
rightnexthop=
leftcert=<server-key<.pem
rightcert=<my-key>.pem
rightid=@patrick.home
auto=add

On the linux-server:

conn <conn>
right=<home-ip>
rightsubnet=192.168.1.12/32
rightnexthop=
rightcert=<key>.pem
rightid=@patrick.home
auto=add

Anyway, is there a way to find out what is going wrong with this
connection? It looks like I'm so close, and only missing one link?

Best regards,

Patrick.
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 02:32 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0