Hi Ashish, I examined the log files. Here's what I think happens:
host2 (10.10.10.5) initiates a connection to host1 (10.10.10.2). host1 sends a packet back to host2 in response. For some reason, this response packet does not reach charon on host2. What you are saying is that the problem does not occur if pluto is disabled on host2. The following line in host2-charon.log caught my attention waiting for data on sockets Because you are using pluto and charon at the same time, charon should use a raw socket instead of UDP socket. So it should say waiting for data on raw sockets If charon uses a UDP socket, and it appears to do so, it competes with pluto for UDP packets. That's why it works ok if pluto is not running. Did you compile strongSwan by yourself or did you use some pre-compiled package? Did you specify --disable-pluto on the command line when running ./configure ? Use the following command to find out whether you compiled charon for raw sockets. strings /usr/lib/ipsec/charon | grep "waiting for data on raw socket" Does it give you some output? -Daniel ashish mahalka wrote: > Hi Daniel and Andreas, > > Here are the fresh logs for both the peers. tcpdump log is also there. > > r...@ipsec01-axc ~]# tcpdump -npi eth1 udp port 500 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes > 12:19:15.238009 IP 10.10.10.5.isakmp > 10.10.10.2.isakmp: isakmp: phase > 1 I #34[] > 12:19:15.371786 IP 10.10.10.2.isakmp > 10.10.10.5.isakmp: isakmp: phase > 1 R #34[] > 12:19:19.239717 IP 10.10.10.5.isakmp > 10.10.10.2.isakmp: isakmp: phase > 1 I #34[] > 12:19:19.246910 IP 10.10.10.2.isakmp > 10.10.10.5.isakmp: isakmp: phase > 1 R #34[] > 12:19:26.442665 IP 10.10.10.5.isakmp > 10.10.10.2.isakmp: isakmp: phase > 1 I #34[] > 12:19:26.449747 IP 10.10.10.2.isakmp > 10.10.10.5.isakmp: isakmp: phase > 1 R #34[] > > 6 packets captured > 6 packets received by filter > 0 packets dropped by kernel > > > config setup > strictcrlpolicy=no > nat_traversal=no > plutostart=yes > plutodebug=none > charonstart=yes > charondebug="dmn 2, mgr 2, ike 2, chd 2, job 2, cfg 2, knl 2, net 2, > lib 2" > > conn conn1 > type=tunnel > leftsubnet=10.10.10.0/24 <http://10.10.10.0/24> > rightsubnet=10.10.10.0/24 <http://10.10.10.0/24> > auto=start > left=10.10.10.5 > right=10.10.10.2 > leftsendcert=never > rightsendcert=never > leftcert=BTS_CERT_FILE.pem > rightcert=BTS_CERT_FILE.pem > rightid=%any > keyexchange=ikev2 > ike=aes128-sha1-modp1024! > pfs=no > ikelifetime=86400s > esp=aes128-sha1! > authby=pubkey > keylife=300s > keyingtries=%forever > dpdaction=restart > mobike=no > dpddelay=10 > dpdtimeout=125 > rekeyfuzz=50% > rekeymargin=180s > > When i set plutostart=no, i am able to establish ikev2. > > Please let me know your comments. > > Thanks in advance! > > regards, > Ashish. > On 1/7/10, *Daniel Mentz* <[email protected] > <mailto:danielml%[email protected]>> wrote: > > ashish mahalka wrote: > > Strongswan runs at the other end. i m not sure whether the > packets where reaching the other end or not. But one thing is > sure, there was no response from strongswan on the other end. > > > I'm afraid you have to find out whether the packets make it to the > other end. Are you familiar with tcpdump? > > tcpdump -npi ppp0 udp port 500 or 4500 > > should do the job. Replace ppp0 with the name of the interface you > want to sniff on. Also, keep an eye on the syslog output of > strongSwan at the remote end. > -Daniel > > _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
