Hi Daniel/Andreas, Can you please have a look at these logs and tell me why ikev2 is not working with plutostart=yes ?
It is kind of urgent and it will be really nice of you guys to provide comments on it. Thanks in advance! regards, Ashish. On Mon, Jan 11, 2010 at 1:56 PM, ashish mahalka <[email protected]> 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 > rightsubnet=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]>> > 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
