Bruce,
I'm a little confused about exactly where you are in all of this, but
two things come to mind.
I don't think I would use the tunnel address as the target of the phones
- I'd suggest trying the address of the Ethernet interface of your
Asterisk system.
Try doing a netstat -rn on both systems again - my comment about needing
to see routes on both systems still applies. Try pinging the address of
the Asterisk server from something with a 192.168.100.0/24 address like
the phones (from one of the phones if they support it). If you can't
ping, it won't work (however, sometimes pings are filtered, which makes
debugging tough).
Remember that routing packets under IP is without any real memory of how
a packet got there - each device doing routing along the way just looks
at the destination IP, looks for a route in the routing table and just
flings the packet along that way. If you get routing wrong, a packet
can reach a destination but the reply won't get back if the reverse
route is not properly defined at every hop. So, you'll need either an
explicit route in the routing table at each hop, or else the packet will
get forwarded to the default gateway.
Regards,
Doug.
On 22/09/2010 12:40 AM, Bruce N wrote:
All right, so the whole reason for OpenVPN was to get rid of one-way audio for
once and for good. It doesn't seem to be the case now. I think I know what is
wrong but please correct me here if I am wrong:
Server A - OpenVPN Server - 172.16.0.1 is the OpenVPN assigned IP
Server B - OpenVPN Client - 172.16.0.6 is the OpenVPN assigned IP
Server B- Supplies a network with 192.168.100.0/255.255.255.0 pool of DHCP
(Aastra phones)
OpenVPN tunnel is at 172.16.0.0/24, so I have all the Aastra phones pointing to
172.16.0.1:5060 for register. They register fine of course and can make calls
and receive calls. But, it's one-way audio and also it drops call. I think what
with this setup something like Siproxd is still needed. I hate to hear that is
the case though. Since several Aastra phones connecting to the server, probably
SIP packets lose track of where to send the packets. Maybe only one device
works.
But this is not nice. There is got to be a work around for this other then me
setting up the DHCP server on the Server A. It's currently on Server B.
Please advise if you see a solution to this.
P.S. I am still to do a wireshark to see what is really wrong....
Thanks,
Bruce
From: [email protected]
To: [email protected]; [email protected]
Date: Tue, 21 Sep 2010 23:08:41 -0400
Subject: RE: [on-asterisk] OpenVPN Gurus! How to forward all traffic from eth1
to tun0?
Just wanted to convey Thanks again Doug. Your instructions on ccd just did the
trick.
-Bruce
From: [email protected]
To: [email protected]; [email protected]
Date: Tue, 21 Sep 2010 19:06:28 -0400
Subject: RE: [on-asterisk] OpenVPN Gurus! How to forward all traffic from eth1
to tun0?
Thanks Doubh. I think you are right on point. I thought all the routing should
be done on the Server B side but I might be wrong now that you put it this way.
However, I can't figure this out and am banging my head against the wall. I
also tried brctl but because tun0 is layer 3 it won't bridge with eth1 and that
is really not something I'd like to do anyways because of the DHCP in place.
So here is what I have for netstat -rn after all connections are made:
Server A - Ovpn_Server:
[r...@servera:~]$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.16.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.16.0.0 172.16.0.2 255.255.255.0 UG 0 0 0 tun0
192.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 venet0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 venet0
0.0.0.0 192.0.2.1 0.0.0.0 UG 0 0 0 venet0
Server B - Ovpn_Client:
[r...@serverb:~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.16.0.1 172.16.0.13 255.255.255.255 UGH 0 0 0 tun0
172.16.0.13 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.16.0.0 172.16.0.13 255.255.255.0 UG 0 0 0 tun0
10.10.9.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1
0.0.0.0 10.10.9.1 0.0.0.0 UG 0 0 0 eth0
I have everything included all the settings posted into pastebin, if you can
please have a look and let me know what I am missing:
http://pastebin.com/GHQry456
Thanks a lot,
Bruce
Date: Tue, 21 Sep 2010 17:44:44 -0400
From: [email protected]
To: [email protected]
Subject: Re: [on-asterisk] OpenVPN Gurus! How to forward all traffic from eth1
to tun0?
Bruce,
Do you have ip_forward enabled on both machines? Look in
/etc/sysctl.conf and see if net.ipv4.ip_forward is set to one (only read
at boot time, so you'll need to set it with the sysctl command if you
don't want to reboot).
On both servers do a netstat -rn
On server A are there routes for the networks associated with B, and on
B are there routes for the networks associated with A? There should be,
for this to work.
If you're following the usual cookbook server/client with X.509 keys,
look at the part in the server.conf file talking about creating a ccd
directory, and connection specific file with an "iroute" statement in it.
If Server B is not the default gateway for the subnet, you'll need to
add a static route to the default gateway that specifies the internal
interface of Server B as the gateway to the addresses associated with
Server A (depending on the circumstances, you might need to do that on
the Server A end too).
Hope that helps.
Regards,
Doug.
On 21/09/2010 4:36 PM, Bruce N wrote:
Thanks for that. Yes, I am pushing and it makes it available only to Server B
and not to it's DHCPd clients which exist on Eth1.
I think the push only helps Server A and Server B to ping each other and not
the other networks they may have contact with.
I have a pastebin of the whole route here:http://pastebin.com/98JhraeJ
Basically anyone on the dhcpd 10.0.0.0/24 can't ping the 172.16.0.1 which is
the OpenVPN server. But, both OpenVPN server and client server can ping each
other.
-Bruce
Date: Tue, 21 Sep 2010 15:25:24 -0400
From: [email protected]
To: [email protected]
Subject: Re: [on-asterisk] OpenVPN Gurus! How to forward all traffic from eth1
to tun0?
Bruce,
On your client (Server B) are you pushing the route in your config ?
route 172.15.0.0 255.255.255.0
push "route 172.15.0.0 255.255.255.0"
Mike
On 09/21/2010 1:57 PM, Bruce N wrote:
Hi Everyone,
I know this is way off-topic of the list but it does involve getting Asterisk
service up and running :-)
In nutshell:
I need to SIP/UDP traffic of eth1 (dhcpd server) traffic to tun0 (openvpn
tunnel) without sending the dhcpd requests to tun0.
In detail:
I have two servers:
Server A running Asterisk and OpenVPN Server.
Server B running DHCPd and has two NIC cards. Eth0 is the WAN to ISP. Eth1 is
the NIC that feeds the Switch with DHCPd IPs to endpoint SIP phones.
Server A and Server B are miles and miles away from each and are connected to
the internet either via Eht0 or Vnet.
OpenVPN on Server A is set to IP range 172.15.0.0/24 so Server A and B can ping
each other in that range with 172.15.0.1 assigned to Server A.
Server B is connected to Server A as an OpenVPN client. I can ping Server A
from Server B when doing: ping 172.15.0.1
However, any endpoints (SIP phones) that have obtained IP from Server B DHCPd
can not ping 172.15.0.1. Network 172.15.0.1 is simple unreachable to them. My
thought was that upon succesful establish of the openvpn connection the routes
will populate properly but it seems that any requests to 172.15.0.1 hit eth0
which is of course wrong. I tried adding routes and I got SIODDART
Here is what I need to accomplish:
Run a DHCPd service on Server B (which has two NIC cards) and feed IPs to SIP
phones and endpoint
Create a tunnel between
Note: I can't do: push "redirect-gateway def1" because it will make Server B
unreachable and Enpoint A points to Server A for DHCP packets which is wrong.
Thanks,
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
