<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">Paul,<br>
<br>
You seem to be fully right with the new addconn code. <b>No
leftsourceip= </b>in my configuration. However a question to
you: how do you interpret the 'addconn --verbose Philippe_PSK'
output at the end of this mail ? My actual configuration for this
run is fully described 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>
<br>
<br>
<b>On the Libreswan VPN server side</b><b>:</b><br>
<br>
[philippe@victor ~]$ sudo systemctl stop ipsec.service <br>
[philippe@victor ~]$ sudo systemctl start ipsec.service<br>
[philippe@victor ~]$ sudo ip xfrm state<br>
[philippe@victor ~]$ # laptop powered on and Shrew started again<br>
[philippe@victor ~]$ # NO ping -c 1 -I 192.168.2.101 <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a><br>
[philippe@victor ~]$ # issued from the laptop<br>
[philippe@victor ~]$ sudo /usr/local/sbin/ipsec auto --status |
grep established<br>
000 #2: "Philippe_PSK"[1] 192.168.1.5:500 STATE_QUICK_R2 (IPsec SA
established); EVENT_SA_EXPIRE in 3559s; newest IPSEC; eroute
owner; isakmp#1; idle; import:not set<br>
000 #1: "Philippe_PSK"[1] 192.168.1.5:500 STATE_MAIN_R3 (sent MR3,
ISAKMP SA established); EVENT_SA_EXPIRE in 86318s; newest ISAKMP;
lastdpd=7s(seq in:0 out:0); idle; import:not set<br>
[philippe@victor ~]$ sudo ip xfrm
state src 192.168.1.5 dst
192.168.1.2<br>
proto esp spi 0x8c62cee5 reqid 16405 mode tunnel<br>
replay-window 32 flag af-unspec<br>
auth-trunc hmac(sha1)
0xb750adf062264668848f14f25c63c066781215ee 96<br>
enc cbc(aes)
0x4cb13f3703b581dfa421ed48b2130fbe7f5809b49d718fe8<br>
src 192.168.1.2 dst 192.168.1.5<br>
proto esp spi 0x04699cdd reqid 16405 mode tunnel<br>
replay-window 32 flag af-unspec<br>
auth-trunc hmac(sha1)
0x9289cf562a6a507955790fc5a07e17bc4e0adf44 96<br>
enc cbc(aes)
0x5ffc73f62597be56ae70aebcb3d47f9781a60642f9d7ea15<br>
[philippe@victor ~]$ sudo 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>
192.168.2.101 via 192.168.1.1 dev eth0<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=5.70 ms<br>
RR: 192.168.1.2<br>
192.168.2.101<br>
192.168.2.101<br>
192.168.1.2<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 = 5.706/5.706/5.706/0.000 ms<br>
<br>
On the <b>Fedora 17 laptop side</b> running Shrew, it now shows:<br>
<br>
After Shrew has established the VPN<br>
<br>
[vladimir@pavilion ~]$ sudo ip xfrm state<br>
[vladimir@pavilion ~]$<br>
<br>
After $ ping -c 1 192.168.2.101 from the VPN server:<br>
<br>
[vladimir@pavilion ~]$ sudo ip xfrm state<br>
src 192.168.1.5 dst 192.168.1.2<br>
proto esp spi 0x8c62cee5 reqid 2 mode tunnel<br>
replay-window 4 <br>
auth-trunc hmac(sha1)
0xb750adf062264668848f14f25c63c066781215ee 96<br>
enc cbc(aes)
0x4cb13f3703b581dfa421ed48b2130fbe7f5809b49d718fe8<br>
sel src 0.0.0.0/0 dst 0.0.0.0/0 <br>
src 192.168.1.2 dst 192.168.1.5<br>
proto esp spi 0x04699cdd reqid 1 mode tunnel<br>
replay-window 4 <br>
auth-trunc hmac(sha1)
0x9289cf562a6a507955790fc5a07e17bc4e0adf44 96<br>
enc cbc(aes)
0x5ffc73f62597be56ae70aebcb3d47f9781a60642f9d7ea15<br>
sel src 0.0.0.0/0 dst 0.0.0.0/0 <br>
[vladimir@pavilion ~]$ sudo ip route <br>
default via <b>192.168.2.101 dev tap0 </b> proto static <br>
default via 192.168.1.1 dev wlan0 proto static <br>
192.168.1.0/24 dev wlan0 proto kernel scope link src
192.168.1.5 <br>
[vladimir@pavilion ~]$ <br>
<br>
And ping -R -c 1 <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a> on the laptop shows:<br>
<br>
[vladimir@pavilion ~]$ ping -R -c 1 <a class="moz-txt-link-abbreviated" href="http://www.ask.com">www.ask.com</a><br>
PING a1230.b.akamai.net (80.239.221.10) 56(124) bytes of data.<br>
64 bytes from 80-239-221-10.customer.teliacarrier.com
(80.239.221.10): icmp_req=1 ttl=52 time=151 ms<br>
RR: pavilion (192.168.2.101)<br>
vouters.dyndns.org (192.168.1.2)<br>
170.212.85.79.rev.sfr.net (79.85.212.170)<br>
22.235.64.86.rev.sfr.net (86.64.235.22)<br>
14.235.64.86.rev.sfr.net (86.64.235.14)<br>
86.93.20.93.rev.sfr.net (93.20.93.86)<br>
222.29.3.109.rev.sfr.net (109.3.29.222)<br>
249.29.3.109.rev.sfr.net (109.3.29.249)<br>
prs-b7.telia.net (80.91.255.56)<br>
<br>
<br>
--- a1230.b.akamai.net ping statistics ---<br>
1 packets transmitted, 1 received, 0% packet loss, time 0ms<br>
rtt min/avg/max/mdev = 151.504/151.504/151.504/0.000 ms<br>
[vladimir@pavilion ~]$ <br>
<br>
<b>addconn --verbose output:</b><br>
[philippe@victor ~]$ sudo /usr/local/sbin/ipsec addconn --verbose
Philippe_PSK<br>
opening file: /etc/ipsec.conf<br>
debugging mode enabled<br>
including file '/etc/ipsec.d/*.conf'(/etc/ipsec.d/*.conf) from
line /etc/ipsec.conf:26<br>
Loading conn Philippe_RSA_Fixed_IP<br>
while loading conn 'Philippe_RSA_Fixed_IP' also including
'FIXED_RIGHT_IP'<br>
starter: case KH_DEFAULTROUTE: empty<br>
Loading conn Vladimir_RSA_Fixed_IP<br>
while loading conn 'Vladimir_RSA_Fixed_IP' also including
'FIXED_RIGHT_IP'<br>
starter: case KH_DEFAULTROUTE: empty<br>
Loading conn Philippe_PSK<br>
while loading conn 'Philippe_PSK' also including
'FIXED_RIGHT_IP'<br>
starter: case KH_DEFAULTROUTE: empty<br>
Loading conn DHCP_RIGHT_IP<br>
starter: case KH_DEFAULTROUTE: empty<br>
Loading conn FIXED_RIGHT_IP<br>
starter: case KH_DEFAULTROUTE: empty<br>
loading named conns: Philippe_PSK<br>
parse_src = 0, parse_gateway = 1, has_dst = 0<br>
dst via 192.168.1.1 dev eth0 src <br>
set nexthop: 192.168.1.1<br>
dst 169.254.0.0 via dev eth0 src <br>
dst 192.168.1.0 via dev eth0 src 192.168.1.2<br>
<b>dst 192.168.2.101 via 192.168.1.1 dev eth0 src </b><br>
dst 127.0.0.0 via dev lo src 127.0.0.1<br>
dst 127.0.0.0 via dev lo src 127.0.0.1<br>
dst 127.0.0.1 via dev lo src 127.0.0.1<br>
dst 127.255.255.255 via dev lo src 127.0.0.1<br>
dst 192.168.1.0 via dev eth0 src 192.168.1.2<br>
dst 192.168.1.2 via dev eth0 src 192.168.1.2<br>
dst 192.168.1.255 via dev eth0 src 192.168.1.2<br>
<br>
parse_src = 1, parse_gateway = 0, has_dst = 1<br>
dst 192.168.1.1 via dev eth0 src 192.168.1.2<br>
set addr: 192.168.1.2<br>
002 "Philippe_PSK"[1] 192.168.1.5: deleting connection
"Philippe_PSK" instance with peer 192.168.1.5 {isakmp=#1/ipsec=#2}<br>
002 "Philippe_PSK" #2: deleting state (STATE_QUICK_R2)<br>
002 "Philippe_PSK" #1: deleting state (STATE_MAIN_R3)<br>
002 "Philippe_PSK": deleting connection<br>
002 added connection description "Philippe_PSK"<br>
[philippe@victor ~]$ <br>
<br>
<b>MY REAL QUESTION:</b><br>
How can you state from addconn output reading, it will use dev
eth0 src 192.168.1.2 and NOT dev lo src 127.0.0.1 for the ping
???? Notice that the two ping's never show going through the
gateway (192.168.1.1). I am sure there is an obvious explanation
but I miss it.<br>
<br>
<b>BETWEEN YOU AND ME:</b><br>
All these tests are really worth a good paper on my Web site.<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 06/01/2013 17:18, Paul Wouters a écrit :<br>
</div>
<blockquote cite="mid:alpine.LFD.2.03.1301061114130.19433@nohats.ca"
type="cite">On Sun, 6 Jan 2013, Philippe Vouters wrote:
<br>
<br>
<blockquote type="cite">My guess is that the last ping works fine
without -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 src 192.168.1.2
<br>
</blockquote>
<br>
Yes. That is the whole point of the left/rightsourceip= option!
From the
<br>
man page:
<br>
<br>
leftsourceip
<br>
the IP address for this host to use when transmitting a
<br>
packet to the other side of this link. Relevant only
locally,
<br>
the other end need not agree. This option is used to
make
<br>
the gateway itself use its internal IP, which is part
of
<br>
the leftsubnet, to communicate to the rightsubnet or
right.
<br>
Otherwise, it will use its nearest IP address, which is
its
<br>
public IP address. This option is mostly used when
defining
<br>
subnet-subnet connections, so that the gateways can
talk to
<br>
each other and the subnet at the other end, without the
need
<br>
to build additional host-subnet, subnet-host and
host-host
<br>
tunnels. Both IPv4 and IPv6 addresses are supported.
<br>
<br>
<br>
<blockquote type="cite">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>
</blockquote>
<br>
the new code in addconn.c asks the kernel for the best IP to use
to
<br>
reach destination (right=)
<br>
<br>
<blockquote type="cite">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
<br>
network layer (especially xfrm) has enough information to
correctly route the packets.
<br>
</blockquote>
<br>
That might be due to the changes in addconn when it fills in the
<br>
"unspecified" information. I think somehow it might be getting the
<br>
127.0.0.1 dev lo route and uses that as "source ip".
<br>
<br>
Paul
<br>
<br>
</blockquote>
<br>
</body>
</html>