OK, now that we have a lot of information, let's go through what's here.
> # defaults for subsequent connection descriptions > conn %default > # How persistent to be in (re)keying negotiations (0 means very). > keyingtries=0 > # RSA authentication with keys from DNS. > # authby=rsasig > # leftrsasigkey=%dns > # rightrsasigkey=%dns > authby=secret > left=ip.pub.lik.254 > leftsubnet=192.168.0.0/24 > leftfirewall=yes > pfs=yes > auto=add > > conn w2k-road-warriors > right=%any > Everything looks plausible here. I would get rid of the unnecessary connections. We truly wish you wouldn't change lines to hide your public ip address... You spend a lot of time doing it, you can make errors by hiding it, and we could get it if we wanted anyway. Changing it will not protect you from getting hacked if someone wanted to (and believe me, noone here has any interest in hacking you). I would also get rid of the *firewall=yes line, if the connection goes down, you will be forced to reboot the firewall to reconnect, which may be the problem....see later in the post. I have information on manually setting the firewall to allow the connections w/o this option at http://leaf.sourceforge.net/devel/guitarlynn/ipsec.txt and Tom has instruction for doing the same on http://www.shorewall.net or http://leaf.sourceforge.net/devel/jnilo/buipsec.html#AEN1436 . > Nov 16 13:35:34 firewall ipsec_setup: Starting FreeS/WAN IPsec > 1.98b... Nov 16 13:35:35 firewall ipsec_setup: Using > /lib/modules/ipsec.o Nov 16 13:35:35 firewall ipsec_setup: KLIPS > ipsec0 on ppp0 ip.pub.lik.254 peer ip.pub.lik.1/32 > Nov 16 13:35:35 firewall ipsec_setup: ...FreeS/WAN IPsec started > Nov 16 13:38:37 firewall kernel: Shorewall:FORWARD:REJECT:IN=ipsec0 > OUT=eth1 SRC=62.147.151.223 DST=192.168.0.201 LEN=89 TOS=0x00 > PREC=0x00 TTL=127 ID=60576 PROTO=UDP SPT=3309 DPT=161 LEN=69 OK, ipsec starts, then rejects a packet from the roadwarrior, we'll check for the error further down. > + _________________________ plog > + > + sed -n 2,$p /var/log/auth.log > + egrep -i pluto > + cat > Nov 16 13:35:35 firewall ipsec__plutorun: Starting Pluto subsystem... > Nov 16 13:35:35 firewall pluto[24215]: Starting Pluto (FreeS/WAN > Version 1.98b) Nov 16 13:35:35 firewall pluto[24215]: including > X.509 patch (Version 0.9.13) Nov 16 13:35:35 firewall pluto[24215]: > Could not change to directory '/etc/ipsec.d/cacerts' > Nov 16 13:35:35 firewall pluto[24215]: Could not change to directory > '/etc/ipsec.d/crls' > Nov 16 13:35:35 firewall pluto[24215]: loaded my default X.509 cert > file '/etc/x509cert.der' (7 bytes) > Nov 16 13:35:35 firewall pluto[24215]: file coded in unknown > format, discarded Nov 16 13:35:35 firewall pluto[24215]: OpenPGP > certificate file '/etc/pgpcert.pgp' not found It appears to be trying to load a x509 cert, If I remember correctly the Bering ipsec package(s) offer seperate packages for use of x509 certs, but this could be a possible problem. I know Dachstein offers an add-on package for x509 certs. > Nov 16 13:35:36 firewall pluto[24215]: added connection description > "sample" Nov 16 13:35:37 firewall pluto[24215]: added connection > description "w2k-road-warriors" > Nov 16 13:35:37 firewall pluto[24215]: listening for IKE messages > Nov 16 13:35:37 firewall pluto[24215]: adding interface ipsec0/ppp0 > ip.pub.lik.254 Nov 16 13:35:37 firewall pluto[24215]: loading secrets > from "/etc/ipsec.secrets" Nov 16 13:38:36 firewall pluto[24215]: > packet from 62.147.151.223:500: ignoring Vendor ID payload > Nov 16 13:38:36 firewall pluto[24215]: "w2k-road-warriors"[1] > 62.147.151.223 #1: responding to Main Mode from unknown peer > 62.147.151.223 > Nov 16 13:38:36 firewall pluto[24215]: "w2k-road-warriors"[1] > 62.147.151.223 #1: Peer ID is ID_IPV4_ADDR: '62.147.151.223' > Nov 16 13:38:36 firewall pluto[24215]: "w2k-road-warriors"[1] > 62.147.151.223 #1: sent MR3, ISAKMP SA established > Nov 16 13:38:37 firewall pluto[24215]: "w2k-road-warriors"[1] > 62.147.151.223 #2: responding to Quick Mode Here your "w2k-road-warriors" tunnel comes up successfully, all that has not happened here is the successful transmission of information across the tunnel. > Nov 16 13:38:37 firewall pluto[24215]: "w2k-road-warriors"[1] > 62.147.151.223 #2: route-client output: RTNETLINK answers: Network is > unreachable Nov 16 13:38:37 firewall pluto[24215]: This is the indication of the problem. For some reason, the network becomes unreachable and/or the tunnel bombs out. Why this is happening is the only unclear problem, I can't say clearly and monitoring tcpdump may be the only good way of locating exactly why. Possibly your ISP is blocking the packets or the road-warrior kills the connection. The rest of the log indicates that the boxes attempt to restart the tunnel, but fail. This is what normally happens after a dropped tunnel with the *firewall=yes" option and why I do not suggest using this option. I hope this helps, ~Lynn -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
