Cisco ASA 8.2 to 9.x :: migrando :: parte 2

En esta ocasión, me toca migrar tema NAT.

Supongamos que tenemos nuestra red local 192.168.2.0/24 y un rango de ip’s públicas, por ejemplo 1.1.1.0/29.

Lo más lógico, es NATear 1:1, es decir, una ip privada de la red, contra una ip pública y permitir / denegar tráfico mediante ACL….. por defecto, está todo cerrado excepto, lo que nosotros permitimos…

configuración en asa 8.2.5… ip privada 192.168.2.2, nateada contra la pública 1.1.1.2 y permitimos 25 y 443 tcp.


static (inside,outside) 1.1.1.2 192.168.2.2 netmask 255.255.255.255

access-list outside_in permit tcp any host 1.1.1.2 eq 25
access-list outside_in permit tcp any host 1.1.1.2 eq 443

access-group outside_in in interface outside

Ahora toca migrar la config a versión 9.x:

object network poseidon
host 192.168.2.2
nat (inside,outside) static 172.26.2.2

access-list outside_in extended permit tcp any object poseidon eq 443
access-list outside_in extended permit tcp any object poseidon eq 25
access-group outside_in in interface outside

Primero toca definir el objeto, aplicamos la regla al object y finalmente, el grupo de reglas al interface que toca.

Policy Based Routing Cisco y Mikrotik, tunnel IPIP y NAT (3)

Ahora, vamos a NATear las ip’s de nuestro proveedor a las máquinas de la red local.

Quiero que mi servidor Debian, con la 192.168.2.1, tenga como ip pública la 1.1.1.4. Para ello, usaremos 2 reglas en nuestra mikrotik; una src-nat y otra dst-nat, usando como interface público el tunnel PPTP:


/ip firewall nat
add action=src-nat chain=srcnat disabled=no out-interface=pptp_provider
src-address=192.168.2.1 to-addresses=1.1.1.4
add action=dst-nat chain=dstnat disabled=no dst-address=1.1.1.4
in-interface=pptp_provider to-addresses=192.168.2.1
add action=masquerade chain=srcnat disabled=no out-interface=pptp_provider
add action=masquerade chain=srcnat disabled=no out-interface=outside

Y recordamos que tenemos que tener una entrada de masquerade para el tunnel pptp y que estas reglas deben de estar antes.

La primera es para indicar que los paquetes entrantes desde internet, que vengan por el tunnel pptp (de entrada), a la ip pública 1.1.1.4, lo traduzca a la 192.168.2.1 de nuestra red.

La segunda regla, es para indicar que, la salida de nuestra máquina 192.168.2.1, la NATee directamente a la 1.1.1.4, por el interface pptp_provider.

Policy Based Routing Cisco y Mikrotik, tunnel IPIP y NAT (1)

Esta entrada, con diferencia, es una de las configuraciones que más me ha hecho sudar la gota gorda…. intervienen varios factores:

1º) Tengo un proveedor de servicio que me proporciona 8 ip’s públicas
2º) Tengo que llegar con mi conexión al proveedor
3º) Hago un tunel IPIP entre la Mikrotik y mi router cisco
4º) Hay que usar nat

El motivo es que, necesito usar esas 8 ip’s y sólo determinados equipos, saldrán por el tunnel IP / ip’s públicas; el resto de máquinas de mi casa, saldrá por la conexión normal que tengo.

Primero de todo, haré la config y el esquema con cisco como cliente y mikrotik como servidor:
ipip1

Empezamos por la configuración de la mikrotik:

/interface ipip
add disabled=no dscp=0 local-address=3.3.3.3 mtu=1480 name=ipip_craem remote-address=2.2.2.2
/ip address
add address=192.168.194.1/30 disabled=no interface=ipip_craem network=192.168.194.0

add disabled=no distance=1 dst-address=1.1.1.1/32 gateway=192.168.194.2 scope=30 target-scope=10
add disabled=no distance=1 dst-address=1.1.1.2/32 gateway=192.168.194.2 scope=30 target-scope=10
add disabled=no distance=1 dst-address=1.1.1.3/32 gateway=192.168.194.2 scope=30 target-scope=10
add disabled=no distance=1 dst-address=1.1.1.4/32 gateway=192.168.194.2 scope=30 target-scope=10
add disabled=no distance=1 dst-address=1.1.1.5/32 gateway=192.168.194.2 scope=30 target-scope=10
add disabled=no distance=1 dst-address=1.1.1.6/32 gateway=192.168.194.2 scope=30 target-scope=10

Primero creamos el tunnel, le damos la ip y, para no perder la de red y broadcast, negociamos con el proveedor que nos la enrute una a una, tras pagarle unas cervezas al técnico 😉

Y ahora el lado Cisco; empezamos por el tunnel:

interface Tunnel7
description TUNNEL proveedor /29
ip address 192.168.194.2 255.255.255.252 --> ip privada del tunnel
ip mtu 1480 --> ajustamos el mtu
ip nat outside --> mis máquinas están detrás del firewall, con NAT
ip virtual-reassembly
ip policy route-map prov_lan --> policy route aplicado
qos pre-classify --> aplico QoS antes de meter en el tunnel
tunnel source 2.2.2.2 --> ip pública mia
tunnel destination 3.3.3.3 --> ip destino
tunnel mode ipip --> modo del tunnel

Creamos la política:

ip local policy route-map prov_map

Metemos en un access-list las ip’s que tendrán salida por el tunnel:

access-list 112 remark -> ACL NAT prov IPS PUBLICAS
access-list 112 permit ip host 172.26.2.9 any
access-list 112 permit ip host 172.26.2.11 any
access-list 112 permit ip host 172.26.2.5 any
access-list 112 permit ip host 172.26.2.6 any
access-list 112 permit ip host 172.26.2.12 any

Hacemos el route-map para identificar los paquetes:

route-map prov_lan permit 10
match ip address 112
set interface Tunnel7

Y ahora, nacemos el nat de las privadas a las públicas de nuestro proveedor:

ip nat inside source static 172.26.2.9 1.1.1.1
ip nat inside source static 172.26.2.11 1.1.1.2
ip nat inside source static 172.26.2.5 1.1.1.3
ip nat inside source static 172.26.2.6 1.1.1.4
ip nat inside source static 172.26.2.12 1.1.1.5

Si no ponemos el nat en el tunnel; no habrá traducción y no podremos usar las ip’s.

Ahora hemos de aplicar el policy-map a los interfaces:

interface FastEthernet0/0
bandwidth 6096
ip address dhcp
ip flow ingress
ip nat outside
ip virtual-reassembly
ip policy route-map rlan_map

interface GigabitEthernet0/1/0
ip address 172.26.2.20 255.255.255.0
ip flow ingress
ip nat inside
ip virtual-reassembly
ip policy route-map rlan_map
negotiation auto

NATear rango de puertos en un router cisco

Como ya sabréis, para hacer NAT por puertos en un router cisco, hay que añadir una línea por cada uno de ellos, del tipo:

ip nat inside source static tcp 192.168.2.3 8080 X.X.X.X 8080 route-map nonat extendable

Aquí estamos NATeando el puerto 8080 a la máquina 192.168.2.3 de nuestra red, donde X.X.X.X es la ip pública nuestra.

Pero el problema es, si queremos NATear un rango entero de puertos…. por ejemplo…. publicamos nuestro servidor de VoIP y necesitamos del 10000 al 20000 UDP para el media y el 5060 UDP para el signaling.

La pesadilla puede ser tremenda…. aunque no es necesario para la voIP los 10000 puertos, pero hacer un rango de 10 o 20, es poco elegante, más si nuestro router ya tiene más nats hechos, con lo que la config se puede volver muuuuy larga.

hace unos días, leyendo documentación de cisco por otros temas, veo el NAT ROTARY, siendo la definición de cisco:

Destination Address Rotary Translation
A dynamic form of destination translation can be configured for some outside-to-inside traffic. Once a mapping is set up, a destination address matching one of those on an access list will be replaced with an address from a rotary pool. Allocation is done in a round-robin basis, performed only when a new connection is opened from the outside to the inside. All non-TCP traffic is passed untranslated (unless other translations are in effect).

Y vemos la palabra mágica:

Destination address matching one of those on an access list

Vamos a investigar un poco:

Primero, hacemos el access-list para los puertos de nuestro VoIP server:

ip access-list extended voip
permit udp any any eq 5060
permit udp any any range 10000 20000

Y ahora el nat con el access-list, contra la ip 192.168.2.5, que será nuestro VoIP Server:

ip nat pool ASTERISK 192.168.2.5 192.168.2.5 netmask 255.255.255.0 type rotary

Finalmente, la destinación del NAT con la ACL:

ip nat inside destination list voip pool ASTERISK

Y ahora, enjoy the nat!!!, hasta que llegue el IPv6.

cisco 87x PPPoE II Parte

Desde el cambio, por parte de telefónica,  al protocolo pppoe en todas sus líneas, he tenido algún que otro inconveniente con los routers cisco. En varias ocasiones me ha pasado que colocaba el cisco 18xx o el  87x y los pc’s de la red no navegan, aunque tengan salida a internet.

Revisando los log’s y googleando un poco, encontré un parámetro que arregla ésto:

Interface Dialer 1

…..

ip tcp adjust-mss 1452
….

Recientemente, en un cisco 1841 con pppoE contra un teldat de telefónica, configurado sin nat, he tenido que ir probando valores hasta ver que no se fragmentaban paquetes….. será de tu ayuda en los routers cisco el comando “amigo” debug tcp..