July 21, 2007

Altigen VOIP over the Internet

Filed under: Cisco — wansend @ 7:28 am

Following are notes for the Altigen Altiware OE 5.0A with Update 4 running on the Windows platform. Configuring Altigen VOIP to work over the Internet can be very tricky. Firewalls are the source of the problem on both the client and server side. Each end of the IP conversation needs to be able to independently contact the other end. If you don’t lock down ports on the server side, hackers will connect on UDP 137, 138, 139, 1026, 1027 and TCP 80, 139 and cause trouble.

Server-side solution: Take a second Cisco router that can bypass the firewall. On it you make the following tweeks:

access-list 105 remark Altigen VOIP ports allowed for route-map
access-list 105 permit tcp host eq 10032 any
access-list 105 permit tcp host any eq 1720
access-list 105 permit tcp host range 49152 50152 any
access-list 105 permit udp host range 49152 50152 any

interface Ethernet0/0
description Inside Network – to hubs.
ip policy route-map bypass-firewall

ip nat inside source static extendable no-alias no-payload

route-map bypass-firewall permit 10
description Bypass the firewall and go directly out to the Internet
match ip address 105
set ip next-hop

Client-side Solution: Go to the website and find a compatible router. Go ahead and try opening up those ports on your home wifi router before going with the dd-wrt method. Upgrade the router with version v.23 SP2 or better and configure the following client-side port-forwards:

Name Port(s) TCP/UDP Destination Port(s)
AltigenPhone 10032 tcp 10032
AltigenH.225 1720 tcp 1720
AltigenH.245 49152-50152 both same

1. Plug phone into one of my wireless router’s four ports.
2. Turn phone on and verify that it has an IP address from my DHCP server –
3. Change phone’s server IP via Menu > System > AW Server
4. Turn on phone’s NAT via Menu > Network > Enable NAT > Yes.
5. Register the phone via Menu > Register


May 17, 2007

Using Ping to find the largest MTU along a VPN route

Filed under: Cisco — wansend @ 11:24 pm

When a wide area network uses a VPN, additional overhead will cause packet fragmentation that can slow the network down and cause Microsoft Active Directory to grind to a halt. You can use Ping.exe and the [x+28=MTU] rule to determine the effective MTU that should be configured on the Cisco Router. MTU is the Maximum Transmittal Unit packet size. For this exercise [] is the remote IP of another Microsoft box that we are going to test pings to.

1. From a Microsoft box, ping – to make sure it is up across the VPN.

2. ping -f -l 1473     This will show you what a failed fragment ping looks like. 1473+28=1501 which automatically gets fragmented because it is greater than 1500, the default MTU.

3. Ping -f -l 1449     This failed for me, meaning an MTU of 1449+28=1477 wasn’t small enough.

4. Ping -f -l 1448     This pinged successfully for me, meaning an MTU of 1448+28=1476 didn’t get fragmented – which is good. I’m looking for the largest number I can get that doesn’t fail. Now I know what MTU to configure on my VPN routers – 1476.

5. Now go to the Cisco router configuration terminal mode for the VPN interface and add the line “ip mtu 1476” or whatever number you come up with in the last step. You shouldn’t have to add the line to the Ethernet interfaces because that would squelch all of the traffic, even browser traffic that doesn’t use the VPN.

When you hold down the MTU anywhere along the line of the router path, the routers will advertise the smallest MTU as part of the TCP/UDP negotiation process. You’d think MTU discovery would be automatic, but it is only half-automatic. Still this is better than using Regedit on every computer to tweek the MTU downward.

Blog at