I'm going to try to connect with another ISP, giving away the "firewall=yes" and trace packets with tcpdump.
Ill' inform the list with my investigation.
Thanks a lot
Stephane
guitarlynn wrote:
OK, now that we have a lot of information, let's go through what's here.
# defaults for subsequent connection descriptionsEverything looks plausible here. I would get rid of the unnecessary
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
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 IPsecOK, ipsec starts, then rejects a packet from the roadwarrior, we'll
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
check for the error further down.
+ _________________________ plogIt appears to be trying to load a x509 cert, If I remember correctly the
+
+ 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
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 descriptionHere your "w2k-road-warriors" tunnel comes up successfully, all that has not happened here is the successful transmission
"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
of information across the tunnel.
Nov 16 13:38:37 firewall pluto[24215]: "w2k-road-warriors"[1]This is the indication of the problem. For some reason, the
62.147.151.223 #2: route-client output: RTNETLINK answers: Network is
unreachable Nov 16 13:38:37 firewall pluto[24215]:
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
-------------------------------------------------------
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
