Ok, Ive taken it outside of vmware, and im still having the problem.
I'll lay out exactly what Im doing step by step here.
Lets say machine-A is 192.168.1.1, and machine-B is 192.168.1.10.
Machine-A is a gateway to the world for 192.168.1.0/24 (this doesn't
seem to be of relevance as im having the same problem in vmware and its
not a gateway)
There is no firewall turned on on either of them.
Here is the ipsec.conf file they share:
config setup
interfaces="ipsec0=eth1"
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes
conn %default
keyingtries=0
conn site1-site2
left=192.168.1.10
right=192.168.1.1
auto=add
authby=rsasig
leftid=@machine-B.company.com
rightid=@machine-A.company.com
leftrsasigkey=0sAQPYZFT1j5pg+sCB0lOoz9YimuCk/nzWBmppB/nmiVkh7DDPn2jNidFC
6OIMIpdeXlD6MJGitbpdi2+xkJEmXN44A37FYIVOxysqzZ0kllNpvmxVO4AT4as5WzsIrG9C
DZczM8h3
znlnTGzD71pCcL+lGBKai2gSsiXxdYIPA187tw==
rightrsasigkey=0sAQN0OWGS4yXNjNWeUSEDnLdGFf1nc0lWr+isFGx1MBV3SyQbfEYuTyJ
jGUnItRupMBO3iWAAzdSVhtN9+iLSyt7rPH3Du2oMxkmDQOxLaldqigT+TrwPOXiSIbJfr/r
3OUnJYYY
kLokCOzVkB8Gbs0eFaGrhA4ZEASsJy28Am4VX/Q==
I do /etc/init.d/ipsec start on either of them, and the ipsec auto --up
site1-site2. Here is the output
Machine-B:/home/turnerd# /etc/init.d/ipsec start
ipsec_setup: Starting FreeS/WAN IPsec 1.96...
ipsec_setup: WARNING: ipsec0 has route filtering turned on, KLIPS may
not work
ipsec_setup: (/proc/sys/net/ipv4/conf/ipsec0/rp_filter = `1', should be
0)
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)
Machine-B:/home/turnerd# ipsec auto --up site1-site2
104 "site1-site2" #1: STATE_MAIN_I1: initiate
106 "site1-site2" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "site1-site2" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "site1-site2" #1: STATE_MAIN_I4: ISAKMP SA established
112 "site1-site2" #2: STATE_QUICK_I1: initiate
004 "site1-site2" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
You can see the SA is established. I now try to ping 192.168.1.1 from
192.168.1.10, and nothing goes through. No counters increment on the
interface, however I see arp "who-has 192.168.1.1 tell 192.168.1.10"
while I tcpdump the main eth1 interface. I have found a case which
describes the exact problem I am having, with no followup at
http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/11/msg00086.html
Thank you for all your help so far, do you have any more ideas?
-- Dayton Turner Air Games Wireless Inc. Suite 204, 309 W. Cordova St. Vancouver BC V6B 1E5 Canada Tel: +1.604.408.2228 Fax: +1.604.408.2649 Cell: +1.604.710.2466 Email: dayton_at_airg.com Web: www.airg.com-----Original Message----- From: Henry Spencer [mailto:henry_at_spsystems.net] Sent: Monday, March 25, 2002 10:11 PM To: Dayton Turner Cc: users_at_lists.freeswan.org Subject: Re: [Users] Cant pass traffic through the VPN?!?!
On Mon, 25 Mar 2002, Dayton Turner wrote: > ...One machine (.64) is actually a vmware > window :P but it has a real ip, and communicates perfectly fine > normally, so I don't see this as an issue.
It might be. IPsec has a somewhat incestuous relationship with the hardware drivers, and I don't know whether anybody's ever tried it under VMware, which has to do some high and fancy fakery to give an imitation of PC hardware.
> Now when I ping or telnet or whatever between them, no traffic makes > it through. Tcpdump on either end verifies that the packets arent > making it.
"tcpdump -i ipsec0" will help confirm that the packets are actually getting into the IPsec machinery.
Given that, "ifconfig ipsec0" is of interest -- if its "dropped" count is incrementing, then the problem is in IPsec. If not, then the packets are getting lost somewhere after we process them, and it is almost certainly not an IPsec problem.
Henry Spencer henry_at_spsystems.net
_______________________________________________ Users mailing list Users_at_lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:19:46 CEST