Even though it seems you've figured this out already, the problem is that the process is waiting on the Kernel for something. (This is usually a driver-level problem, but not always.) The only way to kill such a process is to unload the kernel, which, of course, you can't do without rebooting.
Might be worth trying some kernel debugging (does this tool work on 2008 R2?) in the hopes of narrowing down the specific cause or conflict, but your options for handling the problem are either living with it, or rebooting the server to eliminate it.
Is there a reason you haven't considered living with it? If it's just a zombie process, and it's not impacting anything, I'd think you could put off a reboot until a maintenance window or more opportune time. Typically my approach, when the zombie or hung process isn't interfering with anything - take care of it during the next patch cycle or scheduled maintenance window.
The SA you see in the output of strongswan statusall is an IKE_SA (or rather ISAKMP SA as this is IKEv1) not an IPsec SA. Hence, there must be some kind of problem after Main Mode is finished.
ModeConfig (the assignment of the virtual IP and other attributes) seems to work fine, this is also reflected by the IPsec policy installed on the Android device. But what is missing is the Quick Mode request (that's when the IPsec SA would be negotiated):
14[IKE] assigning virtual IP 10.0.0.2 to peer 'android'
14[NET] sending packet: from 96.244.142.28[4500] to 208.54.35.241[35595]
This is the ModeConfig response that is sent to the Android device, but charon does not receive any message afterwards.
I was now able to reproduce this. This behavior is on purpose. When ModeConfig is finished and the ISAKMP SA is established the following is logged to logcat:
I/racoon (11096): ISAKMP-SA established [...]
D/VpnJni ( 310): Route added on tun0: 0.0.0.0/0
I/LegacyVpnRunner( 310): Connected!
Also, the virtual IP (in your case 10.0.0.2) received during ModeConfig is added to tun0 and IPsec policies for 10.0.0.2 <=> 0.0.0.0/0 are installed in the kernel (this can also be seen in the ip xfrm policies output you posted).
Now, the IPsec SA is not established until traffic matches the outbound policy. Because 0.0.0.0/0 is used as remote traffic selector (also for the route via tun0) any packet will match the policy and, thus, trigger the Quick Mode negotiation.
In my case as soon as I opened the browser the following was logged:
I/racoon (15504): initiate new phase 2 negotiation: [...]
I/racoon (15504): NAT detected -> UDP encapsulation (ENC_MODE 1->3).
W/racoon (15504): attribute has been modified.
I/racoon (15504): Adjusting my encmode UDP-Tunnel->Tunnel
I/racoon (15504): Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
W/racoon (15504): low key length proposed, mine:256 peer:128.
W/racoon (15504): authtype mismatched: my:hmac-md5 peer:hmac-sha
I/racoon (15504): IPsec-SA established: ESP/Tunnel [...]
Which also resulted in the expected output on the strongSwan gateway:
android2{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: cd7ceff0_i 0e7ab2fc_o
android2{1}: AES_CBC_128/HMAC_SHA1_96, 60 bytes_i, 0 bytes_o, rekeying in 41 minutes
android2{1}: 0.0.0.0/0 === 10.0.0.2/32
Best Answer
Weird. To pinpoint the problem, you could try
That should also list all ports in use. If it disagrees, the problem might be with tcpview. Otherwise, you'd have to look elsewhere.