[Swan] leftsourceip functionality with libreswan-3.0
Philippe Vouters
philippe.vouters at laposte.net
Sun Jan 6 20:52:41 EET 2013
Paul,
You seem to be fully right with the new addconn code. *No leftsourceip=
*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
http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven.html
*On the Libreswan VPN server side**:*
[philippe at victor ~]$ sudo systemctl stop ipsec.service
[philippe at victor ~]$ sudo systemctl start ipsec.service
[philippe at victor ~]$ sudo ip xfrm state
[philippe at victor ~]$ # laptop powered on and Shrew started again
[philippe at victor ~]$ # NO ping -c 1 -I 192.168.2.101 www.ask.com
[philippe at victor ~]$ # issued from the laptop
[philippe at victor ~]$ sudo /usr/local/sbin/ipsec auto --status | grep
established
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
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
[philippe at victor ~]$ sudo ip xfrm
state src 192.168.1.5 dst
192.168.1.2
proto esp spi 0x8c62cee5 reqid 16405 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0xb750adf062264668848f14f25c63c066781215ee 96
enc cbc(aes) 0x4cb13f3703b581dfa421ed48b2130fbe7f5809b49d718fe8
src 192.168.1.2 dst 192.168.1.5
proto esp spi 0x04699cdd reqid 16405 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x9289cf562a6a507955790fc5a07e17bc4e0adf44 96
enc cbc(aes) 0x5ffc73f62597be56ae70aebcb3d47f9781a60642f9d7ea15
[philippe at victor ~]$ sudo ip route
default via 192.168.1.1 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
192.168.2.101 via 192.168.1.1 dev eth0
[philippe at victor ~]$ ping -R -c 1
192.168.2.101 PING 192.168.2.101
(192.168.2.101) 56(124) bytes of data.
64 bytes from 192.168.2.101: icmp_req=1 ttl=64 time=5.70 ms
RR: 192.168.1.2
192.168.2.101
192.168.2.101
192.168.1.2
--- 192.168.2.101 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.706/5.706/5.706/0.000 ms
On the *Fedora 17 laptop side* running Shrew, it now shows:
After Shrew has established the VPN
[vladimir at pavilion ~]$ sudo ip xfrm state
[vladimir at pavilion ~]$
After $ ping -c 1 192.168.2.101 from the VPN server:
[vladimir at pavilion ~]$ sudo ip xfrm state
src 192.168.1.5 dst 192.168.1.2
proto esp spi 0x8c62cee5 reqid 2 mode tunnel
replay-window 4
auth-trunc hmac(sha1) 0xb750adf062264668848f14f25c63c066781215ee 96
enc cbc(aes) 0x4cb13f3703b581dfa421ed48b2130fbe7f5809b49d718fe8
sel src 0.0.0.0/0 dst 0.0.0.0/0
src 192.168.1.2 dst 192.168.1.5
proto esp spi 0x04699cdd reqid 1 mode tunnel
replay-window 4
auth-trunc hmac(sha1) 0x9289cf562a6a507955790fc5a07e17bc4e0adf44 96
enc cbc(aes) 0x5ffc73f62597be56ae70aebcb3d47f9781a60642f9d7ea15
sel src 0.0.0.0/0 dst 0.0.0.0/0
[vladimir at pavilion ~]$ sudo ip route
default via *192.168.2.101 dev tap0 * proto static
default via 192.168.1.1 dev wlan0 proto static
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.5
[vladimir at pavilion ~]$
And ping -R -c 1 www.ask.com on the laptop shows:
[vladimir at pavilion ~]$ ping -R -c 1 www.ask.com
PING a1230.b.akamai.net (80.239.221.10) 56(124) bytes of data.
64 bytes from 80-239-221-10.customer.teliacarrier.com (80.239.221.10):
icmp_req=1 ttl=52 time=151 ms
RR: pavilion (192.168.2.101)
vouters.dyndns.org (192.168.1.2)
170.212.85.79.rev.sfr.net (79.85.212.170)
22.235.64.86.rev.sfr.net (86.64.235.22)
14.235.64.86.rev.sfr.net (86.64.235.14)
86.93.20.93.rev.sfr.net (93.20.93.86)
222.29.3.109.rev.sfr.net (109.3.29.222)
249.29.3.109.rev.sfr.net (109.3.29.249)
prs-b7.telia.net (80.91.255.56)
--- a1230.b.akamai.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 151.504/151.504/151.504/0.000 ms
[vladimir at pavilion ~]$
*addconn --verbose output:*
[philippe at victor ~]$ sudo /usr/local/sbin/ipsec addconn --verbose
Philippe_PSK
opening file: /etc/ipsec.conf
debugging mode enabled
including file '/etc/ipsec.d/*.conf'(/etc/ipsec.d/*.conf) from line
/etc/ipsec.conf:26
Loading conn Philippe_RSA_Fixed_IP
while loading conn 'Philippe_RSA_Fixed_IP' also including
'FIXED_RIGHT_IP'
starter: case KH_DEFAULTROUTE: empty
Loading conn Vladimir_RSA_Fixed_IP
while loading conn 'Vladimir_RSA_Fixed_IP' also including
'FIXED_RIGHT_IP'
starter: case KH_DEFAULTROUTE: empty
Loading conn Philippe_PSK
while loading conn 'Philippe_PSK' also including 'FIXED_RIGHT_IP'
starter: case KH_DEFAULTROUTE: empty
Loading conn DHCP_RIGHT_IP
starter: case KH_DEFAULTROUTE: empty
Loading conn FIXED_RIGHT_IP
starter: case KH_DEFAULTROUTE: empty
loading named conns: Philippe_PSK
parse_src = 0, parse_gateway = 1, has_dst = 0
dst via 192.168.1.1 dev eth0 src
set nexthop: 192.168.1.1
dst 169.254.0.0 via dev eth0 src
dst 192.168.1.0 via dev eth0 src 192.168.1.2
*dst 192.168.2.101 via 192.168.1.1 dev eth0 src *
dst 127.0.0.0 via dev lo src 127.0.0.1
dst 127.0.0.0 via dev lo src 127.0.0.1
dst 127.0.0.1 via dev lo src 127.0.0.1
dst 127.255.255.255 via dev lo src 127.0.0.1
dst 192.168.1.0 via dev eth0 src 192.168.1.2
dst 192.168.1.2 via dev eth0 src 192.168.1.2
dst 192.168.1.255 via dev eth0 src 192.168.1.2
parse_src = 1, parse_gateway = 0, has_dst = 1
dst 192.168.1.1 via dev eth0 src 192.168.1.2
set addr: 192.168.1.2
002 "Philippe_PSK"[1] 192.168.1.5: deleting connection "Philippe_PSK"
instance with peer 192.168.1.5 {isakmp=#1/ipsec=#2}
002 "Philippe_PSK" #2: deleting state (STATE_QUICK_R2)
002 "Philippe_PSK" #1: deleting state (STATE_MAIN_R3)
002 "Philippe_PSK": deleting connection
002 added connection description "Philippe_PSK"
[philippe at victor ~]$
*MY REAL QUESTION:*
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.
*BETWEEN YOU AND ME:*
All these tests are really worth a good paper on my Web site.
Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org
Le 06/01/2013 17:18, Paul Wouters a écrit :
> On Sun, 6 Jan 2013, Philippe Vouters wrote:
>
>> 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:
>> 192.168.2.101 via 192.168.1.1 dev eth0 src 192.168.1.2
>
> Yes. That is the whole point of the left/rightsourceip= option! From the
> man page:
>
> leftsourceip
> the IP address for this host to use when transmitting a
> packet to the other side of this link. Relevant only locally,
> the other end need not agree. This option is used to make
> the gateway itself use its internal IP, which is part of
> the leftsubnet, to communicate to the rightsubnet or right.
> Otherwise, it will use its nearest IP address, which is its
> public IP address. This option is mostly used when defining
> subnet-subnet connections, so that the gateways can talk to
> each other and the subnet at the other end, without the need
> to build additional host-subnet, subnet-host and host-host
> tunnels. Both IPv4 and IPv6 addresses are supported.
>
>
>> 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 ????
>
> the new code in addconn.c asks the kernel for the best IP to use to
> reach destination (right=)
>
>> 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.
>
> That might be due to the changes in addconn when it fills in the
> "unspecified" information. I think somehow it might be getting the
> 127.0.0.1 dev lo route and uses that as "source ip".
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20130106/cb58dc1d/attachment-0001.html>
More information about the Swan
mailing list