Monthly Archives: March 2012

Configuring Dynamic Policy PAT on ASA: current and legacy models

This post builds upon the previous discussions on the ASA NAT series to exemplify yet another category of address translation: Dynamic Policy PAT. In this type of scenario, a set of source addresses get mapped into a single global address when they need to reach specific destinations.

In our reference topology, those dmz stations belonging to the 10.10.10.128/27 subnet are port address translated to 172.16.16.125/32 when the destination is the out host 172.16.16.200. For different out hosts, the source IPs are not translated. Some important points to highlight:

  • It is important to observe that we are not translating the destination address. We are just using the destination criteria to influence translation of the source addresses.
  • In the pre-8.3 CLI the number “1” is the NAT_ID, which creates the relationship between the nat and global commands.
  • The original syntax (pre-8.3) employs an Access Control List (ACL) in conjunction with the nat command to insert the destination-based rule.
  • In the new model introduced by release 8.3, we use manual NAT to create any rules that concurrently involve source and destination. This is the case for Policy NAT, Policy PAT and Dual NAT. Unless you use the after-auto argument in the nat command, manual translations are inserted in Section 1 of the Unified NAT Table.

Dynamic Policy PAT on ASA

** Notes:

  • As in the basic PAT case (which does not take destination addresses into account), ASA combines the global address (172. 16.16.125 in this case) with a source port to correctly identify each internal host and deliver the return packets accordingly.
  • Manual NAT allows you to add a sequence number to each manual nat statement, so that you can directly control the order of processing of the translation rules (irrespectively of the NAT category in place). This is a major difference when comparing to releases up to 8.2, for which you needed to know the intrinsic NAT precedence rules.

** Topics for Study:

** Related Posts:

Advertisements

Leave a comment

Filed under English, Firewalls, Security

Dynamic NAT on ASA: before and after release 8.3

[“All appeared new, and strange at first, inexpressibly rare and delightful and beautiful. I was a little stranger, which at my entrance into the world was saluted and surrounded with innumerable joys.” – Thomas Traherne]

After reading the article “NAT Evolution within Cisco ASA software” and applying that knowledge to build static translations on ASA, it is now time to implement dynamic rules. As we did before, to make life easier on migration tasks, the two configuration modes (pre and post-8.3) are presented.

The figure below brings not only the old-style syntax but also the new options for a simple topology, in which the internal addresses belonging to the 10.10.10.128/25 subnet are translated to the range 172.16.16.129-172.16.16.254. In this arrangement, some facts deserve special mention:

  • In the legacy CLI the number “2” is the NAT_ID, which is used to establish the link between the nat and global commands.
  • For source-only translations, the nat statement (configured under the network object definition) automatically places the rule in Section 2 of the Unified NAT Table.
  • Given that manual NAT allows the creation of rules that simultaneously specify translation of source and destination addresses, manual NAT can be “simplified” to create source-only (or destination-only) rules. In this case the rule will be part of Section 1 and there will be no reference to network object. Considering that the sections in the NAT table are sequentially processed, the equivalent construction with manual NAT takes precedence over Object NAT. (The exception is when you employ the after-auto parameter in the nat command, thus sending the manual rule to Section 3).

Dynamic NAT on Cisco ASA

** Topics for Study:

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

Voz sobre IP, Telefonia IP e Colaboração

O transporte de voz sobre uma rede de dados que se apóia no IP como protocolo de camada 3 é uma alternativa para o sistema de comutação de circuitos, tradicionalmente empregado pelas companhias telefônicas. Considerando que grande parte das empresas já realizaram investimentos significativos na criação de uma infraestrutura para comunicação de dados baseada em IP e lembrando que o custo mensal das linhas de dados é (na maioria dos casos) fixo, torna-se bastante intuitivo perceber que se conseguirmos efetuar o transporte de voz sobre tal estrutura poderemos ter uma redução expressiva nos gastos com contas telefônicas e com manutenção.

Em um mundo onde a Internet ganha mais e mais relevância no que se refere à realização de negócios e aumento de produtividade e que, inclusive por isso, vem promovendo a onipresença do protocolo IP, tal perspectiva de economia com custos de operação (cada vez mais importante para manutenção da competitividade das empresas) se mostra suficientemente convidativa para que dediquemos atenção às tecnologias de Voz sobre IP e Telefonia IP.

Cumpre salientar, no entanto, que a possibilidade de tornar real o sonho de integração das redes de voz e dados em uma plataforma multisserviços está condicionada ao fato de que se atendam algumas exigências específicas do tráfego de voz. Sendo respeitadas as restrições intrínsecas a este, como, por exemplo, a necessidade de redução dos atrasos de propagação e manipulação, a uniformização dos atrasos e a reserva de uma largura de banda, pode-se obter qualidade praticamente indiferenciável daquela a que estamos habituados no processo convencional de transporte. Interessante ainda é notar que enquanto no “velho mundo” das comunicações se exigia uma banda de 64 Kbps para um canal de voz, a nova abordagem permite o uso de cerca 16 Kbps por canal, fato este que já traz em si uma exemplificação da eficiência que pode ser obtida ao se transportar voz sobre uma rede IP.

O tratamento dado pela Cisco às soluções de VoIP e Telefonia IP faz parte de um conjunto mais amplo de recomendações que visa promover a convergência dos tráfegos de dados, voz e vídeo em uma infraestrutura de rede única e desta forma contribuir para materializar o conceito de Colaboração.

Para um melhor entendimento deste ( e de outros textos correlatos) vamos começar por definir alguns termos:

  • Voice over IP (VoIP): ao utilizar a denominação Voz sobre IP, ou resumidamente VoIP, estamos nos referindo à solução conhecida como toll-bypass, em que centrais telefônicas convencionais podem ser conectadas através da rede IP, o que se torna particularmente atrativo sob o ponto de vista econômico para ligações do tipo DDD e DDI. Para este cenário faz-se necessária a adição de placas de voz aos roteadores existentes. Note-se aqui que a voz é simplesmente transportada sobre a rede IP e que as tarefas de codificação e compressão da voz são executadas pelos roteadores com placa de voz, que neste ambiente operam como gateways entre o mundo da telefonia tradicional, representado pelos PABXs, e o mundo IP, associado aos roteadores.
  • IP Telephony (IPT): quando falamos em Telefonia IP, estamos nos referindo à implementação dos já bastante difundidos serviços e funcionalidades da telefonia tradicional, com a diferença primordial de que todo o tráfego de controle, assim como a voz propriamente dita, são transportados através de uma infraestrutura de comunicação baseada em IP. Neste novo teatro passam a figurar como atores principais os Call Managers , responsáveis pelas tarefas de processamento de chamadas, e os telefones IP (IP Phones), que se apresentam como a principal interface do usuário com a rede convergente.
  • Colaboração IP: Arquitetura centrada em viabilizar a interação entre pessoas ( e assim contribuir para o compartilhamento de informações e experiências) através de aplicações tais como webex, Cisco Jabber e Telepresença. O uso de Telefonia IP é um passo natural no caminho para a Colaboração IP.

A Figura 1 traz uma comparação visual entre os serviços VoIP e Telefonia IP.

Com base no que aqui foi exposto, podemos concluir que as soluções de Telefonia IP e VoIP são complementares e, numa análise mais cuidadosa, que a implementação de VoIP é um caminho natural de migração da telefonia tradicional para aquela baseada em IP. Isto porque os roteadores com placas de voz empregados no cenário de toll-bypass podem ser utilizados para conexão direta à PSTN no momento em que se promover a eliminação do PABX de uma dada localidade. Tal situação pode ser visualizada na Figura 2, que ilustra a coexistência das soluções de VoIP e Telefonia IP.

Figura 2: Coexistência entre VoIP e Telefonia IP

** Notas:

  1. Promovendo-se uma analogia simples com o modelo de telefonia tradicional, poder-se-á facilmente associar as funções essenciais do Call Manager àquelas do PABX convencional, devendo-se ressaltar, no entanto, que ao deslocar o plano operacional de um sistema proprietário para uma estrutura de comunicação baseada no protocolo universal IP, ganha-se notável flexibilidade. E isto de imediato se traduz na possibilidade de implementação de um número virtualmente infinito de serviços adicionais. (Afinal, a telefonia passou a ser mais uma aplicação IP…)
  2. É vital destacar que o tráfego de voz gerado pelos telefones IP é “nativamente IP”, o que equivale a dizer que após passar pelos processos iniciais de codificação e compressão (internamente aos telefones), a voz é encapsulada em datagramas IP para que possa ser então transportada através da rede.

** Artigos Relacionados:

** Para saber mais sobre o conceito de Colaboração:

http://www.cisco.com/go/collaboration

3 Comments

Filed under Português, Redes