How I hooked up VOIPo

[ctaranto]

I'm hoping this information will help new comers to VOIPo. I've received lots of help from others on this forum and would like to contribute something back.

First, the thread where I was having trouble (long, but may be worth the read):
http://forums.voipo.com/showthread.php?t=1851

I am using a Linksys WRT54GL as my main router, connected to the Cable Modem. I liked the Tomato 3rd party firmware for it's excellent QoS features. After having issues with my previous VoIP provider (losing reauthentication randomly), I came across this:
http://www.broadbandreports.com/forum/r23423987-Equipment-Tomato-with-VOIP-warning

So, I replaced Tomato with DD-WRT (http://www.dd-wrt.com). It's QoS is not nearly as nice as Tomato, but I'm hoping it's good enough. I have it running on both my WRT54GL routers (see below). Please *PLEASE* read the instructions on the dd-wrt page. It's quite easy to brick your router if not done right (I bricked an older WRT54G v4 a few weeks ago because I didn't read all the instructions).

My network currently looks like this:


Cable Modem --- WRT54GL --- RT31P2 (VOIPo)
|
---------- Old PC in Basement
|
---------- Linksys 5 port switch (goes to 4 other devices)
|
---------- Linksys WRT54G-TM (T-Mobile Router for @Home)
|
---------- Many wireless devices, including:
Laptops (2)
Kids' PC
Another WRT54GL (Bridged)
Wii
PSP


Hooking these up with the correct settings was the interesting part. I'll only concentrate on the first WRT54GL and RT31P2 devices (and only the settings the pertain to core communications between the two devices). Wireless security and other doodads are up to you (but if you need help, feel free send a PM).

WRT54GL settings:
Setup tab
WAN
Connection Type: DHCP (IP provided by ISP)
STP: Disable

Router IP
Local IP Address: 172.20.0.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
Local DNS: 0.0.0.0

Network Address Server Settings (DHCP)
DHCP Type: DHCP Server
DHCP Server: Enable
Start IP Address: 172.20.0.100
Maximum DHCP Users: 51
Client Lease Time: 1440 Minutes (default)
Static DNS 1, 2, 3: 0.0.0.0
Use DNSMasq for DHCP: checked
use DNSMasq for DNS: checked
DHCP-Authoritative: checked

Security tab
Firewall Protection
SPI Firewall: Enabled
Additional Filters: all unchecked
Block WAN Requests
Block Anonymous WAN Requests (ping): checked
Filter Multicast: checked
Filter WAN NAT Redirection: unchecked
Filter IDENT (Port 113): checked

NAT/QoS tab
Port Forwarding: None
Port Range Forwarding: None
DMZ: Disabled
QoS
Services Priority
bittorrent: Bulk
MAC Priority
MAC Address (enter WAN MAC of RT31P2): Premium

On to the RT31P2:
Setup
Internet Setup:
Static IP
IP Address: 172.20.0.3
Subnet Mask: 255.255.255.0
Default Gateway: 172.20.0.1
DNS 1: 172.20.0.1
DNS 2,3: 0.0.0.0

Network Setup:
Router IP
Local IP Address: 172.20.0.2
Subnet Mask: 255.255.255.0
Local DHCP Server: Disable

Advanced Routing
NAT: Enable
Dynamic Routing: Disable

Applications & Gaming
Port Range Forwarding: None
Port Triggering: None
UPnP Forwarding: None
DMZ: Disable
QoS: Disable

Adminstration
UPnP: Disabled


Now for the wiring hookup.

Wire from Cable Modem to WRT54GL WAN
Wire from WRT54GL LAN to RT31P2 LAN (I used Port 2)
Wire from RT31P2 LAN (Port 1) to RT31P2 WAN

I only connect systems (laptops, PCs, consoles, etc.) to the WRT. It provides IP addresses and handles all the traffic in and out of the house. In the end, you can administer the WRT at 172.20.0.1 and the RT at 172.20.0.2.

In short, the RT went from a router to a switch. Voice traffic only goes in and out of the RT WAN Port, so by connecting the WAN to the LAN within the RT, it's moving out the WAN of the RT and into the LAN of the RT, and then out the LAN of the RT into the WRT, and then out to the internet (and vice versa).

This has been rock solid for me for 3+ days (not long, but long enough to prove reauth works fine). My wife was on one call yesterday for 3.3 hours. No disruptions, disconnects, etc. I find it interesting (and wonderful) that this works without port forwarding and/or DMZ.

My goal was to put the WRT first in line due to it's stronger firewall. I attempted to put the RT first, but found that many ports were either open or closed (not stealth). A great resource to test for security is "Shields UP!" at http://www.grc.com. In my currently setup, all ports appear to be "stealth"

If I find that this fails reauth in the future, I'll provide an update.

Feel free to ask questions or for clarifications. I can update this post with necessary information.

Thanks,

-Craig

[lost_]

So, I replaced Tomato with DD-WRT (http://www.dd-wrt.com). It's QoS is not nearly as nice as Tomato, but I'm hoping it's good enough.

I'm running Tomato on a Buffalo router -- no problem so far.



Now for the wiring hookup.

Wire from Cable Modem to WRT54GL WAN
Wire from WRT54GL LAN to RT31P2 LAN (I used Port 2)
Wire from RT31P2 LAN (Port 1) to RT31P2 WAN


Any particular reason why you needed to go through RT LAN to WAN? It's practically the same as RT WAN being connected directly to router LAN, without the dummy switching on the RT LAN.

I simply hooked up mine the way I have always hooked up ATA for years with no issue or any port forwarding needed:

Cable Modem -> Router -> ATA's WAN Port.

Also, instead of setting the static IP on the RT, just leave RT in DHCP mode and set the DD-WRT to hand out static IP to the RT. No need to manually set DNS server on the RT either.


EDIT: I read the original thread, and errr... well... if that works for you, great! (to quote DSLR: "on second thought, I do not wish to post").

[ctaranto]

Any particular reason why you needed to go through RT LAN to WAN? It's practically the same as RT WAN being connected directly to router LAN, without the dummy switching on the RT LAN.

The behavior for me is different. I'm guessing here, but possibly connecting to the LAN instead of WAN bypasses some "stuff" in the RT. I read about hooking things up this way and the poster gave a reason. I'll have to find the site/post.


I simply hooked up mine the way I have always hooked up ATA for years with no issue or any port forwarding needed:

Cable Modem -> Router -> ATA's WAN Port.

Yep. Tried that. Worked for a little while, but kept losing reauth.


Also, instead of setting the static IP on the RT, just leave RT in DHCP mode and set the DD-WRT to hand out static IP to the RT. No need to manually set DNS server on the RT either.

I could have used DHCP to assign the 172.20.0.3 address, but figured static reduces any lease and renewing issues that could happen during a call.



EDIT: I read the original thread, and errr... well... if that works for you, great! (to quote DSLR: "on second thought, I do not wish to post").
I'm not sure why, but Tomato didn't work for me with a WRT54GL. Wish it did. Maybe if I'm daring enough, I'll try it again.

[MisterEd]

EDIT: I read the original thread, and errr... well... if that works for you, great! (to quote DSLR: "on second thought, I do not wish to post").


I agree ... I've never seen such a simple installation made so confusing. :) Bottom line was he reset the RT and lost all the provisioning. In the end, had that not happened, the whole issue would have been a non-issue.

[ctaranto]

I agree ... I've never seen such a simple installation made so confusing. :) Bottom line was he reset the RT and lost all the provisioning. In the end, had that not happened, the whole issue would have been a non-issue.

For the first thread, yes, that's mostly true. But just connecting a LAN Port of the WRT to the WAN port of the RT caused reauth issues. The set up explained in this thread appears to have resolved that.

/c

[MisterEd]

For the first thread, yes, that's mostly true. But just connecting a LAN Port of the WRT to the WAN port of the RT caused reauth issues. The set up explained in this thread appears to have resolved that.

/c

You original post might mistakenly lead people to believe it has to be done that way. You might want to clarify your original post. 99.9% of the people wouldn't need to go through all that and I can't understand why you should have had to either.

[ctaranto]

You original post might mistakenly lead people to believe it has to be done that way. You might want to clarify your original post. 99.9% of the people wouldn't need to go through all that and I can't understand why you should have had to either.

I have updated the post where I begin talking about not getting Phone 1 lit. Good suggestion.

/c

[ctaranto]

I switched my WRT firmware from dd-wrt to Tomato (with hardc0re's mod to enhance performance) yesterday afternoon. Throughout last night and this morning, no loss of connection (calls are fine, no reauth issues). So far, so good.

If things go well with Tomato for the next week or so, I'll assume that the reauth issues potentially come from the NAT/firewall within the RT. Running Tomato and hooking up the WRT to the RT WAN port was problematic (at least for me).

Updates coming later...

-Craig

[tritch]

A quadruple NAT setup to get it to work??? It's amazing this setup is working without any problems. Personally, I would be hesitant to ever recommend such a setup.

If it's really necessary to have such a complicated setup, then it's either:
1) a bad ATA or
2) a bad ATA configuration/provisioning issue or
3) a bad router or
4) router setup problem.

It should be as simple as modem - ATA - router, or modem - router - ATA with a preferred single NAT at the most. Any other setup indicates a problem component and/or setup issue.

[ctaranto]

A quadruple NAT setup to get it to work??? It's amazing this setup is working without any problems. Personally, I would be hesitant to ever recommend such a setup.

If it's really necessary to have such a complicated setup, then it's either:
1) a bad ATA or
2) a bad ATA configuration/provisioning issue or
3) a bad router or
4) router setup problem.

It should be as simple as modem - ATA - router, or modem - router - ATA with a preferred single NAT at the most. Any other setup indicates a problem component and/or setup issue.

With modem -> router -> ATA, how does one get single NAT? Turning NAT off on the RT makes it not get Phone 1 lit.

And where are my "4 NATs"? Not knowing what happens internally, I believe that having the RT entirely on the 172.20.0 network, it's not doing NAT at all. I thought NAT happens when going from 172 to 192, or public to private.

-Craig

[tritch]

With modem -> router -> ATA, how does one get single NAT? Turning NAT off on the RT makes it not get Phone 1 lit.

And where are my "4 NATs"? Not knowing what happens internally, I believe that having the RT entirely on the 172.20.0 network, it's not doing NAT at all. I thought NAT happens when going from 172 to 192, or public to private.

-Craig

Assuming your modem is bridged, there's only one IP change from your public IP through your DHCP router to ATA ......thus single NAT.

If your ATA is attached directly to a bridged modem, there's no NAT at all since the ATA is seeing your public IP. Only the device's attached to the LAN port of the RT31P2 experience NAT.

My apologies, it looks like there is less than 4 NAT's since you turned off the DHCP server in the RT31P2. I'd have to study your setup a little closer to get a better idea of how many NAT's are going on.

There's still a problem somewhere in your setup if you are having to go to this trouble.

[ctaranto]

Assuming your modem is bridged, there's only one IP change from your public IP through your DHCP router to ATA ......thus single NAT.

If your ATA is attached directly to a bridged modem, there's no NAT at all since the ATA is seeing your public IP. Only the device's attached to the LAN port of the RT31P2 experience NAT.

My apologies, it looks like there is less than 4 NAT's since you turned off the DHCP server in the RT31P2. I'd have to study your setup a little closer to get a better idea of how many NAT's are going on.

There's still a problem somewhere in your setup if you are having to go to this trouble.

Having the ATA directly attached to the modem is a no-go. The RT is an insecure device - it's firewall, in a single word, sucks. When I had it directly connected, a run of ShieldsUp at grc.com showed ports were closed, not stealth. And a few ports were open.

Having the ATA behind the WRT caused reauth issues when the WRT was directly connected to the WAN port of the RT.

Which brings me to the topology in the first post of this thread.

-Craig

[burris]

This is strange..

I have my ATA always behind the router...firewall off..NAT on..no port forwarding and no STUN and don't experience these problems..

[ctaranto]

This is strange..

I have my ATA always behind the router...firewall off..NAT on..no port forwarding and no STUN and don't experience these problems..

Firewall off on the router? That may explain a bit. I refuse to run my network that way.

Take a look at grc.com, go to ShieldsUp, and run a common port scan.

-Craig

[chpalmer]

Not to start anything here but... http://web.archive.org/web/20041212170503/http://grcsucks.com/

Is the Wan of the RT31P2 using dhcp to get its address by chance?

Your WRT has nothing in the "gateway" portion of its DHCP server according to your post. This should be its lan address. 172.20.0.1

Id also turn off dns forwarder if its on. I believe some routers have problems passing dns queries between the "client" and the internet when the forwarder is on... worth testing anyway.

[tritch]

Having the ATA directly attached to the modem is a no-go. The RT is an insecure device - it's firewall, in a single word, sucks. When I had it directly connected, a run of ShieldsUp at grc.com showed ports were closed, not stealth. And a few ports were open.

Exactly, that's the way the RT31P2 should behave ahead of your router.....allowing it to work more openly with the Internet.

In this scenario, your router is still providing the SPI firewall and protecting your internal network. Why do you really care about the RT's poor firewall ability which is upstream of your router. If the ATA was that insecure or easily hackable, Voipo would not prefer that you hook it up that way to begin with. However, Voipo does prefer it this way just to avoid SPI/NAT issues it encounters with some of its customers.


Having the ATA behind the WRT caused reauth issues when the WRT was directly connected to the WAN port of the RT.

Once again, the fact you are having issues with it hooked up this way is indicative of something else being wrong. No one should have to hook up this way in your topology to get to work correctly.

I took another look at your setup and you have at least double NAT or more going on. Per your topology, your router's DHCP is enabled with a starting IP pool address of 172.20.0.100, but I noticed your LAN and WAN IP's on the RT is 172.20.0.2 and 172.20.0.3 respectively. This tells me that more NAT is going on in the picture here because if you truly had the RT's DHCP server disabled then the LAN ports on the RT would act like a switch instead of a router and pull it's IP addresses from your WRT IP pool.

If it's working good for you this way, I really can't knock it too bad.;)

[ctaranto]

Exactly, that's the way the RT31P2 should behave ahead of your router.....allowing it to work more openly with the Internet.

In this scenario, your router is still providing the SPI firewall and protecting your internal network. Why do you really care about the RT's poor firewall ability which is upstream of your router. If the ATA was that insecure or easily hackable, Voipo would not prefer that you hook it up that way to begin with. However, Voipo does prefer it this way just to avoid SPI/NAT issues it encounters with some of its customers.

If insecure and "more openly" is synonymous, then I don't want it. :) VOIPo only needs certain ports. It shouldn't be THAT open. I actually prefer having a PAP2T, which HAS to be behind a router (that's what I had with VoicePulse). I want to mimic the topology that I had, with my WRT first in line. I also like to measure bandwidth usage and with the RT first, I can't do that.



Once again, the fact you are having issues with it hooked up this way is indicative of something else being wrong. No one should have to hook up this way in your topology to get to work correctly.


Maybe dd-wrt and hooking it up to the WAN is good enough. I never tried that. But I far prefer Tomato, and thus far, it's working.



I took another look at your setup and you have at least double NAT or more going on. Per your topology, your router's DHCP is enabled with a starting IP pool address of 172.20.0.100, but I noticed your LAN and WAN IP's on the RT is 172.20.0.2 and 172.20.0.3 respectively. This tells me that more NAT is going on in the picture here because if you truly had the RT's DHCP server disabled then the LAN ports on the RT would act like a switch instead of a router and pull it's IP addresses from your WRT IP pool.

The WRT's DHCP pool is .100. The RT isn't getting it's IPs from the WRT (I put them in statically), so .2 and .3 were chosen. Because an IP is outside of the DHCP realm (but inside the subnet mask), that causes NAT to be used? I didn't believe that was the case. I believe the way I've hooked it up, the RT *IS* a switch now. The only thing is the WAN port needs to be used because all voice communications goes out the WAN. DHCP is turned off on the RT, and nothing else is connected to it. I can also directly log into the RT via 172.20.0.2 (without any port numbers) while wireless connected to the WRT.

Are you suggesting that if I statically set the IPs of the RT to inside the DHCP range, I'll reduce a NAT? That doesn't quite make sense to me, but again, I'm not a network guy.

I believe (or believed) that by connecting directly to the LAN port, and putting the LAN and WAN in the same subnet, I'm *reducing* a NAT.



If it's working good for you this way, I really can't knock it too bad.;)

I'm enjoying this conversation (please don't take it as an argument). :)

-Craig

[tritch]

If insecure and "more openly" is synonymous, then I don't want it. VOIPo only needs certain ports. It shouldn't be THAT open. I actually prefer having a PAP2T, which HAS to be behind a router (that's what I had with VoicePulse). I want to mimic the topology that I had, with my WRT first in line. I also like to measure bandwidth usage and with the RT first, I can't do that.

I don't have this setup either, but it is preferred by Voipo. It must be secure enough, otherwise you'd be hearing of more ATA's being attacked or hacked.


The WRT's DHCP pool is .100. The RT isn't getting it's IPs from the WRT (I put them in statically), so .2 and .3 were chosen. Because an IP is outside of the DHCP realm (but inside the subnet mask), that causes NAT to be used? I didn't believe that was the case. I believe the way I've hooked it up, the RT *IS* a switch now. The only thing is the WAN port needs to be used because all voice communications goes out the WAN. DHCP is turned off on the RT, and nothing else is connected to it. I can also directly log into the RT via 172.20.0.2 (without any port numbers) while wireless connected to the WRT.

Ok, I stand corrected. I missed the fact you statically assigned the IP's on the RT with the same subnet.

Router setup:
IP: 172.20.0.1
Subnet: 255.255.255.0
Gateway: 0.0.0.0
DHCP enabled: starting IP pool of 172.20.0.100

RT LAN:
IP: 172.20.0.2
Subnet: 255.255.255.0
Gateway: 172.20.0.1

RT WAN:
IP: 172.20.0.3
Subnet: 255.255.255.0
Gateway: 172.20.0.1

LAN and WAN ports on the RT are set with static IP's which are on the same subnet as the router and do not automatically obtain IP's from the WRT. The RT is acting like a switch as you mentioned, so there's only a single NAT between your public IP and your RT which is good.

I do see a problem as chpalmer pointed out in his post. Your WRT's gateway should be 172.20.0.1 not 0.0.0.0 It's possible when you had the RT's WAN hooked up to the WRT's LAN that the router assigned this gateway to the RT as well. I'm assuming of course that you had the RT automatically obtain its IP address from the WRT's IP pool when you tried it before. You might want to see if that was the problem. If this resolves the issue, then you would want to reserve or assign a static IP for the RT in the router.

[ctaranto]

I don't have this setup either, but it is preferred by Voipo. It must be secure enough, otherwise you'd be hearing of more ATA's being attacked or hacked.


There were many things I didn't like about the RT being first. A few of them are:
1. The feeling I was insecure by ports not being "stealth"
2. Relying on the RT to handle all NAT. If it's NAT abilities aren't good (and it's hard to find info on this), then when using many bittorrent clients, I will see a performance hit.
3. The QoS setup in the RT is no where near as good as a WRT running Tomato.



I do see a problem as chpalmer pointed out in his post. Your WRT's gateway should be 172.20.0.1 not 0.0.0.0 It's possible when you had the RT's WAN hooked up to the WRT's LAN that the router assigned this gateway to the RT as well. I'm assuming of course that you had the RT automatically obtain its IP address from the WRT's IP pool when you tried it before. You might want to see if that was the problem. If this resolves the issue, then you would want to reserve or assign a static IP for the RT in the router.

Interesting that the Tomato firmware doesn't even offer a "gateway" for the Router IP (maybe it assumes the Router IP as the gateway?). I don't know the effect of this setting in dd-wrt in the current topology vs. hooking directly into the WAN. I also didn't try dd-wrt and hooking directly into the WAN.

Thanks,

-Craig