[Openswan Users] klips - tunnel established but can ping other end
Curu Wong
prinbra at gmail.com
Mon Jan 31 06:06:11 EST 2011
Problem: I create a host to host vpn tunnel, when use the native netkey
stack, the tunnel works perfectly without any problem, but when I change the
stack from netkey to klips on one end, the tunnel can be successfully bulit,
but it can't send packet back to the other end.
Here is my setup:
hostA(192.168.2.128) ---->GW(192.168.2.129,no
NAT,10.1.1.1)--->10.1.1.10(hostB)
ipsec.conf of hostA
====================================================
version 2.0 # conforms to second version of ipsec.conf specification
config setup
protostack=netkey
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16
oe=off
nhelpers=0
conn tklips
left=192.168.2.128
leftrsasigkey=xxxxxxxxxxxxxxxxx
right=10.1.1.10
rightrsasigkey=xxxxxxxxxxxxxxxxxxx
auto=add
=====================================================
ipsec.conf of hostB
=====================================================
version 2.0 # conforms to second version of ipsec.conf specification
config setup
nat_traversal=yes
oe=off
protostack=auto
conn tklips
left=192.168.2.128
leftrsasigkey=xxxxxxxxxxxx
right=10.1.1.10
rightrsasigkey=xxxxxxxxxxxxxxx
auto=start
===================================================
on hostA, before bring the tunnel:
==================================================
traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 40 byte packets
1 192.168.2.129 (192.168.2.129) 0.928 ms 0.743 ms 0.666 ms
2 10.1.1.10 (10.1.1.10) 4.381 ms 4.769 ms 4.663 ms
==================================================
on hostA, after bring up the tunnel, use the above config file
==================================================
#traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 40 byte packets
1 10.1.1.10 (10.1.1.10) 18.820 ms 19.484 ms 19.291 ms
==================================================
But I want to use klips, so ,on hostB, I installed the klips module, and set
protostack=klips in ipsec.conf.
=========================================================
#ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan 2.6.31 (klips)
Checking for IPsec support in kernel [OK]
KLIPS detected, checking for NAT Traversal support [OK]
SAref kernel support [N/A]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for NAT-T on udp 4500 [OK]
Two or more interfaces found, checking IP forwarding [FAILED]
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:05:14:07
inet addr:10.1.1.10 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe05:1407/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2754 errors:0 dropped:0 overruns:0 frame:0
TX packets:1675 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:270748 (270.7 KB) TX bytes:273601 (273.6 KB)
Interrupt:19 Base address:0x2000
ipsec0 Link encap:Ethernet HWaddr 00:0c:29:05:14:07
inet addr:10.1.1.10 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe05:1407/64 Scope:Link
UP RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:3 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
mast0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.1.1.10 Mask:255.255.255.255
UP RUNNING NOARP MTU:1452 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
#ipsec auto --status
000 using kernel interface: mast
000 interface mast0/eth0 10.1.1.10
000 interface mast0/eth0 10.1.1.10
000 %myid = (none)
000 debug none
000
000 virtual_private (%priv):
000 - allowed 0 subnets:
000 - disallowed 0 subnets:
000 WARNING: Either virtual_private= is not specified, or there is a syntax
000 error in that line. 'left/rightsubnet=vhost:%priv' will not
work!
000 WARNING: Disallowed subnets in virtual_private= is empty. If you have
000 private address space in internal use, it should be excluded!
000
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64, keysizemin=192,
keysizemax=192
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128, keysizemin=128,
keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
keysizemin=160, keysizemax=160
000
000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8,
keydeflen=128
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
keydeflen=128
000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC, blocksize=16,
keydeflen=128
000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC, blocksize=16,
keydeflen=128
000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH,
blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0}
trans={0,0,0} attrs={0,0,0}
000
000 "tklips":
10.1.1.10<10.1.1.10>[+S=C]...192.168.2.128<192.168.2.128>[+S=C]; erouted;
eroute owner: #2
000 "tklips": myip=unset; hisip=unset;
000 "tklips": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0
000 "tklips": policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW; prio:
32,32; interface: eth0;
000 "tklips": newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "tklips": IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
000
000 #2: "tklips":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
EVENT_SA_REPLACE in 27778s; newest IPSEC; eroute owner; isakmp#1; idle;
import:admin initiate
000 #2: "tklips" esp.8d3f82a5 at 192.168.2.128 esp.1e9dd485 at 10.1.1.10
tun.1001 at 192.168.2.128 tun.1002 at 10.1.1.10 ref=3 refhim=1
000 #1: "tklips":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE
in 2548s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin
initiate
000
=============================================================
When I ping hostB from hostA, not respone, but I can see those packet from
ipsec0.
===============================================
#tcpdump -i ipsec0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:55:44.716399 IP 192.168.2.128 > 10.1.1.10: ICMP echo request, id 60237,
seq 7, length 64
18:55:45.925541 IP 192.168.2.128 > 10.1.1.10: ICMP echo request, id 60237,
seq 8, length 64
18:55:47.130018 IP 192.168.2.128 > 10.1.1.10: ICMP echo request, id 60237,
seq 9, length 64
18:55:48.314226 IP 192.168.2.128 > 10.1.1.10: ICMP echo request, id 60237,
seq 10, length 64
18:55:49.533390 IP 192.168.2.128 > 10.1.1.10: ICMP echo request, id 60237,
seq 11, length 64
=====================================================================
and ipsec eroute show nothing.
I am definitely sure that tunnel traffic can go from hostA to hostB, but why
cann't it go from hostB to hostA?
environment of hostB:
ubuntu 10.10
dpkg -l | grep openswan
ii openswan 1:2.6.31-1xelerance1
Internet Key Exchange daemon
ii openswan-modules-dkms 1:2.6.31-1xelerance1
Internet Key Exchange daemon - DKMS source
Can any one kindly help me out, this has trapped me for several days.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20110131/c82018a9/attachment.html
More information about the Users
mailing list