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 ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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. |