Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have come across a strange problem with our VPN and BCM 50 (Nortel/Avaya) phone system.

As you can tell by my other questions I have been doing some work on setting a VPN up from one location to another and it's all working well. With one exception.

We have an IP phone that is connected at the remote location, straight to a router which has a VPN tunnel to our main practice. The phone works mostly, but every few calls it turns into a one way call. As in, the caller (from the remote phone) can't hear the receiver- but the receiver can hear the caller.

This is fixed by setting the VPN tunnel to be the default route for all traffic.

The problem with fixing it that way is that all traffic then goes through the tunnel which slows internet access etc. down considerably.

The router is set to send the following over the VPN:

192.168.1.0/24
192.168.2.0/24
192.168.4.0/24

The IP of the remote location is:

192.168.3.0/24

The remote router (where the phone is) is a Draytek 2830n, and the local router (at the main practice) is a Draytek 2820.

We are using an IPSec tunnel with AES encryption <- as a result of a previous answer pointing to the incompatibility in the hardware encryption.

Any advice would be appreciated!

Network Topology

IP Phone
Draytek Vigor 2830n

IPSec VPN <

Draytek Vigor 2820
Nortel 2550 Switch
BCM Phone System

It's important to note that although the switch is managed externally (By British Telecom), I don't believe this issue is caused by the switch config. Mainly because it works fine when I set the VPN to be the default route.

Routing Table (Remote Site)

Key: C - connected, S - static, R - RIP, * - default, ~ - private
*            0.0.0.0/ 0.0.0.0          via PUBLIC IP   WAN2
S~       192.168.1.0/ 255.255.255.0    via REMOTE IP     VPN-1
S~       192.168.2.0/ 255.255.255.0    via REMOTE IP     VPN-1
C~       192.168.3.0/ 255.255.255.0    directly connected    LAN2
S~       192.168.4.0/ 255.255.255.0    via REMOTE IP     VPN-1
C    PUBLIC IP/ 255.255.255.224  directly connected    WAN2

Routing Table (Main Practice)

Key: C - connected, S - static, R - RIP, * - default, ~ - private
*             0.0.0.0/         0.0.0.0 via BT GATEWAY IP,   WAN2
S        PUBLIC IP/ 255.255.255.255 via PUBLIC IP,   WAN2
*         BT GATEWAY IP/ 255.255.255.255 via EXTERNAL IP,   WAN2
C~        192.168.1.0/   255.255.255.0 is directly connected,    LAN
S~        192.168.2.0/   255.255.255.0 via REMOTE USER IP,    VPN
S~        192.168.3.0/   255.255.255.0 via REMOTE IP (BRANCH),    VPN
S~        192.168.4.0/   255.255.255.0 via REMOTE USER IP,    VPN

Update

I've narrowed it down to an IP/DHCP problem. Any phone with an IP address above 1.212 doesn't work from the remote branch. Any phone that has an IP address that is given out by the Windows DHCP scope that I maintain (1.1 - 1.150) works fine. The only other DHCP server is the BCM itself which has a scope of 1.210 - 1.240. I can't work out why a VPN tunnel'd phone wouldnt correctly communicate with the BCM.

If I make a call to an external number (Mobile for example) it works fine. If a caller calls our reception and then they transfer the call to the remote branch, we can't hear the colleague transferring the call (explaining who's calling etc.) but once the call is transferred it works fine. As in we can hear the mobile caller and vica-versa.

share|improve this question
    
We have our networks with IP phones setup with VLANs. That way you can also setup QOS and setup default routes for only the IP phone network. I don't have the details, but might make a better long term solution –  Nixphoe Nov 24 '11 at 16:16
    
Can you put your DHCP scopes up here - and also the IP addresses of all the gateways as far as internal clients are concerned? –  Mister IT Guru Nov 24 '11 at 17:28
    
I have removed the second DHCP server and widened the scope of the first. Seems to have corrected the problem. Although, the scopes never overlapped. –  dannymcc Nov 24 '11 at 20:19

3 Answers 3

up vote 1 down vote accepted
+100

Make sure routing works correctly; set up a notebook in the same network as the ip phone for testing (it's easier).

Furthermore, can't you set the default route just on the IP phone? I didn't have really the time to dive into your routing setup, but it looks OK on the first glance. I'd say something might be set up wrongly on the phone.

Oh and make sure that you disable any SIP ALG's on all devices in between. From my experience, they cause more problems than they solve (sometimes "helping" when there's not even a NAT in play!).

share|improve this answer
    
I've narrowed it down to an IP/DHCP problem. Any phone with an IP address above 1.212 doesn't work from the remote branch. Any phone that has an IP address that is given out by the Windows DHCP scope that I maintain (1.1 - 1.150) works fine. The only other DHCP server is the BCM itself which has a scope of 1.210 - 1.240. I can't work out why a VPN tunnel'd phone wouldnt correctly communicate with the BCM. –  dannymcc Nov 24 '11 at 15:37
    
That would've been my next suggestion, to look into the DHCP (assigning a wrong route). You should've mentioned that you've got multiple DHCP servers! :) –  Roman Nov 24 '11 at 15:41
    
Sorry! I can't understand why it would hinder the phones though. Is there a step I'm missing that allows the VPN phone to see the second DHCP server? –  dannymcc Nov 24 '11 at 15:43
    
More than one DHCP server is asking for trouble - you must take great care when doing so! See, first mistake already spotted: letting the ranges of these two server overlap. That introduced a race condition: whatever server replies first, wins. And those two don't have the exact same configuration, do they..? –  Roman Nov 24 '11 at 15:59
    
That's true but the scopes didn't overlap. One was 1.1-1.150, the other was 1.210/1.240. Strange! –  dannymcc Nov 24 '11 at 20:20

My gut here is that this is either a routing issue or maybe a QoS issue. In my experience, one-way audio is almost always a routing issue. Let's be certain of the only devices involved (at L3): Phone <-> Router <-IPSEC-> Router <-> Phone. There may or may not be switches between the phones and the routers. Now... on these assumptions, can you post the CLI output of the routing table from each router? Please remove any public IPs if you do.

share|improve this answer
    
I've added the network topology and the routing table outputs to the original question. Thanks. –  dannymcc Nov 20 '11 at 15:26
    
okay... good feedback the routing looks correct... am I correct that the phone and/or phone system is connected to the 1.0/24 subnet? –  SpacemanSpiff Nov 20 '11 at 15:56
    
Yep, the phone system is on 1.0/24. No VLANS or anything. The phone with issues is on 3.0/24. The phone works fine when taken to the main office and connected to the switch. –  dannymcc Nov 20 '11 at 16:24
    
During a one-way audio scenario you should use your switch to mirror your routers port to another port with a PC running wireshark to see if the phone system is still transmitting packets destined for the remote phone. If it is still transmitting, you should then see if the router can communicate with the phone. –  SpacemanSpiff Nov 20 '11 at 16:50
    
I take it I should be mirroring the port of the router that the remote phone is on (3.0/24)? –  dannymcc Nov 20 '11 at 16:58

VoIP uses RTP which doesn't work properly with asymmetric routing. Make sure your setup is symmetric routing.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.