I might further add here that host1 has only ipv4 support whereas host2 has both ipv4 and ipv6 support. I am not sure whether this information does matter in the creation of the sockets for charon.
> > 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
