[Openswan Users] Packets not being encrypted/tunnelled
Brian J. Murrell
brian at interlinx.bc.ca
Wed Feb 9 07:19:47 EST 2011
I have the following configuration:
# ipsec whack --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface wlan0/wlan0 10.75.22.228
000 interface wlan0/wlan0 10.75.22.228
000 interface virbr0/virbr0 192.168.122.1
000 interface virbr0/virbr0 192.168.122.1
000 interface virbr1/virbr1 10.0.0.1
000 interface virbr1/virbr1 10.0.0.1
000 interface virbr2/virbr2 10.0.0.9
000 interface virbr2/virbr2 10.0.0.9
000 %myid = (none)
000 debug none
000
000 virtual_private (%priv):
000 - allowed 3 subnets: 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12
000 - disallowed 0 subnets:
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=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, 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 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
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 "nmconnection-brian": 10.75.22.228:17/1701...192.1.1.234:17/1701; erouted; eroute owner: #6
000 "nmconnection-brian": myip=unset; hisip=unset;
000 "nmconnection-brian": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "nmconnection-brian": policy: PSK+ENCRYPT+UP; prio: 32,32; interface: wlan0;
000 "nmconnection-brian": newest ISAKMP SA: #5; newest IPsec SA: #6;
000 "nmconnection-brian": IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
000
000 #6: "nmconnection-brian":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 26798s; newest IPSEC; eroute owner; isakmp#5; idle; import:admin initiate
000 #6: "nmconnection-brian" esp.b32cec04 at 192.1.1.234 esp.d79be970 at 10.75.22.228 ref=0 refhim=4294901761
000 #5: "nmconnection-brian":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1592s; newest ISAKMP; lastdpd=13s(seq in:0 out:0); idle; import:admin initiate
000
where 10.75.22.228 actually reaches 192.1.1.234 through a NAT router,
10.75.22.196. This NAT router is a great place for me to watch traffic
and observe that traffic from 10.75.22.228 to 192.1.1.234 is not in fact
encrypted per the above policy. Observe (taken on the NAT router):
17:23:06.212802 IP 173.238.244.10 > 192.1.1.234: ICMP echo request, id 1349, seq 1, length 64
17:23:06.303003 IP 192.1.1.234 > 173.238.244.10: ICMP echo reply, id 1349, seq 1, length 64
17:23:07.214088 IP 173.238.244.10 > 192.1.1.234: ICMP echo request, id 1349, seq 2, length 64
17:23:07.306017 IP 192.1.1.234 > 173.238.244.10: ICMP echo reply, id 1349, seq 2, length 64
17:23:08.214993 IP 173.238.244.10 > 192.1.1.234: ICMP echo request, id 1349, seq 3, length 64
17:23:08.308679 IP 192.1.1.234 > 173.238.244.10: ICMP echo reply, id 1349, seq 3, length 64
Here's the current routing table:
10.10.0.1 dev ppp0 proto kernel scope link src 10.10.1.2
10.0.0.0/29 dev virbr1 proto kernel scope link src 10.0.0.1
10.0.0.8/29 dev virbr2 proto kernel scope link src 10.0.0.9
10.75.22.0/24 dev wlan0 proto kernel scope link src 10.75.22.228 metric 2
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
10.10.0.0/16 dev ppp0 proto static scope link
169.254.0.0/16 dev wlan0 scope link metric 1000
default via 10.75.22.254 dev wlan0 proto static
I am using openswan 2.6.28[+dfsg-5+ppa1~maverick1] and here's it's ipsec
verify output:
# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.6.28/K2.6.35-25-generic (netkey)
Checking for IPsec support in kernel [OK]
NETKEY detected, testing for disabled ICMP send_redirects [OK]
NETKEY detected, testing for disabled ICMP accept_redirects [OK]
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 [OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
The question is then, why is the traffic to 192.1.1.234 not going
through the tunnel and being encrypted?
Thanx much,
b.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20110209/6f012de1/attachment.bin
More information about the Users
mailing list