|
Joined: Sep 2005
Posts: 840
Member
|
Member
Joined: Sep 2005
Posts: 840 |
CC is correct, NAT is not supported on that version. Also not mentioned in the above posts is whether the fone itself has the public IP address entered into it as it's 'Remote IPC' address. Not that it matters, at least until the card is put on the public network...
|
|
|
Visit Atcom to get started with your new business VoIP phone system ASAP
Turn up is quick, painless, and can often be done same day.
Let us show you how to do VoIP right, resulting in crystal clear call quality and easy-to-use features that make everyone happy!
Proudly serving Canada from coast to coast.
|
|
|
Joined: Oct 2007
Posts: 27
Member
|
Member
Joined: Oct 2007
Posts: 27 |
Chris, thanks for your detailed response. We originally had it outside the firewall, but we had an issue with our internal phones connecting to it (phones pulled internal IP, had public IP set as IPRC card in phone, and if DMZ was set in our router to a specific phone, that phone would work, but all the others wouldn't. To make sure it wasn't a port issue, we added ports 1 - 65536 to a specific phone, turned off DMZ, and that phone still couldn't connect to it.) So essentially, when behind our firewall/router, only one phone can connect at a time, and that's only if it's set as the DMZ address (NETGEAR FVS318 firewall/router, if it matters).
superfoneguy, Yes, the IP address for the Remote IPC address is the public IP address of the card, not the 192.168.*.*
|
|
|
|
Joined: Jun 2007
Posts: 490
Member
|
Member
Joined: Jun 2007
Posts: 490 |
Most firewalls will not allow traffic to come in on the same interface that it went out on (hairpinning) however if you could assign the IPRC with it's own static public IP outside the firewall that will work. Now if your Internet service provides you with an appropriate block of external IPs is another story. The DMZ typically will have a security level halfway between your external interface and your internal, thus it would block traffic from the DMZ port to the internal subnet. If you were to put the IPRC completely outside with it's own IP (no port forwarding/NAT whatsoever) then your internal endpoints and external endpoints should be able to connect.
|
|
|
|
Joined: Oct 2007
Posts: 27
Member
|
Member
Joined: Oct 2007
Posts: 27 |
Yes, we're provided with a block. When I had it on a public IP address, I was plugging the IPRC card into the switch coming out of our T1 (the switch then router/firewall plugs into the switch, so this bypassed the router/firewall). Does the configuration differ?
|
|
|
|
Joined: Oct 2006
Posts: 101
Member
|
Member
Joined: Oct 2006
Posts: 101 |
We have the same setup here except we don't have any IP phones on the LAN. From our cable modem there is a switch with the IPRC and Firewall FVS318 like yours connected. The IPRC and Firewall have there own public IP address. This works fine for us but like I said our IP phones only connect through the public IP.
One concern I would have with the FVS318 is it's WAN port is only 10T. If you have much internet traffic you may have problems.
|
|
|
Forums84
Topics94,528
Posts640,024
Members49,852
|
Most Online5,661 May 23rd, 2018
|
|
1 members (BrianS),
210
guests, and
42
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
|
|