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