[cisco-voip] R: Nat skinny overload problem

[Nick Matthews]

To give some more details on why voice inspection on a firewall is a bad
idea:

-SCCP is a Cisco proprietary protocol.  This is good because Cisco can
change the protocol as they need, version by version.  This is bad for
firewalls because how many people consider keeping their firewall version up
to date with relationship to their phone firmware version - about as many as
you would expect.  There is a potential for even greater problems with 3rd
party firewalls which may not be as up to date with the SCCP protocol
version/messages.

-SIP isn't any better.  Some may lean on open standards, say it's well
understood, but that doesn't really hold up.  SIP is very flexible and
extensible, which means people can insert their own custom headers, add
their own body types, etc.  In a typical SIP message, you can't just do a
simple find-and-replace for your NAT IP addresses and ports.  One call agent
may include it's private address in the Call-ID header.  This header is not
IP dependent, but it's just an identifier.  If you NAT the IP in the Call-ID
header the other end will not know which session to refer to and it will
break the call.  But, in the From/Via headers you want to NAT the IP.  If I
create a Nick-SIP-NAT-Break header, there isn't a way for the firewall to
reliably know whether it should NAT that header or not unless it's familiar
with it.  You can also get into some implementation differences in how
different vendors use headers differently, some use the shortcut notation of
header definitions, some use optional parts of the header, and now the
firewall has to be cognizant of these differences.

-H.323 is arguably the most secure through a firewall.  It has a standard
associated to it, and should be more predictable.  We're seeing less of
H.323 as almost all new devices are SIP.  The one challenge with H.323 is
that the H.245 connection is a random-to-random port usage which firewalls
can struggle to keep up with.  Most up-to-date major firewalls should be
able to do this, but you see problems on the less-updated and niche
firewalls.

In short, just change the addresses.  It will save you time.
Troubleshooting a voice topology with a firewall is easy - start at the
firewall, because it's almost always the problem.

-nick

On Mon, Mar 28, 2011 at 10:41 AM, Mauro Celli <mauro.celli at 2000net.it>wrote:

> I have some overlapping phone network, i need NAT for some reason.
> This is my nat "ip nat inside source list 101 pool Voce"
> No overload is added but:
> rotary work for 2/3 week,after this time, some phone is overload ip
> Match-host is not applicable
> without rotary and match-host, all phone have same ip (the router apply
> pat)
> Ios tested 12.4 15.0 15.1
>
> Thanks
>
> -----Messaggio originale-----
> Da: Peter Slow [mailto:peter.slow at gmail.com]
> Inviato: domenica 27 marzo 2011 17:18
> A: Mauro Celli
> Cc: cisco-voip at puck.nether.net
> Oggetto: Re: [cisco-voip] Nat skinny overload problem
>
> The overload keyword is what causes it to do PAT instead of NAT. You
> do NOT have to put the "overload" keyword at the end of the ip nat
> inside source command. I'm not sure how skinny inspection works
> (because I've managed to avoid doing this, as it should be avoided and
> is poor design.) with IOS NAT/PAT, but you are going to need some form
> of Skinny inspection if you want dynamically assigned global IP
> addresses because the router needs to know what UDP ports to create a
> corresponding translation across the NAT boundary for.
>
> There is probably a solution here that we can help you come up with
> that will not need NAT/PAT. Tell us what your network architecture is
> like, and what you are trying to do. Perhaps we can help you come up
> with something that wont cause you heartache. ( for instance, if the
> NAT is due to overlapping address space, you can renumber the phones,
> that will be easier. If the NAT is because you are going across a
> public network, then as much as I hate the various forms of tunneling
> and VPNs, one of them may be for you and is probably a lesser evil
> than NAT.) There are even some other ways, such as forcing all your
> phones at thsi one site to send their RTP streams through an MTP with
> a Public IP address, thereby bypassing the need for the
> fixup/inspection. There are varying designs of that nature that use
> parts of CUBE or CUCM.
>
> Even if you manage to get this working now, skinny inspection/fixup
> breaks frequently, for a multitude of reasons.
>
> NAT/PAT really sucks for voice,
>   Peter
>
>
>
>
> On Sat, Mar 26, 2011 at 5:16 PM, Mauro Celli <mauro.celli at 2000net.it>
> wrote:
> > I need to make nat for some phones (15/20 phones) in 2 subnet
> >
> > Subnet1 172.20.10.0/24
> >
> > Subnet2 192.168.10.0/24
> >
> > Nat pool 1.0.1.21 1.0.1.149
> >
> > I need a mapping 1 to 1.
> >
> > I have try some config but:
> >
> >
> >
> > ip nat pool Voce 1.0.1.21 1.0.1.149 netmask 255.255.255.0
> >
> > This not work,all internal phones is natted with 1.0.1.21 (is always
> > overloaded???)
> >
> > ip nat pool Voce 1.0.1.21 1.0.1.149 netmask 255.255.255.0 match-host
> >
> > This is not applicable, because i have two internal subnet
> >
> > ip nat pool Voce 1.0.1.21 1.0.1.149 netmask 255.255.255.0 rotary
> >
> > This work,but after 2/3 week, i found two phone with same natted address.
> >
> >
> >
> > I need always a mapping 1->1 absolutely no overload is permette in my
> > config.
> >
> > How i can make this without making a manual
> >
> > ip nat inside source static x.x.x.x x.x.x.x for every phone?
> >
> > Thanks
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20110328/8913e084/attachment.html>