Re: [Openvpn-users] Re: openvpn and voip

["Eric \"Skippy\" Hope" <ehope@xxxxxxxxxx>]

Leonard Isham wrote:

> On 8/3/05, Eric Skippy Hope <ehope@xxxxxxxxxx> wrote:
>  
>
> > Charles Duffy wrote:
> >
> >    
> >
> > > On Tue, 02 Aug 2005 15:18:00 -0400, Eric "Skippy" Hope wrote:
> > >
> > >
> > >
> > >      
> > >
> > > > The problem comes in when trying to make a call.  The session initiation
> > > > portion of the call goes over the vpn just like it should (this is the sip
> > > > portion, for those familier with voip).  Once the other end picks up the
> > > > phone, the software phone tries to send the actual voice connection over
> > > > the public IPs, ignoring the vpn.  This seems to have something to do with
> > > > the Win TUN/TAP interface.
> > > >
> > > >
> > > >        
> [snip]
>  
>
> > The clients are assigned a 10.10.10.x address by openvpn.
> > The asterisk server has a 10.11.12.13 address and a route pointing
> > 10.10.10.x to the vpn gateway.
> > The client end can ping the server; the server end can ping the client.
> > The sip registration works fine, as do the sip INVITEs all going over
> > the vpn.   Once the call recipient picks up the phone, the softphone
> > sends a sip OK packet, which has as a payload a SDP packet with the
> > details for the actual voice traffic, and this is where its sending the
> > pubic IP rather than the private IP.  All of the sip addresses are in
> > the proper format, ie sip:ext@privateip.
> >
> > We are using asterisk and I've tried the nat=no.  I've tried setting the
> > host= in the sip.conf to the private ip of the client.  The softphone
> > still wants to get its voice data on the public ip.
> >
> > That pounding noise is my head and my desk.
> >
> >    
>
> Have you tried changing the binding order of the NICs?  I'm guessing
> that it is choosing the Real interface as it is the first one bound. 
> If you make the TUN interface first that may resolve the softphone
> issue.  however it may induce other problems as I've never tried this
> with a firtualinterface and the binding order is for for the
> computer...
>
> Another option may be to NAT the outbound destination IP to the VPN IP
> address.  Again this may not work or cause other problems.
>
> If you try either of these please let the list know the results.
>
>  
The binding order was one of our guesses as well, but changing it didn't 
seem to matter.  (I'm not positive that I did it correctly, I'm not a 
windows admin by any stretch.)

I thought about trying a NAT setup, but the additional complexity and 
the possible problems didn't seem worth it.

We did get it to work however.  We got rid of the 10.11.12.13 private IP 
on the asterisk server and used its public IP instead.  A "push route 
se.rv.er.ip 255.255.255.255" got the trafic from the client to the 
asterisk server.  The asterisk server still tried to send packets back 
to the client via the clients public ip, but setting the client 
softphone to use a STUN server fixed that.  For anyone not familier with 
them, a STUN server is meant to let a client behind NAT determine what 
its public IP is.  In this case the softphone seems to trust the IP 
returned by the stun server more than the bind order or whatever 
criteria it was using, even though it isn't behind NAT.

I'm not sure why this setup works when the other setups didn't, but it 
is working.  Thanks for the help everyone.

Eric



____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users