Best way to connect IPO to Internet?? 1

[TelNetSystems]

I have an IP Office 500v2 that is working great in the following configuration with voice services provided by a PRI.

DATA NETWORK (192.168.81.x) <-> COMPUTERS
|
- PIX FIREWALL <-> INTERNET (x.x.x.x/29)
|
VOICE NETWORK (192.168.82.x) <-> IP OFFICE LAN & LOCAL IP PHONES

This configuration is comfortable and familiar from a security standpoint since it isolates the IPO from the internet behind a packet inspection firewall and NAT. However, now I need to modify this system to add SIP trunks and remote IP phones.

What is the best way to modify this configuration to facilitate SIP trunks and Internet based IP phones?
[ul][li]Leave IPO-LAN alone and configure NAT traversal and firewall rules on the PIX?[/li]
[li]Move IPO-LAN to a DMZ using a public IP behind the PIX firewall?[/li]
[li]Leave IPO-LAN alone and connect IPO-WAN directly to the Internet using a public IP and no external firewall?[/li][/ul]

From what I have read, it seems NAT traversal is generally avoided for VoIP where possible, which makes me lean toward the second two options. However, I don't know if the IP Office WAN port is secure enough to directly connect to the Internet and/or if I would have to completely neuter the PIX firewall anyway to allow unobstructed VoIP traffic. I'm hoping some of you have done this enough to know which way is the best/standard practice in this situation.

Thanks,

David

 

[amriddle01]

•Leave IPO-LAN alone and configure NAT traversal and firewall rules on the PIX? - YES

•Move IPO-LAN to a DMZ using a public IP behind the PIX firewall? - NO

•Leave IPO-LAN alone and connect IPO-WAN directly to the Internet using a public IP and no external firewall? - HELL NO




"No problem monkey socks

 

[TelNetSystems]

Okay, so you share my concern about connecting the IPO WAN port straight to the Internet. If you don't mind me picking your brain a little more, what makes you prefer NAT + Firewall to A private IP over a public IP in a DMZ behind the firewall? Do you think the NAT adds meaningful additional security to the IPO over the firewall alone or do you have another reason for that preference?

This may be too technical, but a Cisco document seems to indicate this is pretty much all that would be required:

fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
access-list 101 permit tcp any host x.x.x.x eq 5060
access-list 101 permit tcp any host x.x.x.x eq h232
static (inside outside) x.x.x.x 192.168.82.2 netmask 255.255.255.255 0 0
access-group 101 in interface outside
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

Does that look about right?

 

[IPGuru]

Additional suggestions

Remote Phones, Use a VPN Avaya's Nat traversal is problematic & does not work with all ISP's

SIP Trunks, either use a SBC or correctly configure the Lan topology settings is system config.

to re-iterate Amriddle, Never connect the IPO directly to the internet!



A Maintenance contract is essential, not a Luxury.
Do things on the cheap & it will cost you dear

 

[amriddle01]

Usually it's best to remove the fixups within the Cisco, they tend to break SIP and H323 traffic completely. SIP traverses NAT just fine with a decent provider. Remote phones aren't supported with the system on a public IP, that being said they tend not to work very well anyway especially through a Cisco...just setting your expectations to the correct level before you start



"No problem monkey socks

 

[tlpeter]

I tried a NoUser source number which changes the port and should work on a Cisco for remote phones.

REMOTE_H323=1800

No reboot required.

BAZINGA!

I'm not insane, my mother had me tested!

 

[hairlessupportmonkey]

I would set that to "no fixup"

ACSS - SME
General Geek

 

[biv343]

•Leave IPO-LAN alone and connect IPO-WAN directly to the Internet using a public IP and no external firewall? - HELL NO"

I went to work on a system for a new customer a couple months back and their system was set up exactly this way. The previous vendor used that for their remote access. Default passwords and everything.

It isn't that way any longer.

 

[amriddle01]

Clearly they have never heard of port forwarding or specific IP routes



"No problem monkey socks

 

[TelNetSystems]

Thank you all for being so helpful and for such rapid responses. I'll take a shot at it this evening or tomorrow morning. Based on the feedback so far I'm planning to start simple and try this (along with verifying QoS is configured):

no fixup
access-list 101 permit ip any host x.x.x.x eq sip
static (inside outside) x.x.x.x 192.168.82.2 netmask 255.255.255.255 0 0
access-group 101 in interface outside
timeout sip 0:30:00 sip_media 0:02:00

This should turn off SIP "helping" by the PIX, establish a 1:1 NAT from a public IP to the IPO private IP, tell the firewall to allow sip inbound to the IPO, and add some sip related timeouts I see often in Cisco's sample configurations. From there I'll add my SIP trunk and try testing some calls.

Now on to: "Remote Phones, Use a VPN Avaya's Nat traversal is problematic & does not work with all ISP's" and "Remote phones aren't supported with the system on a public IP, that being said they tend not to work very well anyway". Okay, so remote phones should travel over a VPN tunnel rather than directly to the IPO's public IP. From my research I think I have learned that telephone VPN tunnels will need to terminate on the firewall, recent software releases support VPN directly to the IPO, the new IPO VPN termination capability only applies to an Avaya remote support solution, and neither the PIX nor the Avaya VPN telephones support SSL VPNs (upgrading the PIX to an ASA is very possible if the SSL VPN capability is significant). Assuming all that is correct, I believe supporting remote telephones would require these steps:
[ol 1][li]Buy a compatible Avaya IP telephone with VPN capability.[/li]
[li]Buy an Avaya IP Endpoint license for our IP500v2 R8.1 Essential Edition.[/li]
[li]Get the IP telephone working properly on the local voice LAN.[/li]
[li]Configure an IPSEC/L2TP VPN tunnel from the telephone to the firewall.[/li][/ol]

I'm feeling much more confident about being on the right track and not at risk of setting up a stupid configuration out of ignorance. Interestingly, with VPNs connecting remote telephones to the IPO, and the IPO protected behind NAT and a SPI firewall, the unencrypted SIP trunk to the VoIP service provider is starting to look less than secure in comparison. I assume that is just the nature of SIP trunking at this point, or are encrypted SIP trunks common and I just don't know about it?

 

[amriddle01]

Don't forget you can make the IP Office only respond to a single IP or small range of IP's by using IP routes carefully, so therefor it would only respond to to the SIP trunk provider and no others from external/public addresses



"No problem monkey socks

 

[TelNetSystems]

True, I can configure the IPO and/or the firewall to allow non-VPN internet traffic only to/from the IP blocks of our SIP trunk provider to protect the IPO... I was actually thinking more along the lines of privacy... sip calls being vulnerable to evesdropping, trunking provider userIDs and passwords sent in the clear, and that sort of thing.

 

[amriddle01]

Most trunk providers use trusted IPs now as oppose to registration (though registration has its benefits), but yes calls are subject to eavesdropping, however that is harder to accomplish on SIP than it is on analogue lines or ISDN, should someone be motivated to do so



"No problem monkey socks

 

[TelNetSystems]

Well, I installed the license, set up an account with Callcentric to use for testing, configured the firewall, and configured the SIP line...

It mostly works.

Immediately after the IPO reboots the SIP trunk registers and both inbound and outbound calling works. After several minutes I can still make outbound calls, but I can't call inbound and the SIP trunk status shows as unregistered.

I suspect I need to either lengthen some timeouts on the PIX or open more inbound ports that just 5060.

 

[amriddle01]

It will be a timeout



"No problem monkey socks