Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 5 – Networking and Internal Router

Note: This review was originally posted on the Michigan Telephone, VoIP and Broadband blog

In our previous installment we completed setting up the VoIP portion of the Atcom AG-188N (sold in North America by CIGear), touching on some of the other screens in the process. But there’s a whole other side of this great device that I have avoided touching on until today. If I were a TV infomercial pitchman, this might be the point where I’d take a dramatic pause and say, “You’d think there wouldn’t be anything more that we could pack into this small of a package — but wait, there is more —it’s ALSO a ROUTER!!!” And then the studio audience would applaud on cue!

And when I say router, I mean that it includes a DHCP server, NAT (port forwarding), QoS (Quality of Service), and even some limited VPN (Virtual Private Network) Tunneling support. Now, one reason I’ve sort of avoided talking about this is because of all the things I understand with regard to computing and VoIP, the area where my knowledge is weakest is networking. The whole process of getting packets from point A to point B over the Internet is sort of a “black hole” for me. And I’m not one of those reviewers that tries to convince you that I’m smarter than everybody else, and know everything about everything – if you’ve ever taken even one networking class, you’re probably way ahead of me. So what I’m going to do here is show you the screenshots and tell you what I can, but if I make some wildly inaccurate statement, kindly let me know in the comments, okay?

In Part 2 of this series, I showed you the WAN configuration page. Let’s take one more look at it:

Atcom AG-188N WAN configuration screen

As you see, you can enter static IP information, dynamically obtain an IP address, or use PPPoE. Depending on which you choose, you may need to fill in additional information in the text boxes. Most users will simply pick DHCP to obtain an address from an “upstream” router and be done with it — if you’re like me, you may not understand exactly how it works, you’re just glad it does. But, if you need or want to assign a static IP, or need to use a PPPoE server, you have that ability. Most VoIP adapters will let you use DHCP or a static IP address, but I can’t recall seeing any others that offer PPPoE support.

As I mentioned in the previous article, the manual is silent on the usage of the “Mac Authenticating Code” field, but the most likely use is for “cloning” the Mac address of another router or computer, in the unlikely event that your ISP actually cares what you plug into their cable or DSL modem.

Now let’s look at the LAN configuration settings:

Atcom AG-188N LAN configuration screen

If you are sending this unit to someone in a remote location and you don’t know whether they are going to plug a computer, a switch, a router, or nothing at all into the LAN port of this device, the default settings are probably the safest – as long as whatever’s plugged into the LAN port gets its address using DHCP, it should work. Providers could send a unit to a customer, knowing that if the customer simply unplugs the network cable from the back of the computer and plugs it into this unit, then uses another network cable to go from this device to the computer, it will still work in most cases (provided they don’t swap the WAN and LAN port connections, anyway).

In the specific case where the WAN port of this device is connected to another router, it’s true that having two routers “stacked” may not be an optimum situation, since you are doing two levels of Network Address Translation (NAT) — therefore this configuration could interfere with certain services (perhaps ironically, one of the things that would be most likely to be affected adversely would be any SIP-based softphone client running on a computer behind the two levels of NAT). But for most typical end users, the defaults are probably the safest if you have no idea what they are going to do on their end.

However, for those who know what they are doing, you can tweak the settings for a more optimum configuration. The available settings are

• Bridge Mode: You’d probably want to enable this if you know that the AG-188N will be connected to an “upstream” router, rather than directly to a cable or DSL modem. When this is checked, the AG-188N will not assign IP addresses for devices connected to its LAN port — the AG-188N and any devices plugged into the LAN port will all be on the same network. This would avoid the “double NAT” problem mentioned above. Note that this setting will not take effect until you save the config and reboot the device.
• IP: The base IP address for the local network. This is also the address that you can use to access the AG-188N configuration pages from devices connected to the LAN port. Normally it should always be in one of the “private” IP address ranges and should always end in .1. In almost all situations it is safe to leave it at the default — the one exception is if the “upstream” network also uses the 192.168.10.x address range, in which case you might want to change the “10” to some non-conflicting address. You almost certainly must change this if there is already an upstream device (such as an upstream router) using 192.168.10.1.
• Netmask: If your IP is in the 192.168.x.x range then leave this at the default. If you change the IP to something outside that range, I assume you know what needs to be used here.
• DHCP Server: Enables DHCP service in LAN port. Leave this checked unless you are using “Bridge Mode”, or have a specific reason for turning it off (such as, ALL connected devices use a fixed IP address).
• NAT: Enables Network Address Translation. Also leave this checked unless you are using “Bridge Mode.”

Note that it may not hurt anything to leave the DHCP Server and NAT enabled when using “Bridge Mode”, but I simply prefer to leave no doubt that we want the “upstream” router to handle these functions. I discovered that enabling “Bridge Mode” does not seem to totally disable the internal LAN, as evidenced by the fact that even though my computer received its IP address from the “upstream” router (in the 192.168.0.x range), I could still access the AG-188N’s web pages on either the 192.168.10.1 address, and that was true even if I disabled the DHCP Server and NAT. So since I don’t know exactly how things are being handled internally, I just felt it best to tun off those services when running in “Bridge Mode.”

Now let’s look at the DHCP Service configuration page:

Atcom AG-188N DHCP Service configuration screen

I didn’t change anything on this page, and I don’t advise that you do so either unless you know what you are doing. Note that by default, the DHCP server will assign addresses in the range 192.168.10.1 through 192.168.10.30 (with 192.168.10.1 normally being the AG-188N itself), so if you want to assign any device a fixed IP address you’re safe in assigning it anything from 192.168.10.31 through 192.168.10.254 (of course, you’d have to connect the LAN port to a switch in order to connect multiple devices). For the most part the settings seem pretty self-explanatory. The one thing I didn’t fully understand is the setting for “Update Mode”, which has three choices: None, Update firmware, or Update config file. I turned to the manual for enlightenment and this is what it had to say:

Update Mode: Using DHCP updated model, None expressed are not updated, Update firmware update firmware is used to DHCP. Update file is used to configure DHCP updated configuration files.

Um, okay then. Seems like the default choice of “None” is probably right for most users. So, since there’s really nothing to see here (for most users, anyway), let’s move along to the NAT configuration page:

Atcom AG-188N NAT configuration page

Again, I didn’t change anything on this page, and most users won’t need to either. The exception would be if you need to map a port to a particular device — this is where you’d do it. Just fill in the blanks for your new port mapping rule, click add, and you’re all set. Under “Transfer Type” your choices are TCP or UDP. Oh, and in case you’re wondering about the first three checkboxes, ALG apparently stands for Application-Level Gateway, and if you click on the link it will take you to a Wikipedia article on the subject.

The Net Service page lets you change certain default port settings used by the AG-188N, and shows you a table of all devices that currently have DHCP leases:

Atcom AG-188N Net Service and DHCP Lease Table screen

Most users will not want to change any of these, and I certainly would not advise doing so, but you can if you really want to. If you change the HTTP port and then forget what you changed it to, you probably will not be able to access the Web interface, so be careful here!

The next page we’ll look at is the QoS page:

Atcom AG-188N QoS configuration page

QoS stands for “Quality of Service”, and is a method for giving certain packets priority over others. Of all the screens on this device, this is the one of the two that I comprehend the least, and I get the distinct impression that either the author of the manual didn’t fully understand it either, or else felt that anyone changing the parameters on this page would know what they were doing. Here’s what it has to say about this screen (slightly edited to clean up obvious spelling/punctuation/syntax errors):

AG188 implements QoS based on 802.1p. The QoS is used to mark the network communication priority in the data link/MAC sub-layer. AG188 will sort the packets using the QoS and send them to the destination.

• VLAN Enable — Disable/Enable VLAN function
• VLAN ID Check Enable – not defined by the manual
• Voice/Data VLAN differentiated — what the manual has to say about this is borderline incomprehensible, but basically you have three choices Undifferentiated, Tag differentiated, and Data untagged. Here’s the actual, verbatim phrase from the manual: “undifferentiated for Date and voice VLAN is not distinction VLAN tag, Tag differentiated for Date and Voice VLAN is distinction VLAN tag, Date untagged for Date VLAN is distinction VLAN tag.”
• DiffServ Enable — Disable/Enable Diffserv service
• DiffServ Value — Configure the Diffserv parameter. The permissible range of values is: 0x28, 0x30, 0x38, 0x48, 0x50, 0x58, 0x68, 0x70, 0x78, 0x88, 0x90, 0x98, 0xb8. The default is 0xb8, which stands for best fast transmission; 28-30 is guarantee for the transmission priority for the 1st rank, 48-58 is guarantee for the transmission priority for the 2nd rank, 68-78 is guarantee for the transmission priority for the 3rd rank, and 88-98 is guarantee for the transmission priority for the 4th rank.
• Voice VLAN ID — configure the Voice/signaling VLAN ID
• Data VLAN ID — Assign VLAN id for data stream.
• Voice 802.1p Priority — Configure the priority of the voice packets in 802.1p protocol.
• Data 802.1P Priority — Configure the priority of the data packets (non-voice/signaling data) in 802.1p protocol.

There’s also a separate section in the manual on VLAN implementation, which shows several screen captures that will hopefully aid you in setting this up. Honestly, I’d welcome comments from anyone who can further enlighten me on the correct way to set this up. If you don’t use the LAN port, or if you are not pushing much data through the LAN port while on calls, it’s probably okay to leave this not enabled. But if you do use the LAN port, and you experience voice breakups and other weirdness while you are on the phone, the best advice I can give you is to try the various sample configurations in the “VLAN implement” section of the manual. If anyone is an expert on QoS implementation, please leave a comment and help us understand the correct way to configure this!

There’s one more networking-related page to talk about, and it’s the other one that I have relatively little understanding of, although I’d definitely like to increase my knowledge. Let’s look at the VPN Tunnel page:

Atcom AG-188N VPN Tunnel configuration page

The AG-188N supports VPN (Virtual Private Network) tunneling using either UDP (apparently a custom format for one specific customer) or L2TP (without IPSec). Unfortunately, it does not support other popular methods, such as IPSec, PPTP, or OpenVPN. For those who may not understand why you’d want to use a VPN tunnel, I’m going to quote an excerpt from the Wikipedia article on VoIP VPN here, since it explains this far better than I could (just replace the reference to “IPSec” with “UDP or L2TP”):

A VoIP VPN combines Voice over IP and Virtual Private Network technologies to offer a method for delivering secure voice. Because VoIP transmits digitized voice as a stream of data, the VoIP VPN solution accomplishes voice encryption quite simply, applying standard data-encryption mechanisms inherently available in the collection of protocols used to implement a VPN.

The VoIP gateway-router first converts the analog voice signal to digital form, encapsulates the digitized voice within IP packets, then encrypts the digitized voice using IPSec, and finally routes the encrypted voice packets securely through a VPN tunnel. At the remote site, another VoIP router decodes the voice and converts the digital voice to an analog signal for delivery to the phone.

…..

Security is not the only reason to pass Voice over IP through a Virtual Private Network, however. Session Initiation Protocol, a commonly used VOIP protocol is notoriously difficult to pass through a firewall because it uses of random port numbers to establish connections. A VPN is one solution to avoid a firewall issue when configuring remote VoIP clients. The VPN virtually moves users inside the same network local as the VoIP server.

Edit: Unfortunately, it turns out that the AG-188N uses L2TP without IPSec, which means that the comments about voice encryption in the above excerpt aren’t applicable – L2TP alone does not offer any form of encryption. However, the final paragraph of the excerpt, talking about how a VPN tunnel could overcome difficulties with firewalls when SIP is used, would still be applicable.

Here’s the explanation of the settings on this page:

• VPN IP — After the AG-188N has registered successfully on the VPN, the VPN server will assign an IP address to the device. If there is a IP address other than 0.0.0.0 shown here, it means that you are successfully registered on the VPN.
• UDP Tunnel and L2TP settings — These are obvious from the text field labels. Only fill in the settings for the protocol you plan to use (probably L2TP unless you can somehow reverse-engineer the UDP method).
• UDP Tunnel and L2TP radio buttons — Click the one corresponding to the type of tunnel you plan to use.
• Enable VPN — Enable the VPN server — you must choose either UDP or L2TP type in advance.

Some of you may be wondering – if you set up a VPN tunnel, does all traffic get routed through it (including any traffic on the LAN port), or only VoIP traffic? And, if only VoIP traffic, will it route both SIP and IAX protocols over the tunnel, or just one or the other? And unfortunately, I simply don’t know the answer to that at this point. I also don’t know how to set up a VPN using either UDP or L2TP on an Asterisk/FreePBX server, otherwise I might give this a go. If if any of the more popular forms of VPN tunneling were supported (such as IPSec, PPTP, or OpenVPN) I might be able to set those up and administer them using Webmin, but it appears that there are no Webmin modules available to help configure L2TP or UDP tunnels.

Edit: After receiving some clarification that this uses L2TP without IPSec, I Googled a bit and found a blog post entitled “Use Linux to Setup L2TP Server (without IPSec)” that appears to give server installation and configuration instructions that should work under CentOS (the opening paragraph is in Chinese, but the actual steps are all in English, and if you’re curious about that opening paragraph you can always view the Google translation). However, I think I’d try using yum install l2tpd rather than using rpm in the first instruction; if that doesn’t work you can always try the rpm method. It looks like it should be a pretty simple installation, but I have not actually attempted it yet.

At this point, this may be my only real letdown with the AG-188N – I was enthused when I saw that it supported VPN, but that enthusiasm rather quickly deflated when I saw that it really didn’t support any of the more widely-used VPN protocols (Edit: and in particular, none that offer encryption). And granted, my disappointment may be in part based on my lack of proficiency in setting up a VPN server, or some other lack of understanding — feel free to enlighten me! — and in any case, my disappointment here is tempered by the knowledge that no other ATA’s (to the best of my knowledge) support any form of VPN tunneling. The vast majority of users of this device are probably not going to care whether it supports VPN or not, let alone which “flavors” of VPN, but it’s just something that had particular appeal to me.

This is a subject I’d obviously like to know more about — some readers may recall my post, New Products Wanted, part 1: Simple VPN devices (switches and/or routers) — so I welcome any comments that might help me set up one of the supported forms of tunneling, especially if there is a web-based GUI administration utility available (sorry, Linux gurus, I don’t share your affinity for config files and the command line).

There are a few other configuration pages on the AG-188N that I have not discussed separately, either because their purpose and usage is fairly self-evident (Clear Config, Backup Config, WEB Update — the latter lets you upload new firmware or restore backup configuration files) or are of interest primarily to service providers and other “system administrator” types (FTP/TFTP Update, Auto Provisioning). If you really want to see screenshots of any of these, leave a comment and I’ll post them in a followup article.

In the next installment, I plan on wrapping up this series (for now, anyway) with some final thoughts and a summary review. I hope you’ve enjoyed this exploration of the AG-188N up to this point as much as I have!

Disclosure: CIGear provided me with an Atcom AG-188N for review purposes, and allowed me to keep it after I was finished writing this series, and for that I am most grateful.

Previous Installment | Next Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

The post Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 5 – Networking and Internal Router appeared first on VoIP Blog by VoipSuperstore.