Yeah, I have been through it pretty thoroughly (and I did find config mistakes that I'd made ;-)).Likely this is a incorrect option set up on the WinXP client. The Bering Users manual ( http://leaf.sourceforge.net/devel/jnilo/buipsec.html#AEN1436 ) has instructions for Win2K, if they help. Possibly Chad Carr or someone else that has connected with WinXP could help here.
This is a wireless link running from my main router - a Dachstein box - to a subnet that is hanging off this new Bering box. So the Bering router is a on one of the subnets of the Dachstein box (192.168.2.0/24). This link and both routers work great. The XP box is a laptop that is also on the 192.168.2.0/24 subnet and is able to ssh into boxes hanging off either of the routers. Shorewall is set to ignore RFC1918 on the Bering box in the Shorewall interface set up. (Shorewall is not running on the Dachstein box)> What auth.log shows when I attempt to connect: > Nov 16 23:02:37 beringfirewall ipsec__plutorun: Starting Pluto > subsystem... Nov 16 23:02:37 beringfirewall pluto[7363]: Starting > Pluto (FreeS/WAN Version 1.98b) > Nov 16 23:02:38 beringfirewall pluto[7363]: added connection > description "w2k-road-warriors" > Nov 16 23:02:38 beringfirewall pluto[7363]: listening for IKE > messages Nov 16 23:02:38 beringfirewall pluto[7363]: adding interface > ipsec0/eth0 192.168.2.253 > Nov 16 23:02:38 beringfirewall pluto[7363]: loading secrets from > "/etc/ipsec.secrets" > Nov 16 23:03:50 beringfirewall pluto[7363]: packet from > 192.168.2.1:500: ignoring Vendor ID payload > Nov 16 23:03:50 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #1: responding to Main Mode from unknown peer 192.168.2.1 > Nov 16 23:03:50 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #1: sent MR3, ISAKMP SA established > Nov 16 23:03:51 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #2: responding to Quick Mode > Nov 16 23:03:51 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #2: IPsec SA establishedHmm.... it appears to be extremly strange to be connecting to rfc1918 class address via the internet (or even having Shorewall accept anything from this address). Could we get some more information on the WAN link?
Yeah, I have done that. The messages you are seeing are occurring despite the spoofprotect option being set to "no". IIRC, IPsec seems to return this message regardless.> > IPsec start up > # /etc/init.d/ipsec start > ipsec_setup: Starting FreeS/WAN IPsec 1.98b... > ipsec_setup: Using /lib/modules/ipsec.o > ipsec_setup: WARNING: eth0 has route filtering turned on, KLIPS may > not work ipsec_setup: (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', > should be 0) This is a problem. I believe you will have to change this option. This is noted in the Bering User Manual: Quote "You must not turn on route filtering for any interfaces involved in ipsec. The "Bering recommended" way to turn this off is to use the /etc/network/options file and change the "spoofprotect" parameter to "no"
I'm sitting behind DSL that is NATted by the ISP. My Dachstein router breaks that up into a bunch of of 192.168.x.x/24 subnets, all of which work fine. One of of the subnets is 192.168.2.0/24, on which the Bering box sits. The Bering box "hides" a single 192.168.3.0/24 subnet. Boxes on that subnet are able to reach the Internet fine using the Bering box as their first hop, then the Dachstein box and then whatever my ISP has imposed. I run it like this because the servers can't be near the main DSL router for space and noise reasons. They sit on the 192.168.3.0/24 subnet hosts in a different room.> + ip route > 192.168.2.1 via 192.168.2.1 dev ipsec0 > 192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.254 > 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.253 > 192.168.2.0/24 dev ipsec0 proto kernel scope link src > 192.168.2.253 default via 192.168.2.254 dev eth0 This appears to be a very unclear test system. Using a 10./8 on the WAN would clarify a lot between WAN and LAN networks. Using the same net block addressing makes it much harder to see what is exactly going on.
> # 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 > # Following added by Lee just as above 3 commented by Lee > authby=secret > left=192.168.2.253 > leftsubnet=192.168.3.0/24 > leftfirewall=yes > pfs=yes > auto=add Get rid of the "leftfirewall-yes" entry, it will not allow a reconnection if a tunnel drops w/o a reboot. It will not be needed if Shorewall is configured correctly for ipsec.
Thanks, I didn't know that and will try it.
I have done. ;-) I've also tried manually setting /proc/sys/net/ipv4/conf/eth0/rp_filter = `0' but it does not fix the problem. It's a weird one.> + sed -n 210,$p /var/log/syslog > + egrep -i ipsec|klips|pluto > + cat > Nov 16 23:02:36 beringfirewall ipsec_setup: Starting FreeS/WAN IPsec > 1.98b... Nov 16 23:02:36 beringfirewall ipsec_setup: Using > /lib/modules/ipsec.o Nov 16 23:02:37 beringfirewall ipsec_setup: > KLIPS ipsec0 on eth0 192.168.2.253/24 broadcast 192.168.2.255 > Nov 16 23:02:37 beringfirewall ipsec_setup: WARNING: eth0 has route > filtering turned on, KLIPS may not work > Nov 16 23:02:37 beringfirewall > ipsec_setup: (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', should > be 0) Nov 16 23:02:37 beringfirewall ipsec_setup: ...FreeS/WAN IPsec > started + _________________________ plog Please turn off the route filtering as suggested in the Bering Users Manual. Ipsec will NOT work with it turned on via Shorewall.
Yeah, that seemed the most obvious reason to me too but I have turned this off both ways and it does not fix the problem. I do recall seeing a similar message displayed with a subnet-to-subnet tunnel that I ran between two Dachstein boxes and it did work, so I think this error message may be a hangover from the way Shorewall enables the connection.> + sed -n 224,$p /var/log/auth.log > + egrep -i pluto > + cat > Nov 16 23:02:37 beringfirewall ipsec__plutorun: Starting Pluto > subsystem... Nov 16 23:02:37 beringfirewall pluto[7363]: Starting > Pluto (FreeS/WAN Version 1.98b) > Nov 16 23:02:38 beringfirewall pluto[7363]: added connection > description "w2k-road-warriors" > Nov 16 23:02:38 beringfirewall pluto[7363]: listening for IKE > messages Nov 16 23:02:38 beringfirewall pluto[7363]: adding interface > ipsec0/eth0 192.168.2.253 > Nov 16 23:02:38 beringfirewall pluto[7363]: loading secrets from > "/etc/ipsec.secrets" > Nov 16 23:03:50 beringfirewall pluto[7363]: packet from > 192.168.2.1:500: ignoring Vendor ID payload > Nov 16 23:03:50 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #1: responding to Main Mode from unknown peer 192.168.2.1 > Nov 16 23:03:50 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #1: sent MR3, ISAKMP SA established > Nov 16 23:03:51 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #2: responding to Quick Mode > Nov 16 23:03:51 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #2: IPsec SA established The tunnel comes up successfully, but no information has been sent through the tunnel. > Nov 16 23:04:54 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #1: ignoring Delete SA payload > Nov 16 23:04:54 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #1: received and ignored informational message > Nov 16 23:09:24 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #1: ignoring Delete SA payload > Nov 16 23:09:24 beringfirewall pluto[7363]: "w2k-road-warriors"[1] > 192.168.2.1 #1: received and ignored informational message The Bering box is ignoring the information sent through the tunnel. Most likely this is because "rp_filter" is blocking the traffic sent through the tunnel. >From the Bering Users Manual: "You must not turn on route filtering for any interfaces involved in ipsec. The "Bering recommended" way to turn this off is to use the /etc/network/options file and change the "spoofprotect" parameter to "no" I believe this is your problem.
Thanks for your help - I really appreciate it.
-------------------------------------------------------
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
