<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Dear Oguz,<br>
<br>
Sorry for this long mail. I think I'd better assemble a new
document on my Web site explaining all this. This mail is a
follow-up of my previous mail, this time now taking into account
Paul's remark drawing attention onto the ip route command which
was confusing in his mail as he used a not as well performing
messaging facility as Thunderbird. Also Paul's network
configuration is not as simple and as demonstrative as mine. In
consequence, his ip route output is much more complex than mine.<br>
<br>
<b>PART ONE:</b><br>
<br>
My configuration has not changed since my last mail. It still
contains:<br>
leftsourceip=192.168.1.2<br>
<br>
The VPN with Shrew is established but before I issue the<br>
$ ping -c1 -I 192.168.2.101 <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a><br>
on the laptop, I have this information on my desktop:<br>
<br>
[philippe@victor ~]$ sudo systemctl restart ipsec.service<br>
[philippe@victor ~]$ route<br>
Kernel IP routing table<br>
Destination Gateway Genmask Flags Metric
Ref Use Iface<br>
default neufbox 0.0.0.0 UG 0
0 0 eth0<br>
link-local * 255.255.0.0 U 1002
0 0 eth0<br>
192.168.1.0 * 255.255.255.0 U 0
0 0 eth0<br>
[philippe@victor ~]$ ip route<br>
default via 192.168.1.1 dev eth0 <br>
169.254.0.0/16 dev eth0 scope link metric 1002 <br>
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
<br>
[philippe@victor ~]$ sudo /usr/local/sbin/ipsec auto --status |
grep established<br>
000 #2: "<b>Philippe_PSK</b>"[1] 192.168.1.5:500 <b>STATE_QUICK_R2</b>
(<b>IPsec SA established</b>); EVENT_SA_EXPIRE in 3559s; newest
IPSEC; eroute owner; isakmp#1; idle; import:not set<br>
000 #1: "<b>Philippe_PSK</b>"[1] 192.168.1.5:500 <b>STATE_MAIN_R3</b>
(sent MR3, <b>ISAKMP SA established)</b>; EVENT_SA_EXPIRE in
86315s; newest ISAKMP; lastdpd=10s(seq in:0 out:0); idle;
import:not set<br>
<br>
After I issue $ ping -c1 -I 192.168.2.101 <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a> on the
laptop,<br>
I read this on my desktop:<br>
<br>
[philippe@victor ~]$
route Kernel
IP routing table<br>
Destination Gateway Genmask Flags Metric
Ref Use Iface<br>
default neufbox 0.0.0.0 UG 0
0 0 eth0<br>
link-local * 255.255.0.0 U 1002
0 0 eth0<br>
192.168.1.0 * 255.255.255.0 U 0
0 0 eth0<br>
192.168.2.101 neufbox 255.255.255.255 UGH 0
0 0 eth0<br>
[philippe@victor ~]$ ip
route default
via 192.168.1.1 dev eth0 <br>
169.254.0.0/16 dev eth0 scope link metric 1002 <br>
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
<br>
192.168.2.101 via 192.168.1.1 dev eth0 src 192.168.1.2 <br>
[philippe@victor ~]$ ping -R -c 1 192.168.2.101<br>
PING 192.168.2.101 (192.168.2.101) 56(124) bytes of data.<br>
64 bytes from 192.168.2.101: icmp_req=1 ttl=64 time=11.5 ms<br>
RR: 192.168.1.2<br>
192.168.2.101<br>
192.168.2.101<br>
192.168.1.2<br>
<br>
<br>
--- 192.168.2.101 ping statistics ---<br>
1 packets transmitted, 1 received, 0% packet loss, time 0ms<br>
rtt min/avg/max/mdev = 11.569/11.569/11.569/0.000 ms<br>
<br>
My guess is that the last ping works fine <b>without</b> -I
192.168.1.2 on my desktop because of this information in the ip
route output in bold:<br>
192.168.2.101 via 192.168.1.1 dev eth0 <b>src 192.168.1.2 </b><br>
<br>
<b>PART TWO:</b><br>
<br>
To make sure of this statement, I stopped Shrew on the laptop,
commented out leftipsource=192.168.1.2 in my Philippe_PSK
connection, restarted ipsec on my desktop and finally Shrew on the
laptop.<br>
<br>
One noticeable difference which comes up on the laptop is that now<br>
$ ping -I 192.168.2.101 -c 1 <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a><br>
looses all ICMP packets.<br>
<br>
On the desktop:<br>
$ sudo /usr/local/sbin/ipsec auto --status | grep established<br>
shows no change<br>
$ route -n<br>
shows no change<br>
[philippe@victor ~]$ ip
route default
via 192.168.1.1 dev eth0 <br>
169.254.0.0/16 dev eth0 scope link metric 1002 <br>
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
<br>
192.168.2.101 via 192.168.1.1 dev eth0 <br>
<br>
If you consider the last line of the last ip route line, it lost <b>src
192.168.1.2</b>. This should now explain the lack of route of
information for the ICMP packet from <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a> to return back to
the laptop issuer.<br>
<br>
Now to be as close as your case and strangely:<br>
[philippe@victor ~]$ ping -R -c 1
192.168.2.101 PING 192.168.2.101
(192.168.2.101) 56(124) bytes of data.<br>
64 bytes from 192.168.2.101: icmp_req=1 ttl=64 time=6.03 ms<br>
RR: 192.168.1.2<br>
192.168.2.101<br>
192.168.2.101<br>
192.168.1.2<br>
<br>
<br>
--- 192.168.2.101 ping statistics ---<br>
1 packets transmitted, 1 received, 0% packet loss, time 0ms<br>
rtt min/avg/max/mdev = 6.031/6.031/6.031/0.000 ms<br>
[philippe@victor ~]$ arp
-a neufbox
(192.168.1.1) at 00:25:15:3d:46:30 [ether] PERM on eth0<br>
vova.vouters.dyndns.org (192.168.1.5) at 00:14:a5:b4:48:29 [ether]
on eth0<br>
<br>
<b>The big question is now how the desktop managed to know it has
to use 192.168.1.2 to reach 192.168.2.101 ????<br>
</b><br>
Also another noticeable fact on the laptop after the ping from the
desktop:<br>
$ ping -I 192.168.2.101 -c 1 <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a><br>
<b>is now successful</b><br>
<br>
I have not yet any absolute answer to this. However an answer may
come from:<br>
<br>
From one terminal on the desktop:<br>
<br>
[philippe@victor ~]$ sudo ip xfrm state<br>
<b>src 192.168.1.5 dst 192.168.1.2</b><br>
proto esp spi 0x01a784fb reqid 16405 mode <b>tunnel</b><br>
replay-window 32 flag af-unspec<br>
auth-trunc hmac(sha1)
0xbe3e8d29a6021ffd864d87456e6b01a3c94eebec 96<br>
enc cbc(aes)
0x647e6d49047810ec495d68fc576bd28cb3b90798bb3a6abb<br>
<b>src 192.168.1.2 dst 192.168.1.5</b><br>
proto esp spi 0x0caf0777 reqid 16405 mode <b>tunnel</b><br>
replay-window 32 flag af-unspec<br>
auth-trunc hmac(sha1)
0x1ec60d27cd430917a4c55a40e55500bcef9da3a0 96<br>
enc cbc(aes)
0xb3db5b710a1ad31c23a3ba8071b2c3f6e27af9f7a8468685<br>
<br>
From another terminal on the desktop:<br>
<br>
[philippe@victor ~]$ ping -R -c 1 192.168.2.101<br>
PING 192.168.2.101 (192.168.2.101) 56(124) bytes of data.<br>
64 bytes from 192.168.2.101: icmp_req=1 ttl=64 time=6.31 ms<br>
RR: 192.168.1.2<br>
192.168.2.101<br>
192.168.2.101<br>
192.168.1.2<br>
<br>
<br>
--- 192.168.2.101 ping statistics ---<br>
1 packets transmitted, 1 received, 0% packet loss, time 0ms<br>
rtt min/avg/max/mdev = 6.316/6.316/6.316/0.000 ms<br>
[philippe@victor ~]$ <br>
<br>
From the first terminal the 'ip xfrm monitor' command was prior
issued<br>
<br>
[philippe@victor ~]$ sudo ip xfrm monitor<br>
Async event (0x10) replay update <br>
src 192.168.1.2 dst 192.168.1.5 reqid 0x4015 protocol
esp SPI 0xcaf0777<br>
Async event (0x10) replay update <br>
src 192.168.1.5 dst 192.168.1.2 reqid 0x4015 protocol
esp SPI 0x1a784fb<br>
<br>
With the $ ping -R -c1 <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a> issued again on the laptop:<br>
<br>
[philippe@victor ~]$ sudo ip xfrm monitor<br>
... (as above)<br>
Async event (0x20) timer expired <br>
src 192.168.1.5 dst 192.168.1.2 reqid 0x4015 protocol
esp SPI 0x1a784fb<br>
Async event (0x20) timer expired <br>
src 192.168.1.2 dst 192.168.1.5 reqid 0x4015 protocol
esp SPI 0xcaf0777<br>
Async event (0x20) timer expired <br>
src 192.168.1.5 dst 192.168.1.2 reqid 0x4015 protocol
esp SPI 0x1a784fb<br>
Async event (0x20) timer expired <br>
src 192.168.1.2 dst 192.168.1.5 reqid 0x4015 protocol
esp SPI 0xcaf0777<br>
Async event (0x20) timer expired <br>
src 192.168.1.5 dst 192.168.1.2 reqid 0x4015 protocol
esp SPI 0x1a784fb<br>
Async event (0x20) timer expired <br>
src 192.168.1.2 dst 192.168.1.5 reqid 0x4015 protocol
esp SPI 0xcaf0777<br>
Async event (0x20) timer expired <br>
src 192.168.1.5 dst 192.168.1.2 reqid 0x4015 protocol
esp SPI 0x1a784fb<br>
Async event (0x20) timer expired <br>
src 192.168.1.2 dst 192.168.1.5 reqid 0x4015 protocol
esp SPI 0xcaf0777<br>
<br>
So this should explain that 192.168.2.101 (laptop) and 192.168.1.2
(desktop) can now talk to each other thanks to the xfrm layer (it
manages the tunnel) which has enough information to correctly
route the data between both ends.<br>
<br>
<b>APPARENT CONCLUSION:</b><br>
<br>
The presence of leftsourceip in the ipsec configuration forces a
route enabling immediate dialog between both ends.<br>
<br>
The absence of leftsourceip in the ipsec configuration prevents
the network layer to correctly know in advance which route to use.
Once traffic is established between both ends , the network layer
(especially xfrm) has enough information to correctly route the
packets.<br>
<br>
<b>APPARENT SUMMARY USING PING:</b><br>
<br>
With leftsourceip=192.168.1.2, the ping has to be issued from the
VPN end<br>
Without leftsourceip=192.168.1.2, the ping has to issued from the
VPN server<br>
<pre class="moz-signature" cols="72">Philippe Vouters (Fontainebleau/France)
URL: <a class="moz-txt-link-freetext" href="http://vouters.dyndns.org/">http://vouters.dyndns.org/</a>
SIP: <a class="moz-txt-link-abbreviated" href="mailto:sip:Vouters@sip.linphone.org">sip:Vouters@sip.linphone.org</a></pre>
Le 05/01/2013 16:55, Philippe Vouters a écrit :<br>
</div>
<blockquote cite="mid:50E84CFD.3010607@laposte.net" type="cite">Dear
Oguz,
<br>
<br>
My VPN client is Shrew VPN Client running on a Fedora 17 laptop
within my home network.
<br>
My initial configuration can be viewed at
<a class="moz-txt-link-freetext" href="http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven.html">http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven.html</a><br>
Simply stated Linux Fedora 17 has replaced Windows 7 and
<br>
192.168.2.101 is the Fedora 17 laptop VPN'ed address.
<br>
<br>
From the initial configuration and to work onto your leftsourceip
problem, I also added to Philippe_PSK connection the line:
<br>
<br>
leftsourceip=192.168.1.2
<br>
<br>
So that the 192.168.2.101 laptop's route establishes on my VPN
server (192.168.1.2 [my desktop]), I issued the following command
on the laptop:
<br>
$ ping -I 192.168.2.101 -c 1 <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a>
<br>
<br>
Note that this above action is specific to Linux and is NOT needed
on Windows 7 in exact same Shrew configuration.
<br>
<br>
After the ping action above on the laptop, I now read these routes
on my desktop (192.168.1.2):
<br>
<br>
[philippe@victor ~]$ route -n
<br>
Kernel IP routing table
<br>
Destination Gateway Genmask Flags Metric
Ref Use Iface
<br>
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0
eth0
<br>
169.254.0.0 0.0.0.0 255.255.0.0 U 1002
0 0 eth0
<br>
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
<br>
192.168.2.101 192.168.1.1 255.255.255.255 UGH 0 0 0
eth0
<br>
<br>
If I now ping 192.168.2.101 WITHOUT -I 192.168.1.2 from my
desktop, I get what you expect that you claimed this is an issue
with Libreswan which did NOT exist with Openswan.
<br>
<br>
[philippe@victor ~]$ ping 192.168.2.101
<br>
PING 192.168.2.101 (192.168.2.101) 56(84) bytes of data.
<br>
64 bytes from 192.168.2.101: icmp_req=1 ttl=64 time=3.99 ms
<br>
64 bytes from 192.168.2.101: icmp_req=2 ttl=64 time=3.64 ms
<br>
64 bytes from 192.168.2.101: icmp_req=3 ttl=64 time=4.76 ms
<br>
<br>
So can you provide us, when the VPN has established, the output of
<br>
$ route -n
<br>
$ ping -c 1 <the failing IP address>
<br>
$ ping -c 1 -I <IP interface> <the failing address>
<br>
<br>
Can you tell us where my successful test with my configuration
differs from your failing test using your configuration.
<br>
<br>
Kind regards,
<br>
<br>
Philippe Vouters (Fontainebleau/France)
<br>
URL: <a class="moz-txt-link-freetext" href="http://vouters.dyndns.org/">http://vouters.dyndns.org/</a>
<br>
SIP: <a class="moz-txt-link-abbreviated" href="mailto:sip:Vouters@sip.linphone.org">sip:Vouters@sip.linphone.org</a>
<br>
<br>
Le 02/01/2013 09:35, Oguz Yilmaz a écrit :
<br>
<blockquote type="cite">I think, this is the first support mail
concerning libreswan-3.0. :) Good Luck.
<br>
<br>
I have previous leftsourceip definition. This makes the vpn
gateway
<br>
itself to be able to reach remote end, without forcibly defining
<br>
sourceip. With previous openswan-2.6.38, with leftsourceip
parameter I
<br>
can "ping someremoteclient". However with libreswan-3.0 it
requires
<br>
"ping -I 10.14.1.5 someremoteclient" to ping. Config is exactly
same.
<br>
I have thought leftsourceip param is not working.
<br>
<br>
<br>
Config is:
<br>
<br>
version 2.0
<br>
<br>
config setup
<br>
interfaces=%defaultroute
<br>
klipsdebug=none
<br>
plutodebug=none
<br>
nat_traversal=no
<br>
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!172.19.32.0/24<br>
protostack=netkey
<br>
<br>
<br>
conn %default
<br>
auto=add
<br>
<br>
conn myvpn
<br>
authby=secret
<br>
auth=esp
<br>
esp=3des-md5-96
<br>
left=LEFT_EXT_IP
<br>
leftsubnet=10.46.0.0/16
<br>
leftsourceip=10.46.1.5
<br>
right=RIGHT_EXT_IP
<br>
rightid=10.6.202.3
<br>
rightsubnets={10.6.0.0/16,192.168.2.0/24}
<br>
leftnexthop=LEFT_EXT_GW
<br>
disablearrivalcheck=no
<br>
auto=start
<br>
keylife=86400s
<br>
pfs=yes
<br>
keyexchange=ike
<br>
ikelifetime=86400s
<br>
ike=3des-md5-modp1024
<br>
dpdaction=restart
<br>
dpddelay=30
<br>
dpdtimeout=120
<br>
<br>
<br>
<br>
"ping 10.6.1.1" does not work
<br>
"ping -I 10.46.1.5 10.6.1.1" works
<br>
<br>
With openswan-2.6.38, both were working.
<br>
<br>
Kernel: 3.5.3
<br>
Libreswan: 3.0
<br>
OS: Centos 5
<br>
Stack: Netkey
<br>
<br>
<br>
<br>
Jan 2 10:18:23 2013 ipsec__plutorun: Starting Pluto
subsystem...
<br>
Jan 2 10:18:23 2013 pluto[18211]: nss directory plutomain:
/etc/ipsec.d
<br>
Jan 2 10:18:23 2013 pluto[18211]: NSS Initialized
<br>
Jan 2 10:18:23 2013 pluto[18211]: FIPS integrity support
[disabled]
<br>
Jan 2 10:18:23 2013 pluto[18211]: libcap-ng support [enabled]
<br>
Jan 2 10:18:23 2013 pluto[18211]: Linux audit support
[disabled]
<br>
Jan 2 10:18:23 2013 pluto[18211]: Starting Pluto (Libreswan
Version
<br>
3.0; Vendor ID OENiHcUfspQs) pid:18211
<br>
Jan 2 10:18:23 2013 pluto[18211]: Not able to open
<br>
/proc/sys/crypto/fips_enabled, returning non-fips mode
<br>
Jan 2 10:18:23 2013 pluto[18211]: Pluto is NOT running in FIPS
mode
<br>
Jan 2 10:18:23 2013 pluto[18211]: core dump dir: /var/run/pluto
<br>
Jan 2 10:18:23 2013 pluto[18211]: secrets file:
/etc/ipsec.secrets
<br>
Jan 2 10:18:23 2013 pluto[18211]: LEAK_DETECTIVE support
[disabled]
<br>
Jan 2 10:18:23 2013 pluto[18211]: OCF support for IKE
[disabled]
<br>
Jan 2 10:18:23 2013 pluto[18211]: SAref support [disabled]:
Protocol
<br>
not available
<br>
Jan 2 10:18:23 2013 pluto[18211]: SAbind support [disabled]:
Protocol
<br>
not available
<br>
Jan 2 10:18:23 2013 pluto[18211]: NSS crypto [enabled]
<br>
Jan 2 10:18:23 2013 pluto[18211]: XAUTH PAM support [enabled]
<br>
Jan 2 10:18:23 2013 pluto[18211]: HAVE_STATSD notification
support [disabled]
<br>
Jan 2 10:18:23 2013 pluto[18211]: Setting NAT-Traversal
port-4500
<br>
floating to off
<br>
Jan 2 10:18:23 2013 pluto[18211]: port floating activation
<br>
criteria nat_t=0/port_float=1
<br>
Jan 2 10:18:23 2013 pluto[18211]: NAT-Traversal support
[disabled]
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_enc():
Activating
<br>
OAKLEY_AES_CBC: Ok (ret=0)
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_hash():
Activating
<br>
OAKLEY_SHA2_512: Ok (ret=0)
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_hash():
Activating
<br>
OAKLEY_SHA2_384: Ok (ret=0)
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_hash():
Activating
<br>
OAKLEY_SHA2_256: Ok (ret=0)
<br>
Jan 2 10:18:23 2013 pluto[18211]: no helpers will be started,
all
<br>
cryptographic operations will be done inline
<br>
Jan 2 10:18:23 2013 pluto[18211]: Using Linux XFRM/NETKEY IPsec
<br>
interface code on 3.5.3
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_enc():
Activating
<br>
aes_ccm_8: Ok (ret=0)
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_add(): ERROR:
algo_type
<br>
\'0\', algo_id \'0\', Algorithm type already exists
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_enc():
Activating
<br>
aes_ccm_12: FAILED (ret=-17)
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_add(): ERROR:
algo_type
<br>
\'0\', algo_id \'0\', Algorithm type already exists
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_enc():
Activating
<br>
aes_ccm_16: FAILED (ret=-17)
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_add(): ERROR:
algo_type
<br>
\'0\', algo_id \'0\', Algorithm type already exists
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_enc():
Activating
<br>
aes_gcm_8: FAILED (ret=-17)
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_add(): ERROR:
algo_type
<br>
\'0\', algo_id \'0\', Algorithm type already exists
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_enc():
Activating
<br>
aes_gcm_12: FAILED (ret=-17)
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_add(): ERROR:
algo_type
<br>
\'0\', algo_id \'0\', Algorithm type already exists
<br>
Jan 2 10:18:23 2013 pluto[18211]: ike_alg_register_enc():
Activating
<br>
aes_gcm_16: FAILED (ret=-17)
<br>
Jan 2 10:18:23 2013 pluto[18211]: loaded CA cert file
<br>
\'cacert.pem\' (1143 bytes)
<br>
Jan 2 10:18:23 2013 pluto[18211]: Could not change to directory
<br>
\'/etc/ipsec.d/aacerts\': No such file or directory
<br>
Jan 2 10:18:23 2013 pluto[18211]: Could not change to directory
<br>
\'/etc/ipsec.d/crls\': 2 No such file or directory
<br>
Jan 2 10:18:23 2013 pluto[18211]: listening for IKE messages
<br>
Jan 2 10:18:23 2013 pluto[18211]: adding interface
eth9.102/eth9.102
<br>
LEFT_EXT_IP:500
<br>
Jan 2 10:18:23 2013 pluto[18211]: adding interface eth1/eth1
10.46.1.5:500
<br>
Jan 2 10:18:23 2013 pluto[18211]: adding interface eth0/eth0
169.254.1.1:500
<br>
Jan 2 10:18:23 2013 pluto[18211]: adding interface lo/lo
127.0.0.1:500
<br>
Jan 2 10:18:23 2013 pluto[18211]: adding interface lo/lo
::1:500
<br>
Jan 2 10:18:23 2013 pluto[18211]: loading secrets from
\"/etc/ipsec.secrets\"
<br>
Jan 2 10:18:23 2013 pluto[18211]: no secrets filename matched
<br>
\"/etc/ipsec.*.secrets\"
<br>
Jan 2 10:18:24 2013 pluto[18211]: added connection description
\"myvpn/0x1\"
<br>
Jan 2 10:18:24 2013 pluto[18211]: added connection description
\"myvpn/0x2\"
<br>
Jan 2 10:18:27 2013 pluto[18211]: \"myvpn/0x2\": terminating
SAs
<br>
using this connection
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: initiating
Main Mode
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: transition
from
<br>
state STATE_MAIN_I1 to state STATE_MAIN_I2
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1:
STATE_MAIN_I2:
<br>
sent MI2, expecting MR2
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: received
Vendor
<br>
ID payload [Cisco-Unity]
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: received
Vendor
<br>
ID payload [Dead Peer Detection]
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: ignoring
unknown
<br>
Vendor ID payload [0945ede6cbf922e41e391f9f0eefa0a6]
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: received
Vendor
<br>
ID payload [XAUTH]
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: transition
from
<br>
state STATE_MAIN_I2 to state STATE_MAIN_I3
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1:
STATE_MAIN_I3:
<br>
sent MI3, expecting MR3
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: Main mode
peer ID
<br>
is ID_IPV4_ADDR: \'10.6.202.3\'
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: transition
from
<br>
state STATE_MAIN_I3 to state STATE_MAIN_I4
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1:
STATE_MAIN_I4:
<br>
ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
<br>
cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1024}
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #1: Dead Peer
<br>
Detection (RFC 3706): enabled
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #2: initiating
Quick
<br>
Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK {using
isakmp#1
<br>
msgid:827c3b24 proposal=3DES(3)_192-MD5(1)_096
<br>
pfsgroup=OAKLEY_GROUP_MODP1024}
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #2: ignoring
<br>
informational payload, type IPSEC_RESPONDER_LIFETIME
msgid=827c3b24
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #2:
route-client
<br>
output: /usr/libexec/ipsec/_updown.netkey: doroute `ip route
replace
<br>
192.168.2.0/24 via 10.46.1.5 dev lo src 10.46.1.5\' failed
(RTNETLINK
<br>
answers: No such process)
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #2: Dead Peer
<br>
Detection (RFC 3706): enabled
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #2: transition
from
<br>
state STATE_QUICK_I1 to state STATE_QUICK_I2
<br>
Jan 2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #2:
STATE_QUICK_I2:
<br>
sent QI2, IPsec SA established tunnel mode {ESP=>0xe63085eb
<br>
<0x34323d6b xfrm=3DES_0-HMAC_MD5 NATOA=none NATD=none
DPD=enabled}
<br>
<br>
<br>
<br>
--
<br>
Oguz YILMAZ
<br>
_______________________________________________
<br>
Swan mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Swan@lists.libreswan.org">Swan@lists.libreswan.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.libreswan.org/mailman/listinfo/swan">https://lists.libreswan.org/mailman/listinfo/swan</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>