Actually, my mistake. Server A DOES know where the 192.168.100.0 is because 
netstat -rn shows:

 

192.168.50.0    172.16.0.2      255.255.255.0   UG        0 0          0 tun0

 

and it DOES ping that network just fine.

 

[r...@servera]$ ping 192.168.50.1
PING 192.168.50.1 (192.168.50.1) 56(84) bytes of data.
64 bytes from 192.168.50.1: icmp_seq=1 ttl=64 time=15.6 ms
64 bytes from 192.168.50.1: icmp_seq=2 ttl=64 time=14.8 ms
64 bytes from 192.168.50.1: icmp_seq=3 ttl=64 time=15.1 ms

 

The SIP packets just keep containing things like FROM [email protected]   which 
is the tunnel IPs in both direction (TO and FROM). That is what needs to get 
fixed. Is there somewhere ont he Aastra Phone that I can specify it to use the 
192.168.0.0/24 instead of the 172.16.0.1 or do the packet header get 
over-written by the tun0 and change to 172.16.0.1. If so, how can I avoid this?

 

Thanks again,

Bruce
 
> From: [email protected]
> To: [email protected]; [email protected]
> Date: Wed, 22 Sep 2010 13:17:57 -0400
> Subject: RE: [on-asterisk] OpenVPN Gurus! How to forward all traffic from 
> eth1 to tun0?
> 
> 
> Thanks for reply Douglas,
> 
> 
> 
> Server B knows to reach 172.16.0.1 because of the ccd direction that you 
> pointed out which added. So, the iroute actually established the connection 
> between subnet 192.168.100.0/24 -> 172.16.0.1.
> 
> 
> 
> However, you right about Server A not knowing where to send packets back to. 
> And I tried pining 192.168.100.5 and it's not pinging.
> 
> 
> 
> Do I have to do something like:
> 
> 
> 
> route add -net 192.168.100.0 netmask 255.255.255.0 dev tun0
> 
> 
> 
> ????
> 
> 
> 
> I am not sure about this part either. Or would I have to do a static route 
> using "ip route add" which again I am not sure of the details.
> 
> 
> 
> Thanks,
> 
> Bruce
> 
> > Date: Wed, 22 Sep 2010 11:56:42 -0400
> > From: [email protected]
> > To: [email protected]
> > Subject: Re: [on-asterisk] OpenVPN Gurus! How to forward all traffic from 
> > eth1 to tun0?
> > 
> > Bruce,
> > You said that the phones are assigned 192.168.100.0/24 addresses by 
> > server B, but there is no route in Server A that says use the tunnel to 
> > send packets for 192.168.100.0/24 back to Server B.
> > 
> > My point is that server A needs that route for it to work. Server A 
> > doesn't keep a record of how a packet gets from 192.168.100.0/24 - it 
> > just uses the routing table.
> > 
> > Of course, server B doesn't have an explicit route either - how does it 
> > know where to send packets for 192.168.100.0/24?
> > 
> > Regards,
> > Doug.
> > 
> > 
> > 
> > 
> > 
> > On 22/09/2010 10:58 AM, Bruce N wrote:
> > >
> > > Douglas,
> > >
> > > Thanks for the feedback. The reason why I was hitting the tunnel address 
> > > is because Server A (openvpn server/Asterisk server) is a stand alone 
> > > server and doesn't have any local IP number. It has a Vnet with Public IP 
> > > address and then loop back of 127.0.0.1. If I ping the public IP address 
> > > then my ping doesn't go through the tunnel and I am not sure if that's 
> > > right anyways because then NAT stuff and externip should kick in. So, I 
> > > don't have another IP than the tun IP to ping or register to. Am I 
> > > missing something?
> > >
> > > Following is the netstat -rn:
> > >
> > > Server A - OpenVPN Server - Tun address: 172.16.0.1
> > > 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
> > > 192.168.50.0 172.16.0.2 255.255.255.0 UG 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 - OpenVPN Client - Tun address: 172.16.0.6
> > > Kernel IP routing table
> > > Destination Gateway Genmask Flags MSS Window irtt Iface
> > > 172.16.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
> > > 192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> > > 172.16.0.0 172.16.0.5 255.255.255.0 UG 0 0 0 tun0
> > > 192.168.0.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
> > > 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
> > >
> > > Regards,
> > > Bruce
> > >
> > >> Date: Wed, 22 Sep 2010 10:20:48 -0400
> > >> From: [email protected]
> > >> To: [email protected]
> > >> Subject: Re: [on-asterisk] OpenVPN Gurus! How to forward all traffic 
> > >> from eth1 to tun0?
> > >>
> > >> 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.
> > >>
> > >>
> > >>
> > >>
> > > 
> > >
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> > 
> 
                                          

Reply via email to