Hi Daniel, I have complied strongswan on both the host machines. I have not used -disable pluto option when running ./configure command.
"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" i haven't specified any option which says that charon is compiled for raw sockets. May be you can tell me what option to give while compiling charon. Meanwhile, I will run this command and get back to you with the results. Just to tell you that I am using strongswan 4.3.4. Thanks for all the help! regards, Ashish. On Wed, Jan 13, 2010 at 12:12 AM, Daniel Mentz < [email protected]<danielml%[email protected]> > wrote: > 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]<danielml%[email protected]><mailto: >> danielml%[email protected]<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
