<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>Fixed issue using Asterisk NAT configuration!<br>
<br>
In sip.conf. Added nat=force_rport,comedia<br>
<br>
Now we're good to go without any back channeling. Thanks guys!<br>
<br>
<br>
<br>
Sent with Good (www.good.com)<br>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Noel Kuntze <noel@familie-kuntze.de><br>
<b>Sent:</b> Thursday, September 11, 2014 3:10:17 AM<br>
<b>To:</b> Levine, Daniel J.; Users@lists.strongswan.org<br>
<b>Subject:</b> Re: [strongSwan] VoIP Data Leaks around VPN</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hello Daniel,<br>
<br>
Please keep things on the mailing list.<br>
<br>
For making the iptables rules and forwarding permanent,<br>
Please look at the documentation of the distribution you're using.<br>
I'm 95 % certain that you will end up with a file in /etc/sysctl.d/ <br>
and an iptables-save file.<br>
As Android is just the Linux kernel with Java on top of it,<br>
you can install a terminal emulator and look at the routing table<br>
with command line tools like "ip" or "route", if they're installed.<br>
If you have access to the root account, you can install busybox <br>
and get the necessary tools with it.<br>
Can you check if the DHCP server pushes any routes to your LAN to the phones?<br>
Also, you should check the strongSwan app logs for any problems.<br>
<br>
Regards,<br>
Noel Kuntze<br>
<br>
GPG Key id: 0x63EC6658<br>
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
<br>
Am 10.09.2014 um 23:43 schrieb Levine, Daniel J.:<br>
> Now this is what I call support! :-)<br>
> <br>
> I turned the boxes off for the day, so I'll answer for what I believe is the case.<br>
> <br>
> 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.<br>
> <br>
> 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
(<a href="http://www.foteviken.de/?p=2175">http://www.foteviken.de/?p=2175</a>) 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. ;-)<br>
> <br>
> 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.<br>
> T<br>
> Regarding DHCP, the only thing doing DHCP (unless StrongSwan secretly does it when it establishes a new VPN) is the wireless router.<br>
> <br>
> 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.<br>
> <br>
> 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. ;-)<br>
> <br>
> Dan<br>
> <br>
> Daniel J. Levine<br>
> A3C4 Section Supervisor<br>
> Air and Missile Defense Department<br>
> Johns Hopkins University Applied Physics Laboratory<br>
> Phone: (443) 778-3952 (240) 228-3952<br>
> ________________________________________<br>
> From: users-bounces@lists.strongswan.org <users-bounces@lists.strongswan.org> on behalf of Noel Kuntze <noel@familie-kuntze.de><br>
> Sent: Wednesday, September 10, 2014 5:05 PM<br>
> To: users@lists.strongswan.org<br>
> Subject: Re: [strongSwan] VoIP Data Leaks around VPN<br>
> <br>
> Hello Daniel,<br>
> <br>
> Does the asterisk server have a route to the VPN network over the VPN server?<br>
> What is SPD NAT rewrite?!<br>
> Can you look at what sockets are used by the SIP software? Also check the routing table on the Android devices.<br>
> I think it's a problem with the routing table, maybe caused by a route pushed to the phone via dhcp.<br>
> Also, you might want to increase verbosity for the asterisk server and look how and why it does what it does.<br>
> It sounds like a problem with asymmetric routing.<br>
> <br>
> Regards,<br>
> Noel Kuntze<br>
> <br>
> GPG Key id: 0x63EC6658<br>
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
> <br>
> Am 10.09.2014 um 22:52 schrieb Levine, Daniel J.:<br>
>> 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.<br>
> <br>
>> 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.<br>
> <br>
>> 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!<br>
> <br>
>> 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.<br>
> <br>
>> 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.<br>
> <br>
>> Thoughts? Anyone solve a problem like this?<br>
> <br>
>> Dan<br>
> <br>
> <br>
> <br>
>> Sent with Good (<a href="http://www.good.com">www.good.com</a>)<br>
> <br>
> <br>
>> _______________________________________________<br>
>> Users mailing list<br>
>> Users@lists.strongswan.org<br>
>> <a href="https://lists.strongswan.org/mailman/listinfo/users">https://lists.strongswan.org/mailman/listinfo/users</a><br>
> <br>
> _______________________________________________<br>
> Users mailing list<br>
> Users@lists.strongswan.org<br>
> <a href="https://lists.strongswan.org/mailman/listinfo/users">https://lists.strongswan.org/mailman/listinfo/users</a><br>
> <br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQIcBAEBAgAGBQJUEUrYAAoJEDg5KY9j7GZYzT4P/0KFPXb5Gfyfmw7it6JwmfIL<br>
DVcUbAjjmRY6LAFXdDVzT2T2vfoVU7A66h2pMdqLGe6LuSwRFYIG9X+HLyqmE6CG<br>
SIZtMeh7sCcEXXzax0yDT0LsP5vaLGPP7ocjzgu0QI8YDY8zCKlvrjlob/kys2Cj<br>
bgn1ZjAEHTacnYiKK9Vd9UCWivvxu+JTbP3JcAPcBVnDXvmP7ogjEk2BHYJfbawE<br>
vIYLV5shoeYMWmAKKbA/wxB8L9vbSj+hU/NNTLt5KfBga3KFQNFy7M6rYeQVp3ll<br>
944YCiHFDkgSDsvh7mimVLULiEc5HuJvFFivw55Yjt6/O6eA1VQM8FkTpo01NCdO<br>
bmdcc1R1bIyRkPDQFvB/v5O3iAAON9hbvbOLEQl31+wRfolXfomNR0nJhs6Oh6iC<br>
mB8tsYOZNJEtj2Nr2dq+JAtapyIMeg5NDNlsUfp2D8OtO+znPo2wphn4xRGKJLHH<br>
leNtI3Kg60UUZ9TTHv5X5giWXw8AWjwoo8iDlv1bV+E4aVvQzD4saXg/rXs1wLsK<br>
/drJLD9Hdl+hx28V8VrJgUGzU1OJBQL+rh84sys7sf8uIRBGnG3g4mjloCU18bAV<br>
BfdPodeEP0vkSlY2DYwrm2m4Ymo/d7fU7oKY/40g2WvSgUYuOnYRD1ctla6H+pVx<br>
7gbnvcc5w8zSEWuZz9qS<br>
=WNIi<br>
-----END PGP SIGNATURE-----<br>
</div>
</span></font>
</body>
</html>