[strongSwan] VoIP Data Leaks around VPN

Thu Sep 11 09:10:17 CEST 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Daniel,

Please keep things on the mailing list.

For making the iptables rules and forwarding permanent,
Please look at the documentation of the distribution you're using.
I'm 95 % certain that you will end up with a file in /etc/sysctl.d/ 
and an iptables-save file.
As Android is just the Linux kernel with Java on top of it,
you can install a terminal emulator and look at the routing table
with command line tools like "ip" or "route", if they're installed.
If you have access to the root account, you can install busybox 
and get the necessary tools with it.
Can you check if the DHCP server pushes any routes to your LAN to the phones?
Also, you should check the strongSwan app logs for any problems.

Regards,
Noel Kuntze

GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 10.09.2014 um 23:43 schrieb Levine, Daniel J.:
> Now this is what I call support! :-)
> 
> I turned the boxes off for the day, so I'll answer for what I believe is the case.
> 
> The Asterisk server simply has a default route pointing to the VPN Server.  The VPN Server has a default route pointing to the wireless router.  So you can see how traffic could find its way out to the 10.2.0.0/24 network.
> 
> So, you may have found the issue here with SPD NAT rewrite.  Since I have no experience with that, we probably have nothing for it.  I assume that's a rule that would go in the VPN Server's iptables nat table?  We currently use the nat.sh script found here (http://www.foteviken.de/?p=2175) to configure the server's iptables to move the traffic around.  Although I do know how to make the ip_forward setting part of the script permanent, there's probably a better way to do the rest as well.  I'll fix that once I figure out what we need to get it all working. ;-)
> 
> How does one check the routing table on the Androids?  I know from the phones I can see the 10.1.0.0/24 network and (now after your help) both 10.3.0.0/24 (VPN IPs) for the phones as well as the whole 10.2.0.0/24 network when the VPN is established to both phones.  Does that demonstrate enough about the state of the routing at the phones?  I can try something else if that is not good enough.
> T
> Regarding DHCP, the only thing doing DHCP (unless StrongSwan secretly does it when it establishes a new VPN) is the wireless router.
> 
> I'll see if I can turn more debug on in Asterisk to see if it'll provide insight into why it's chosing the alternative path.  I'll have to look up asymmetric routing.
> 
> Thanks for your help, I wish I knew how to do some of the things you ask for here without you completely spelling it out, but I'm a little new to this. ;-)
> 
> Dan
> 
> Daniel J. Levine
> A3C4 Section Supervisor
> Air and Missile Defense Department
> Johns Hopkins University Applied Physics Laboratory
> Phone: (443) 778-3952  (240) 228-3952
> ________________________________________
> From: users-bounces at lists.strongswan.org <users-bounces at lists.strongswan.org> on behalf of Noel Kuntze <noel at familie-kuntze.de>
> Sent: Wednesday, September 10, 2014 5:05 PM
> To: users at lists.strongswan.org
> Subject: Re: [strongSwan] VoIP Data Leaks around VPN
> 
> Hello Daniel,
> 
> Does the asterisk server have a route to the VPN network over the VPN server?
> What is SPD NAT rewrite?!
> Can you look at what sockets are used by the SIP software? Also check the routing table on the Android devices.
> I think it's a problem with the routing table, maybe caused by a route pushed to the phone via dhcp.
> Also, you might want to increase verbosity for the asterisk server and look how and why it does what it does.
> It sounds like a problem with asymmetric routing.
> 
> Regards,
> Noel Kuntze
> 
> GPG Key id: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
> 
> Am 10.09.2014 um 22:52 schrieb Levine, Daniel J.:
>> I have a VPN road warrior configuration using StrongSwan client apps on 2 Android phones (the road warriors). The VPN tunnels establish fine using IKEv2.  The phones can now see each other on the VPN subnet (10.3.0.0/24) as well as the private network (10.1.0.0/24) behind the firewall. For completeness, the public network the VPN goes over is the 10.2.0.0/24 network. So the phones, a wireless router, and the outer half of the VPN server live over there.  I think that covers the topology.
> 
>> So, once this network is established, I'm using a SIP phone app on the Androids to register with an Asterisk server on the private network. That actually works nicely as well. I can even call an extension on the Asterisk server that plays a canned message just fine.  Looking at the traffic, I see that everything is confined to the 10.3.0.0/24 and 10.1.0.0/24 network. Which is what I'd expect.  Both phones work fine this way.
> 
>> If I place a call to the other phone through the Asterisk server the call works great. Both phones send and receive the audio of their microphones.  However, when I use tcpdump to examine the traffic on the Asterisk server (which is different from the VPN server on the 10.1.0.0/24 network) on the 10.1.0.0/24 network, I see that the traffic goes over the 10.2.0.0/24 network!
> 
>> I have found that turning on SDP NAT rewrite causes causes the data confine itself to the 10.3.0.0/24 network, but I only get one way audio transmission in a direction related to who calls whom.
> 
>> Any thoughts on what kind of issue I might have here?  As I describe this, I'm thinking I should probably talk to the Asterisk people to figure out why it doesn't like talking over the VPN and then discovers the 10.2.0.0/24 path.
> 
>> Thoughts?  Anyone solve a problem like this?
> 
>> Dan
> 
> 
> 
>> Sent with Good (www.good.com)
> 
> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
> 
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUEUrYAAoJEDg5KY9j7GZYzT4P/0KFPXb5Gfyfmw7it6JwmfIL
DVcUbAjjmRY6LAFXdDVzT2T2vfoVU7A66h2pMdqLGe6LuSwRFYIG9X+HLyqmE6CG
SIZtMeh7sCcEXXzax0yDT0LsP5vaLGPP7ocjzgu0QI8YDY8zCKlvrjlob/kys2Cj
bgn1ZjAEHTacnYiKK9Vd9UCWivvxu+JTbP3JcAPcBVnDXvmP7ogjEk2BHYJfbawE
vIYLV5shoeYMWmAKKbA/wxB8L9vbSj+hU/NNTLt5KfBga3KFQNFy7M6rYeQVp3ll
944YCiHFDkgSDsvh7mimVLULiEc5HuJvFFivw55Yjt6/O6eA1VQM8FkTpo01NCdO
bmdcc1R1bIyRkPDQFvB/v5O3iAAON9hbvbOLEQl31+wRfolXfomNR0nJhs6Oh6iC
mB8tsYOZNJEtj2Nr2dq+JAtapyIMeg5NDNlsUfp2D8OtO+znPo2wphn4xRGKJLHH
leNtI3Kg60UUZ9TTHv5X5giWXw8AWjwoo8iDlv1bV+E4aVvQzD4saXg/rXs1wLsK
/drJLD9Hdl+hx28V8VrJgUGzU1OJBQL+rh84sys7sf8uIRBGnG3g4mjloCU18bAV
BfdPodeEP0vkSlY2DYwrm2m4Ymo/d7fU7oKY/40g2WvSgUYuOnYRD1ctla6H+pVx
7gbnvcc5w8zSEWuZz9qS
=WNIi
-----END PGP SIGNATURE-----