List of WLAN (Wireless Local Area Network) channels using IEEE 802.11 protocols.

802.11 b/g/n (2.4 GHz band)

• Channel Frequency (MHz)  -  (F - 10)  -  Center  - (F + 10)
• 
  
• 1 2402 2412 2422
• 2 2407 2417 2427
• 3 2412 2422 2432
• 4 2417 2427 2437
• 5 2422 2432 2442
• 6 2427 2437 2447
• 7 2432 2442 2452
• 8 2437 2447 2457
• 9 2442 2452 2462
• 10 2447 2457 2467
• 11 2452 2462 2472
• 12 2457 2467 2477
• 13 2462 2472 2482
• 14 2474 2484 2494 Japan

Transmission can be on a 22MHz (802.11b), 20MHz (802.11g/n), or 40MHz (802.11n) wide channel.

802.11 a/n (5 GHz band)

• Channel Frequency (MHz)  -  (F - 10)  -  Center  -  (F + 10)
• 
  
• 36 5170 5180 5190
• 40 5190 5200 5210
• 44 5210 5220 5230
• 48 5230 5240 5250
• 52 5250 5260 5270
• 56 5270 5280 5290
• 60 5290 5300 5310
• 64 5310 5320 5330
• 100 5490 5500 5510
• 104 5510 5520 5530
• 108 5530 5540 5550
• 112 5550 5560 5570
• 116 5570 5580 5590
• 120 5590 5600 5610
• 124 5610 5620 5630
• 128 5630 5640 5650
• 132 5650 5660 5670
• 136 5670 5680 5690
• 140 5690 5700 5710
• 144 5710 5720 5730
• 149 5735 5745 5755
• 153 5755 5765 5775
• 157 5775 5785 5795
• 161 5795 5805 5815
• 165 5815 5825 5835

Transmission can be on a 20 or 40MHz (802.11a/n), or 80 MHz (802.11ac) wide channel.

Graphics:

Firewall FILTER

En un firewall tenemos 3 chains o cadenas: Input (tráfico con destino el propio router), Forward (tráfico que atraviesa el router, como el que originan los dispostivos de tu LAN), Output (tráfico con origen el propio router). El firewall por defecto da de alta las siguientes reglas (cada una de las que ves con la palabra "add" delante).

Chain Input (destino el router)

Código:

add action=accept chain=input comment=\

    "defconf: accept established,related,untracked" connection-state=\

    established,related,untracked

Aceptas toda conexión previamente establecida, con destino el router.

Código:

add action=drop chain=input comment="defconf: drop invalid" connection-state=\

    invalid

Rechazas toda conexión con estado "inválido".

Código:

add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp

Aceptas que puedas hacerle un ping a tu IP pública. Si esta regla la quitas, verás que dejas de poder hacer ping a tu IP pública desde internet.

Código:

add action=accept chain=input comment=\

    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1

Aceptas peticiones del propio router para haciendo de CAPsMAN. Esta regla es solo necesaria cuando tienes un router+AP (router con wifi) y quieres montar CAPsMAN en ese mismo equipo, manejando su propia red inalámbrica vía esa herramienta. En ese caso particular, la petición de control de CAPsMAN vendrá de la IP de loopback, la 127.0.0.1. Si tu equipo no tiene wifi, esa regla la puedes eliminar directamente, no la necesitas.

Código:

add action=drop chain=input comment="defconf: drop all not coming from LAN" \

    in-interface-list=!LAN

La regla más importante del chain de input. Impide que nada que no sea un elemento de tu lista LAN (¿ves como usamos las listas, en lugar de las interfaces?) acceda al propio equipo. Esa regla impide, por ejemplo, que alguien desde internet pueda acceder a tu equipo si sabe tu IP pública y tiene winbox instalado.

Chain de Forward (origen/destino la LAN, tráfico que atraviesa el router)

Código:

add action=accept chain=forward comment="defconf: accept in ipsec policy" \

    ipsec-policy=in,ipsec

add action=accept chain=forward comment="defconf: accept out ipsec policy" \

    ipsec-policy=out,ipsec

Dos reglas muy similares. Aceptan que los elementos LAN y el exterior se puedan comunicar con una policy de IPSec. Esto lo vas a usar cuando montes una VPN en el router, y quieras que el tráfico encriptado entre y salga del equipo, tal y como lo hace el tráfico LAN. Una regla acepta el tráfico encriptado en sentido de entrada (in,ipsec) y el otro en salida (out,ipsec). No las toques, son muy útiles, aunque no las necesitas si no montas una VPN.

Código:

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \

    connection-state=established,related

Esa regla hace magia, y podríamos estar mucho tiempo hablando de ella. Básicamente lo que hace es saltarse el flujo de paquetes que seguiría cualquier paquete en el chain de forward, para toda conexión ya activa. Es decir, el primer paquete que pase por ahí no entrará en esa regla, y entrará en la siguiente, pasando por todo el flujo. Pero todos los demás relativos a esa conexión, irán por la vía rápida, saltándose del tirón ese flujo. Esta regla es incompatible con la gestión avanzada del tráfico (QoS, las famosas colas de prioridad y el mangle), y tendrías que desactivarla en caso de querer usar políticas de gestión de tráfico. Sin embargo, consiguen aumentar el rendimiento de un equipo una barbaridad. En tu caso no lo vas a notar, porque tienes una bestia parda de router, pero en el caso de un router de 50€ como puede ser un hEX, es la diferencia entre coger 400-500 Mbps y que el equipo se vaya a manejar 900 y pico megabits por segundo (a todo lo que dan los puertos gigabit). Trátala con mucho cariño y mantenla en tu configuración todo el tiempo que puedas. Yo la tengo quitada porque uso balanco de carga PCC y colas; y si quiero usar mangle para marcar el tráfico, no me queda otra que quitarla. El día que tengas que quitarla, simplemente desactívala con el aspa roja y reinicia el router. Verás que un par de reglas dinámicas que tenías tanto a nivel de filter como en mangle desparecen (descuida, que se vuelven a generar cuando la habilitas y reinicias).

Código:

add action=accept chain=forward comment=\

    "defconf: accept established,related, untracked" connection-state=\

    established,related,untracked

Igual que lo anterior, para el tráfico que aún no haya sido marcado como fasttrack (primeros paquetes de una conexión). Como ves no se acepta el estado "new", lo cual quiere decir que nadie desde fuera (internet) puede originar una conexión a un elemento de tu LAN. Las conexiones siempre se originan de dentro a fuera, salvo en un caso muy particular (última regla, ahora hablaremos de ella).

Código:

add action=drop chain=forward comment="defconf: drop invalid" \

    connection-state=invalid

Al igual que en input, paquetes marcados como inválidos, los rechazamos.

Código:

add action=drop chain=forward comment=\

    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \

    connection-state=new in-interface-list=WAN

Esta es la excepción que confirma la regla. Sólo vamos a aceptar nuevas conexiones que vienen del exterior a nuestra LAN, si dicho tráfico está explicitamente declarado en el NAT. ¿Cuando se da esto? Muy sencillo: cuando abrimos un puerto. En ese caso, esa regla se encargaría de aceptar dicha conexión, dejando pasar ese tráfico en particular, y ningun otro. La regla literalmente dice: toda nueva conexión que venga de internet y no esté explicitamente declarada en el NAT, la rechazas. Otra regla muy importante y que no debes borrar nunca.

Firewall NAT

Aquí es donde cambiamos IPs públicas por privadas y viceversa. Trabajas con dos chains, muy parecido al firewall: srcnat (tráfico con origen la red nateada) y dstnat (tráfico con destino la red nateada). Las reglas de nateo para cambiar tu ip privada por tu ip pública irían en el srcnat, y la apertura de puertos en el dstnat.

Código:

/ip firewall nat

add action=masquerade chain=srcnat comment="defconf: masquerade" \

    ipsec-policy=out,none out-interface-list=WAN

Como tienes una IP pública dinámica, no puedes usar una regla de src-nat directamente para cambiar unas por otras (si la tuvieras y fuera estática, esa regla sería incuso más simple), así que tienes que tirar de un "truco" para salir a internet: usar un sub-grupo dentro del src-nat: el masquerade. Esta regla enmascara todo tráfico saliente no encriptado que acabe saliendo por cualquier interfaz dentro de tu lista WAN. De esa manera tan elegante, resuelves el problema de no tener una IP pública estática.

Si la tuvieras, tu regla sería algo así (siendo 1.2.3.4 tu IP pública)

Código:

add action=accept chain=srcnat comment="nateo-lan-to-wan" \

    ipsec-policy=out,none src-address=192.168.55.0/24 dst-address=1.2.3.4

Vamos a utilizar un router Mikrotik para enlazar con nuestro router principal Mikrotik desde el exterior.

Reseteamos el equipo para arrancar sin configuración (System -> Reset -> No default configuration), ya que esto va a ser un router tonto.

Nos tocará entrar por Winbox al equipo, puesto que necesitaremos acceder vía MAC address.

Le cambiamos la password al usuario de admin en System -> Users. O, mejor aún, creamos uno nuevo con permisos "full" y borramos el de admin.

Establecemos ether3 como puerto para conectarnos por IP mediante Winbox y administrarlo.

La conexión a internet la podremos hacer tanto por cable (ether1) como por wifi (wlan1).

/interface list add name=WAN

/interface list member add interface=ether1 list=WAN

/interface list member add interface=wlan1 list=WAN

/interface detect-internet set detect-interface-list=WAN

/interface bridge add name=bridge1

/ip address add address=192.168.99.1/24 interface=ether3 network=192.168.99.0

/ip pool add name=pool-mgmnt ranges=192.168.99.2-192.168.99.5

/ip dhcp-server network add address=192.168.99.0/24 dns-none=yes gateway=192.168.99.1

/ip dhcp-server add address-pool=pool-mgmnt interface=ether3 name=dhcp-mgmnt

/ip dns set servers=1.1.1.1,1.0.0.1

Y nos conectamos con la interfaz física wlan1 en modo station (cliente) a la red de marras.

Lo más sencillo para esto es usar el botón "Scan" que tenéis en la pestaña de WiFi Interfaces.

Escaneáis las redes, seleccionáis la que sea y le dais a conectar.

Podéis comprobar si hay conexión haciendo un ping mediante terminal a ping google.com.

Ahora levantamos el tunel EoIP y añadimos al bridge los puertos que queramos más el tunel EoIP.

Y añadimos el cliente dhcp sobre el bridge.

/ip cloud set ddns-enabled=yes

/interface eoip

add allow-fast-path=no disabled=yes ipsec-secret=MyPasswordIpsec !keepalive mtu=1500 name=eoip-tunnel-to-RouterA remote-address=serial.sn.mynetname.net tunnel-id=1

/interface bridge port add bridge=bridge1 interface=eoip-tunnel-to-RouterA

/interface bridge port add bridge=bridge1 interface=ether2

/ip dhcp-client add interface=bridge1 add-default-route=no

Os voy a mostrar como abrir puertos en nuestro router Mikrotik utilizando la terminal para introducir las órdenes.

Y que mejor que unos ejemplos prácticos.

Vamos a abrir el puerto 6655 (tcp) para nuestro pc con ip 192.168.1.60 que utilizaremos con el programa qBittorrrent.

También vamos a abrir los puertos 4662(tpc) y 4672(udp) para nuestro pc con ip 192.168.1.60 que utilizaremos con el programa eMule.

Cómo veis sólo tenéis que cambiar la ip de vuestra máquina, el número de puerto, el protocolo y un comentario si queréis.

/ip firewall nat

add action=dst-nat chain=dstnat comment=Qbittorrent dst-port=6655 protocol=\

    tcp to-addresses=192.168.1.60 to-ports=6655

add action=dst-nat chain=dstnat comment=Emule_TCP dst-port=4662 protocol=tcp \

    to-addresses=192.168.1.60 to-ports=4662

add action=dst-nat chain=dstnat comment=Emule_UDP dst-port=4672 protocol=udp \

    to-addresses=192.168.1.60 to-ports=4672

/tool bandwidth-test address=23.162.144.120 user=btest password=btest duration=25s direction=both

 

Resultado:

 

 

 

/tool bandwidth-test address=23.162.144.120 user=btest password=btest duration=25s direction=both

status: done testing

duration: 25s

tx-current: 322.1Mbps

tx-10-second-average: 321.9Mbps

tx-total-average: 301.2Mbps

rx-current: 317.1Mbps

rx-10-second-average: 317.0Mbps

rx-total-average: 315.8Mbps

lost-packets: 2750

random-data: no

direction: both

tx-size: 1492

rx-size: 1492

connection-count: 20

local-cpu-load: 56%

remote-cpu-load: 34%

Filtrar web maliciosas a parte de tus equipos usando filtrado DNS

Para cuando tenemos peques en la casa o simplemente queremos que se filtren las peticiones DNS a parte de nuestra red, podemos redirigir las peticiones DNS a un servidor público con filtrado, evitando así que los más peques de la casa accedan a contenido indeseado.

Código:

# Creamos una lista de IP's a las que se les va a aplicar el bloqueo

/ip firewall address-list

add address=192.168.1.151-192.168.1.254 list="Bloquear XXX"

#Redirigimos las peticiones DNS al DNS de Norton ConnectSafe

/ip firewall nat

add action=dst-nat chain=dstnat comment=\

"Redireccionar DNS a Norton Connectsafe" dst-port=53 protocol=udp \

src-address-list="Bloquear XXX" to-addresses=199.85.126.30 to-ports=53

Si queremos aplicarlo a toda la red, lo más sencillo es utilizar como servidor uptream de DNS uno que ya vaya filtrado. Por ejemplo:

Family shield, de OpenDNS: 208.67.222.123 / 208.67.220.123

Cloudflare family:

Anti malware: 1.1.1.2 / 1.0.0.2

Anti malware + anti pornografía: 1.1.1.3 / 1.0.0.3

Código:

# Configurarmos nuestro servidor dns upstream apuntando al family de cloudflare anti malware

/ip dns set servers=1.1.1.2,1.0.0.2

Y si queremos personalizarlo, sólo hay que sacarse una cuenta en OpenDNS Home y configurar a nuestro gusto los filtros que queramos. Nos proveerán otros servidores DNS donde podremos personalizar qué tipo de filtrado queremos aplicar, los cuales, al igual que lo anterior, podremos usar para filtrar parte o todo el tráfico del mikrotik.

Usar el servidor DNS como servidor local para un dominio de intranet.

Con la opción de IP -> DNS -> Allow remote requests, estamos convirtiendo nuestro equipo en un servidor DNS, el cual podrá hacer las funciones de DNS caché y de servidor local. Para esto último podemos crear entradas estáticas a las IP's locales de nuestros dispositivos, resolviendolos luego vía nombre.dominio.

Por defecto, el router habrá creado una entrada que apunta a la IP del propio equipo, la cual podemos resolver con un ping a router.lan. Siguiendo con ese dominio .lan, podemos seguir añadiendo dispositivos para luego resolverlos por nombre. Ejemplo:

Código:

/ip dns static add address=192.168.88.2 name=miequipo.lan

/ip dns static add address=192.168.88.3 name=miotroequipo.lan

...

etc

Bonus: una vez tengamos nuestros equipos, todos bajo un mismo dominio (puede ser el .lan o cualquier otro que nos guste más), podemos añadir este dominio a la lista de dominios de búsqueda en el DHCP, de tal manera que nos lo entregue como parte de los datos que facilita el router cuando un cliente le solicita una IP.

Código:

/ip dhcp-server network set number=[find where gateway=192.168.88.1] domain=lan

De esta forma, una vez el servidor DHCP nos entregue una dirección, también nos entregará su dominio de búsqueda, tal que ahora podremos invocarlo con un ping simplemente al nombre del equipo: ping router deberia responder de la misma manera ahora que un ping router.lan

Acceder a la ONT o el router que tengo conectado el puerto WAN (ether1).

Muchas veces tenemos la necesidad de acceder al router u ONT que usamos como WAN. Sin embargo, si estamos conectados al router mikrotik y estamos en otro segmento, no llegaremos a dicho equipo. La manera de hacerlo es muy sencilla.

Primero, creamos una IP del rango del equipo conectado al WAN, y se la asignamos a ether1. En mi caso tengo una ONT a la cual accedo con la dirección 192.168.100.1, de tal manera que he configurado la dirección 192.168.100.2 sobre ether1:

Código:

/ip address add address=192.168.100.2/24 interface=ether1 network=192.168.100.0

Y, a continuación, especifiamos que la interfaz física ether1 la considere como un puerto WAN (además de la VLAN o cliente PPPoE que use vuestra configuración original, la cual ya estará dada de alta como perteneciente a la lista WAN)

Código:

/interface list member add interface=ether1 list=WAN

Con estos dos sencillos pasos, ahora podremos abrir un navegador y, desde cualquier dispositivo conectado a nuestro router mikrotik, acceder a la dirección 192.168.100.1 (adaptarlo según necesidad de cada uno

Podéis aislar un equipo o varios dependiendo de vuestras necesidades. Añadir puertos al bridge de la red que queréis aislar.

Muchas veces tenemos la necesidad, bien por trabajo bien por cualquier otro tema, de aislar un equipo dentro de nuestra red. Para ello, no basta con asignar una IP o segmento de red distinta al equipo, sino que además tenemos que bloquear el tráfico que genera para que no acceda a nuestra red principal, dado que, por defecto, todos los segmentos de red que se configuren en un router mikrotik se comunican entres sí.

Para montar una red independiente, lo primero que vamos a hacer es sacar el puerto físico donde vayamos a conectar el equipo (ether5 en mi caso) del bridge principal, el cual de normal aglutina los puertos del 2 al 5 (en el caso de equipos con 5 puertos ethernet). En este caso, saco ether5 del bridge principal llamado bridge1.

Código:

/interface bridge port remove numbers=[find where interface=ether5]

Lo siguiente que haremos, será asignar un nuevo segmento de red para ese puerto. Por ejemplo, le daremos el segmento de red 192.168.99.1/24

Código:

/ip address add address=192.168.99.1/24 interface=ether5

Siguiente, creamos un pool de direcciones para dicho servidor, tan grande como nos interese. En mi caso, de 8 equipos, de la 3 a la 10.

Código:

/ip pool add name=pool-out-of-lan ranges=192.168.99.3-192.168.99.10

Y le añadimos un servidor DHCP a dicha interfaz, para no tener que preocuparnos de poner una IP estática en la máquina la cual conectemos a ese puerto. Primero el detalle de la red, luego el servidor propiamente dicho

Código:

/ip dhcp-server network

add address=192.168.99.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.99.1

/ip dhcp-server

add address-pool=pool-out-of-lan disabled=no interface=ether5 name=dhcp-out-of-lan

Y por último, y más importante, añadimos las reglas de firewall que nos impedirán la comunicación entre ambas redes, dado que el mikrotik las comunica por defecto. Serán dos reglas (una por cada sentido del tráfico) en el chain de forward:

Código:

/ip firewall filter

add action=drop chain=forward comment="drop communication from LAN to new network" \

    src-address=192.168.88.0/24 dst-address=192.168.99.0/24

add action=drop chain=forward comment="drop communication from new network to LAN" \

    src-address=192.168.99.0/24 dst-address=192.168.88.0/24

Información obtenida del foro AdslZone-Mikrotik

Esta opción nos valdrá para acceder a una máquina local (tipo un NAS o un webserver) usando un dominio público, cuando estemos dentro de nuestra propia red. En los routers comerciales al uso, normalmente esto ya viene implementado, y es algo por lo que no nos tenemos que preocupar. No obstante, en routers más avanzados, es una opción que hay que configurar a mano. La configuración básica, para una única máquina y un único puerto, la tenéis explicada en la wiki. No obstante, vamos a darle una vuelta de tuerca y a configurar esto para que el loopback funcione para todo el segmento de red y que, además, no tengamos que andar editando la regla de apartura de puertos del hairpin cada vez que necesitemos exponer un puerto nuevo. Para ello, vamos a hacer uso de una propiedad relativamente nueva en los routers mikrotik, llamada address-llists.

Primero, activamos el dominio ddns.

Código:

/ip cloud set ddns-enabled=yes

Segundo, añadiremos nuestro dominio como una lista de direcciones, la cual vamos a llamar public-ip. Al hacerlo, el propio router resolverá nuestra IP pública, a la cual apunta el dominio, sacando la dirección directamente del comando /ip cloud

Código:

/ip firewall address-list add address=[/ip cloud get dns-name] list=public-ip

Crearemos la siguiente regla de masquerade en el NAT, la cual colocaremos en la primera posición, antes que la regla por defecto (posición 0), obteniendo nuestra LAN dinámicamente. Suponemos que, si no se ha cambiado, nuestra LAN por defecto es la que se define en la primera entrada de "networks" en el servidor DHCP:

Código:

/ip firewall nat add action=masquerade chain=srcnat comment=hairpin-nat dst-address=[/ip dhcp-server network get 0 address] src-address=[/ip dhcp-server network get 0 address] place-before=0

Por último, creamos la apertura de puertos que queramos, pero con una pequeña modificación: ahora le diremos que el tráfico viene por nuestra IP pública. Al no tener una IP pública estática, no podremos usarla en el dst-address, pero como hemos creado la entrada en la lista de direcciones, podemos usar el dst-address-list como filtro. De esta manera no secuestramos todo el tráfico de nuestra red para ese puerto en cuestión, sino sólo el de entrada (el que tiene como destino la IP pública)

En este caso, abriremos el tráfico del puerto 443 externo (HTTPS) y lo redireccionaremos a la al puerto https de la consola de administración de nuestro equipo (supongo un servidor web situado en la IP 192.168.88.100 y con puerto de administración el 1234). Adaptar el ejemplo a vuestras necesidades:

Código:

/ip firewall nat

add action=dst-nat chain=dstnat comment=Web-Admin dst-address-list=public-ip \

    dst-port=443 protocol=tcp to-addresses=192.168.88.100 to-ports=1234

Una vez hecho esto, podremos ingresar a nuestra consola de admin, tanto desde dentro de la red como desde fuera, usando nuestro dominio tipo https://serial.sn.mynetname.net, tráfico que acabará golpeando el puerto tcp interno 1234 de la máquina 192.168.88.100

Para el resto de puertos a abrir, seguiremos la misma técnica y en todos especificaremos el dst-address-list, en lugar del in-interface.

CAP: Equipo(s) wifi el cual controlaremos mendiante CAPsMAN.

Implementación de CAP:

Vamos al apartado Wireless de nuestro equipo para ponerlo en modo CAP.

Hay que tener un detalle en cuenta que en muchos manuales no tienen en cuenta.

Si el equipo donde quieres instalar el CAPsMAN manager tiene wifi ( por ejemplo un hAP AC2 ) y quieres controlar también la parte inhalambrica , en ese equipo particular, has de hacer referencia a él mismo, a su direccion de loopback, 127.0.0.1 en lugar de referenciar al bridge como interfaz de discovery .

Es decir, esta sería la configuración de un CAP normal:

Y esta otra la de un equip CAP, que es a su vez es CAPsMAN:

Además de eso, necesitas que el router acepte el tráfico de CAPsMAN en el firewall. Si no lo has tocado, es una de las reglas por defecto que crea él mismo desde el quick setup. Deberías tener en el firewall, en el chain de input, una regla tal que así:

Código:

/ip firewall filter

add action=accept chain=input comment=\

"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1

Implementación de CAPsMAN:

Código:

/caps-man rates

add basic=12Mbps name=gn-only supported=\

12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps

/caps-man security

add authentication-types=wpa2-psk disable-pmkid=yes \

encryption=aes-ccm group-encryption=aes-ccm group-key-update=1h \

name=home-sp passphrase=MyPassword

/caps-man channel

add band=2ghz-g/n control-channel-width=20mhz \

extension-channel=disabled frequency=2412,2437,2462 \

name=2ghz-chs-auto tx-power=13

add band=5ghz-n/ac control-channel-width=20mhz \

extension-channel=XXXX name=5ghz-chs-auto

/caps-man datapath

add bridge=bridge client-to-client-forwarding=yes \

local-forwarding=no name=home-dp

/caps-man configuration

add channel=2ghz-chs-auto country=spain datapath=home-dp mode=ap \

name=home-wifi-2ghz-cfg rates=gn-only security=home-sp ssid=MyWifiSSID

add channel=5ghz-chs-auto country=spain datapath=home-dp mode=ap \

name=home-wifi-5ghz-cfg rates=gn-only security=home-sp ssid=MyWifiSSID

/caps-man provisioning

add action=create-dynamic-enabled hw-supported-modes=gn \

master-configuration=home-wifi-2ghz-cfg name-format=prefix-identity \

name-prefix=2ghz

add action=create-dynamic-enabled hw-supported-modes=ac \

master-configuration=home-wifi-5ghz-cfg name-format=prefix-identity \

name-prefix=5ghz

          /caps-man access-list

          add action=accept interface=all signal-range=-75..120

          add action=reject interface=all signal-range=-120..-76

         /caps-man manager

set enabled=yes

Si ves que los AP's eligen el mismo canal para la red de 2,4GHz, pulsa el botón "reselect channel" en la lista de interfaces de CAPsMAN,

Cuando selecciones el "CAP Interface" y ojo con la frecuencia de 5GHz que seleccione en auto, puesto que, dependiendo de la que coja, así tardará más o menos en levantar la interfaz de 5GHz. Lo digo porque no os extrañéis cuando la wifi de 5GHz tarde en levantar, me explico:

•Canales NO DFS ( del 36 al 48 ), frecuencias (5180 - 5240): la interfaz levanta instantáneamente, no necesita cumplir ningún requisito en dicha frecuencia.

•Canales DFS ( del 52 al 116 ), frecuencias (5260 - 5580): la interfaz escanea en busca de radares durante 1m. Si todo ha ido bien y no hay un pulso de radar detectado, levanta la interfaz en dicho canal.

•Canales DFS entre las frecuencias 5600 - 5650 (canales 120 - 132): banda reservada a radares meteorológicos, donde mikoritk cumple el estándar a rajatabla, es decir, extiende la detección del pulso de radar 10 minutos, para permitir que un radar meteorológico, como los que hay en el aeropuerto, complete un ciclo completo de rotación. Si el equipo selecciona esa frecuencia, tardará el menos ese tiempo en levantarla.

Las frecuencias DFS están bien, porque los equipos pueden emitir con más potencia en algunos de esos canales. Pero tened en cuenta de que, si detectan un pulso de radar, el AP de apaga y reselecciona otro canal, para cumplir con la ley.

CONSEJOS Y ACLARACIONES

Cuidado con lo del Skip DFS. Si sólo vas a tener un AP en la instalación... ni tan mal. Los canales en 5GHz tienen un ancho de canal de 20MHz por defecto. Los canales que cumplen con ese "Skip DFS" son los cuatro primeros del espectro: 36, 40, 44, 48. Si plantas una configuración de 80MHz con Skip DFS, significa que el AP se va a plantar en el 36 o el 48 y va a extender bien por arriba bien por abajo a los otros tres canales, zampándote de un plumazo los 4 canales; los únicos cuatro que cumplen con esa regla. Si mañana vas a plantar otro AP, no le quedará más remedio que usar el mismo canal, y ahí empiezan los problemas, si los AP's no están lo suficientemente separados y se "oyen" entre ellos. En ese caso, habría que bajar el ancho de canal a 40Mhz, donde sí tendrías dos canales sin solapamiento entre los NO DFS.

Resumiendo: los canales DFS están para usarlos, aunque siempre es bueno tener al menos un AP en un canal NO DFS, tal que si los otros detectan un pulso de radar y se ponen a reseleccionar una nueva frecuencia, no te quedes tirado por completo. Esto para instalaciones grandes, para casa no creo ni que te enteres.

Además de lo anterior, si en tu equipo ejecutas interface wireless info allowed-channels wlan2, verás que el equipo no emite con la misma potencia en todos los canales. 

1. Si al final sólo se decide usar un equipo con Capsman habilitado y sin otros Caps a su cargo como se puede subir el power tx que ahora está restringido en la banda de 2.4Ghz. En la definición del canal (pestaña Channels), ves que el canal está definido con cierto valor en el "Tx Power". Si quitas ese valor, el equipo emitirá con la potencia máxima, restringida por tu país, que pueda emitir en esa banda. Para 2,4GHz, dicha potencia en España son 20dBm (100mW). Puedes poner valores por debajo de 20 a ese campo, si los pones por encima, el propio firmware te capará y te dará como máximo 20dBm. Si quieres que ambas redes lleguen con igual intensidad a los sitios, reduce la potencia de la de 2,4GHz en torno a 7-8dBm. De esa manera, promueves un roaming natural a la red de 5GHz, puesto que a igual potencia, los clientes suelen implementar reglas de roaming donde prefieren la red con mayor velocidad; la de 5GHz. No obstante, esto lo vas a hacer cuando tienes varios AP's para cubrir una zona, normalmente con un único AP no te interesa restarle potencia. Si tienes que plantar dos AP's asegúrate de que, entre ellos, no se oyen: reciben señal con menos de -80 a -85dBm cuando los pones a "escuchar" uno al otro.

2. Cuales son los pasos correctos para actualizar el equipo con Capsman manager y los Caps que tuviera a su cargo. 

Si no te quieres complicar la vida, verás que los equipos en modo CAP tienen un bridge con un cliente dhcp corriendo, usease, tiene IP. Los localizas vía winbox y los actualizas, entras a ellos y los actualizas, tal cual haces con tu equipo normal. Si te quieres complicar la vida, como obviamente en un despliegue de 200AP's no vas a ir uno a uno actualizando, CAPsMAN también ha pensado en eso: en el botón "Manager" de CAPsMAN verás dos campos, uno que se llama "Package Path" y otro que se llama "Upgrade Policy". Esos dos valen, respectivamente, para decirles dónde está el paquete software que contiene la actualización en el disco de tu CAPsMAN y cuándo tienen que actualizar. Las dos opciones para actualizar son: require same version: cuando actualiza el CAPsMAN, fuerza a actualizar los CAPs a la misma versión, y si no puede los deshabilita; no los provisiona (se van de CAP Interface, aunque aún puedes crear una provisión a mano en dicha pestaña) suggest same version: cuando actualiza el CAPsMAN, intenta actualizar los CAPs a la misma versión, y si no puede. los deja como estaba, provisionados.

En la práctica esto es un poco coñazo, especialmente para casa: si tienes varios equipos varipintos (un hEX-S como CAPsMAN [arquitectura MMIPS], hAP-lite/mini [arquitectura SMIPS] y hAP-ac3 [arquitectura ARM]) tendrás que bajarte sendos paquetes y meterlos todos en el CAPsMAN si quieres que se actualicen los CAPs. Resultado: tardas menos en entrar en cada uno y pulsar "System -> Packages -> Check for Updates", que además ya selecciona su arquitectura automáticamente. Supongo que en despliegues enormes con todos los APs iguales, es muy cómodo la opción de actualizarlos vía CAPsMAN, pero para casa, me quedo con el método manual.

3. Con sólo conectarlo o desconectarlo por cable de red Capsman ya se hace cargo dinámicamente de todo? No hay que dar de alta ni baja los Caps?

Esa es la gracia de CAPsMAN: le das un reset a un equipo y lo pones en modo CAP (desde las opciones del reset lo tienes), y con que le llegue un cable ethernet que le enchufe al CAPsMAN, ya no tienes que hacer más. Esto pasa porque las dos reglas de provisioning que tienes son totalmente automáticas, de ahí que no te haga falta dar de alta ni de baja nada, y dicen: si el equipo soporta g/n, mándale la configuración de g/n, y si soporta además ac, mándale también la de ac. Como ves, esas reglas no llevan especificadas las direcciones MAC, que es lo que suele ir en una regla de provisioning normal en un despliegue grande: cada radio lleva su MAC y su regla de provisión, tal que nadie te pueda pinchar un AP en tu instalación y obtener una configuración que funcione. De hecho, se suelen meter configuraciones y reglas de provisioning "bogus" o "fakes" para que obtengan una provisión temporal que no haga nada, y luego ir metiendo a mano la suya, atendiendo a un plano de situación y distribución de canales.

Además de lo anterior, las reglas de provisioning que hemos metido tienen como "action" un "create dynamic enabled", que quiere decir "créame las interfaces CAP dinámicamente y de forma automática las das de alta en CAP Interface. Si te das cuenta, las reglas dinámicas no se pueden editar en la primera pestaña, sólo borrar, y dependen totalmente de las reglas de provisión. Lo bueno de esto es que si tocas algo en la configuración, el canal, la seguridad o cualquier otro parámetro, el propio CAPsMAN detecta el cambio y recrea la interfaz sin tú tocarlo (tarda un pelín, pero lo hace automático). Si quieres forzarlo y ver con tus propios ojos el cambio, sólo tienes que borrar la interfaz CAP de la primera pestaña e ir a Radio, seleccionar la entrada que no tiene "P" (sin provisión), y darle al botón Provision, y verás como se vuelve a crear la entrada dinámica en la primera pestaña.

Como las reglas de provisioning son totalmente automáticas y para que identifiques mejor quien es quien, el Name Format está puesto como Prefix + Identity, siendo el prefijo 2ghz / 5ghz, dependiendo de la regla. Las identidades o nombres de los CAPs también los puedes controlar desde la pestaña Remote CAP, con el botón Set Identity.

La configuración que te he facilitado es de las más sencillitas, pero perfectamente válida para casa.

Todo esto se puede complicar lo que quieras, si le sabes sacar partido a la herramienta. Cuando quieras lo pones en casa y juega con ello, entre dos APs.

4. De cara al roaming entre Caps piensas que es conveniente o no ponerle alguna regla en el access list para el salto de un Cap al otro o es mejor dejar que decida el cliente inalámbrico a que Cap se conecta y no poner ninguna regla. 

Creo que, a menos que pongas los AP's lo suficientemente lejos el uno del otro, vas a necesitar la regla. En mi experiencia, si los AP's están suficientemente cerca, como no metas una regla de ese estilo, no fuerzas a que el cliente desconecte del primer AP, aunque detecte el otro con bastante más potencia, a menos que apagues y enciendas el wifi de ese dispositivo en cuestión (lo suelen hacer los teléfonos por su cuenta cada cierto tiempo).

5. Potencia de emisión. Pondríamos poner la banda 2.4Ghz en 17dBm que ya es la mitad de la potencia que la original (cada 3dBm menos, es la mitad), que arranca en 20dBm.

Si ves que sigues teniendo demasiada buena cobertura en 2,4, vas bajando poco a poco, quizás de uno en uno, hasta que te quedes con la justa, que te llegue a todos los rincones de casa pero no salga de ahí.

Si quieres que tus equipos prefieran la de 5Ghz a la de 2, asegúrate de que hay una diferencia en potencia de emisión de al menos 6dBm entre lo a lo que emite una y otra banda, con beneficio sobre la de 5GHz. Es decir, que si la de 5GHz emite a 23, la de 2,4Ghz emita a 17 o menos.

Ten en cuenta los números de CAPsMAN, luego los de emisión real son siempre algo menores, puesto que se les resta la ganancia de la antena.

Por ejemplo, si tu tienes un cAP-AC y configuras que la red de 2,4GHz tenga una potencia de emisión de 17dBm, si te vas al CAP en cuestión, verás que está emitiendo a 15, puesto que su antena integrada tiene 2dBm de ganancia.

Es decir, la tarjeta inalámbrica emite a menos potencia, lo cual es bueno para generar cuanto menos ruido mejor.

Lo mismo pasa en 5GHz, si coge un canal no DFS emitirá a 23dBm por defecto, menos tres de la ganancia de la antena en esa banda (2,5 en verdad, pero redondean hacia arriba), si te vas al CAP en cuestión lo verás a 20. Y si emites en un DFS que tiene de salida 27dBm, lo verás en 24, y así.

Cada equipo ya conoce su ganancia y lo que tiene que restarle a la potencia de emisión, en función de sus antenas. Solo habría que tocarlo si cambian las antenas por unas de mayor ganancia.

Información obtenida del foro AdslZone-Mikrotik.

Introducción​

Sustitución del manual para montar una VPN de tipo IKEv2. Quiero mostraros cómo montar no sólo una VPN de tipo road-warrior, sino también como unir dos sedes usando este tipo de VPN, que sinceramente creo es la mejor que podéis montar en un equipo de esta marca, a día de hoy.

Generación de certificados​

Me baso en que tenéis un dominio propio, en mi caso y para el ejemplo será pericopalotes.com, el cual apunta a la IP pública de vuestra conexión con el sub-dominio router.pericopalotes.com, de la manera que creáis conveniente. No obstante, podéis hacer lo mismo con el dominio que os regala Mikrotik, el cual podéis encontrar en IP -> Cloud, si activáis esa opción. Vamos a crear dos certificados, uno para un cliente road-warrior, un supuesto teléfono móvil y el otro para un cliente de tipo oficina, que conectaremos en remoto a nuestro HQ.

Código:

# Creaccion de los certificados
# Primero la CA
/certificate
add name=vpn-ca country=ES state=Tabarnia locality=Rivendel organization="Perico Palotes LTD"\
common-name="VPN CA" subject-alt-name=DNS:pericopalotes.com key-size=2048 days-valid=3650 trusted=yes\
key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,crl-sign

# Luego el certificado del servidor
add name=vpn-server country=ES state=Tabarnia locality=Rivendel organization=Perico Palotes LTD" unit=VPN\
common-name="VPN Server" subject-alt-name=DNS:router.pericopalotes.com key-size=2048 days-valid=1825\
key-usage=tls-server,key-encipherment,digital-signature

# Por ultimo una template para crear certificados cliente
add name=~vpn-client-template country=ES state=Tabarnia locality=Rivendel organization=Perico Palotes LTD"\
common-name="VPN Client XXX" subject-alt-name=email:xxx@router.pericopalotes.com key-size=2048\
days-valid=730 key-usage=tls-client

#Y los certificados de tipo cliente, copia de la template
add copy-from=~vpn-client-template name=vpn-client-mobile common-name="VPN Client Mobile"\
subject-alt-name=email:mobile@router.pericopalotes.com
add copy-from=~vpn-client-template name=vpn-client-branch common-name="VPN Client Branch"\
subject-alt-name=email:branch@router.pericopalotes.com

# Los firmamos
/certificate
sign vpn-ca
{:delay 5};
sign vpn-server ca=vpn-ca
sign vpn-client-mobile ca=vpn-ca
sign vpn-client-branch ca=vpn-ca

# Exportar la CA y los certificados cliente
/certificate
export-certificate vpn-ca file-name=ca
export-certificate vpn-client-mobile type=pkcs12 export-passphrase="MySuperVPN!" file-name=mobile
export-certificate vpn-client-branch type=pkcs12 export-passphrase="MySuperVPN!" file-name=branch

A continuación, daremos de alta un pool para los clientes de tipo road-warrior. Abriremos un "hueco" en dicho pool, puesto que usaremos las primeras direcciones para las oficinas remotas en el modo site-to-site.

Código:

/ip pool
add name=pool-vpn ranges=192.168.68.10-192.168.68.254

Y ahora creamos toda la configuración para IPSec, auto explicada en sus comentarios.

Código:

#Creamos dos configuraciones, una para road warrior, y otra para la oficina remota
/ip ipsec mode-config
add address-pool=pool-vpn address-prefix-length=32 name=ike2-conf-road-warrior split-include=0.0.0.0/0 system-dns=yes
add address=192.168.68.2 address-prefix-length=32 name=ike2-conf-branch system-dns=no

# Damos de alta un nuevo groupo para asociar a él las plantillas de configuración con los policies a usar
/ip ipsec policy group
add name=ike2-template-group

# Damos de alta el perfil de authenticación
/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha256 name=ike2-profile

# Damos de alta el peer que escuchará las conexiones remotas, de tipo IKEv2
/ip ipsec peer
add exchange-mode=ike2 name=ike2-peer passive=yes profile=ike2-profile

# Damos de alta la propuesta de negociación para el intercambio de claves IKE y SAs
# Las claves tendrán una validez de 8h para evitar renegociaciones innecesarias y el pfs-group=none para
# aumentar la compatiblidad con dispositivos moviles, tipo Apple. Restringimos el proposal a tipo de encriptación AES
/ip ipsec proposal
add auth-algorithms=sha512,sha256,sha1 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm lifetime=8h \
    name=ike2-proposal pfs-group=none

# Damos de alta las identidades de los clientes que se van a conectar al router
# Por un lado el movil en modo road warrior, y por otro el router remoto en modo branch
# Cada uno apuntando a un mode-config distinto, y al nuevo grupo de plantillas que hemos creado
/ip ipsec identity
add auth-method=digital-signature certificate=vpn-server comment=mobile generate-policy=port-strict match-by=certificate mode-config=ike2-conf-road-warrior peer=ike2-peer \
    policy-template-group=ike2-template-group remote-certificate=vpn-client-mobile
add auth-method=digital-signature certificate=vpn-server comment=router-branch generate-policy=port-strict match-by=certificate mode-config=ike2-conf-branch peer=\
    ike2-peer policy-template-group=ike2-template-group remote-certificate=vpn-client-branch

# Creamos dos plantillas con las políticas pertinentes, ambas pertenecientes al nuevo grupo
# Suponemos 192.168.88.0/24 como LAN local del router de HQ, este que estamos configurando, y 192.168.98.0/24 como LAN local del router tipo branch remoto
# La 192.168.68.0/24 es nuestro segmento VPN para los equipos en modo road-warrior
/ip ipsec policy
add comment=road-warrior dst-address=192.168.68.0/24 group=ike2-template-group proposal=ike2-proposal src-address=0.0.0.0/0 template=yes
add comment=site-to-site dst-address=192.168.98.0/24 group=ike2-template-group proposal=ike2-proposal src-address=192.168.88.0/24 template=yes

Una vez hecho esto, tenemos el router listo para admitir conexiones remotas, tanto de clientes que vengan de cualquier IP den modo road-warrior, como el cliente remoto que será nuestra oficina que conecta con este router como head-quarter. Estamos suponiendo que la oficina remota tiene una LAN distinta de la principal, en este caso la principal supones está en la 192.168.88.0/24 (la red por defecto del mikrotik) y la remota será la 192.168.98.0/24. Como veis, las plantillas de generación de políticas de ikev2 van asociadas a dichas IPs.

Configuración en modo road-warrior​

En esta parte no me voy a parar, porque ya está explicada en el manual anterior. Exportáis los certificados CA y cliente (en este caso el mobile, que yo llamé "VPN Client iPhone") y los importáis en el dispositivo móvil que vayáis a usar, confiando ciegamente en la CA. El endpoint de conexión sería "router.pericopalotes.com" y la autenticación se haría por certificados, sin ninguna otra contraseña de por medio. Una vez conectados, navegaréis y tendréis los DNS del router principal. Un ejemplo de configuración en un iPhone, una vez hecha la importación de los certificados:

Configuración en modo site-to-site​

Esta conexión hay dos maneras de hacerla. O podemos montar un túnel IKEv2, exactamente del mismo modo que se conectaría cualquier cliente road-warrior, usando su perfil, para luego levantar sobre dicho túnel otro túnel IPIP, GRE, EoIP, etc y así hacer el enrutado, o podemos usar las policies de IPSec para enrutar el tráfico. Esta segunda manera no es trivial, puesto que no vamos a tener como tal una tabla de rutas donde podamos ver el caminio que seguiran los paquetes, sino que IKEv2 los tele-transportará usando las políticas de in-ipsec y out-ipsec. Me voy a centrar en esta segunda manera porque creo que es la manera correcta de hacerlo, y además vamos a obtener mucho mejor resultado en rendimiento, puesto que no vamos a generar overhead por el encapsulado de un túnel dentro de otro túnel. Si alguien quiere más detalle del setup de túnel sobre túnel, que pregunte, que lo puedo explicar también.

Del lado del servidor lo tenemos todo listo (salvo ajustar la parte del firewall, que la veremos un pelín más tarde) para que un cliente remoto establezca la conexión, ya sea tipo road warrior (usará la primera template) o de tipo site-to-site (usará la segunda template). Podemos crear tantas templates como redes queramos transportar de un lado al otro usando IPSec.

Lo primero que haremos del lado cliente es importar los dos certificados, la CA y el certificado cliente. Una vez importados, podemos renombrarlos si queremos, y así ponerle un nombre más descriptivo. En mi caso, el certificado de tipo CA se va a llamar "ca" y el certificado cliente se llamará "vpn-client-branch". Hecho esto, damos de alta una configuración similar que en el router de la oficina principal, con la única salvedad que el peer apuntará a la URL del equipo que hace de servidor VPN (router.pericopalotes.com) y que crearemos una policy de tipo túnel, en lugar de template. En este caso el identity apuntará únicamente a nuestro certificado cliente (no hay certificado servidor como en el otro lado), y pediremos la configuración al remoto. Con esto, nos quedaría así la configuración del cliente de tipo oficina remota.

Código:

# Nuevo template group, idéntico al del router HQ
/ip ipsec policy group
add name=ike2-template-group
# Perfil, idéntico al del servidor
/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 \
    hash-algorithm=sha256 name=ike2-profile

# Peer, apuntando a la dirección de nuestro dominio o IP estática del router HQ
/ip ipsec peer
add address=router.pericopalotes.com exchange-mode=ike2 name=ike2-hq-peer \
    profile=ike2-profile

# Proposal, idéntico al del router de HQ
/ip ipsec proposal
add auth-algorithms=sha512,sha256,sha1 enc-algorithms="aes-256-cbc,aes-256-ctr,a\
    es-256-gcm,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm" \
    lifetime=8h name=ike2-proposal pfs-group=none

# Identity, en este caso especificando únicamente el certificado cliente
# Y, como configuración, indicamos "request-only" para pedirsela al remoto
/ip ipsec identity
add auth-method=digital-signature certificate=vpn-client-branch generate-policy=\
    port-strict mode-config=request-only peer=ike2-hq-peer \
    policy-template-group=ike2-template-group

# Policy, en este caso en modo túnel, no template
# Origen la LAN de nuestra oficina branch, destino la LAN del router HQ
/ip ipsec policy
add dst-address=192.168.88.0/24 level=unique peer=ike2-hq-peer proposal=\
    ike2-proposal src-address=192.168.98.0/24 tunnel=yes

Si todo ha ido bien, en el router cliente, el que hace de branch remota, tendremos una entrada tipo túnel en la pestaña de IPSec Policies, y en la columna PH2 State, veremos el mensaje "established". Dicha entrada habrá golpeado en el router remoto, en la template "site-to-site", y se habrá generado una entrada similar, creada por la plantilla de forma dinámica, con el mismo mensaje "established" en la columna PH2 State. Si navegamos en cualquiera de los dos routers a la pestaña "Installed SAs" podremos ver las claves de encriptado que se han generado en ambos extremos (autenticación sha512 y encriptado aes cbc de 256 bits) , y en la pestaña "Active Peers" podremos ver la conexión del cliente en sí. En este momento ambas LANs estarán conectadas y podremos lanzar un ping desde un cliente conectado al router de HQ hacia un cliente conectado al router de la branch y viceversa.
En el router cliente, veréis una nueva dirección 192.168.68.2 que ha aparecido de manera dinámica sobre ether1 (o la que sea vuestra interfaz WAN), lo cual podéis comprobar en IP -> Address.

Una cosa curiosa de este método es que nos permite conectividad incluso si el router de la oficina estuviera debajo de un NAT de otro router de operadora. Si además quisiéramos tener acceso desde al oficina HQ a dicho router que está por encima de nuestro mikrotik en la branch remota, bastaría con crear un nuevo túnel en el router de dicha oficina mandándole a la red remota la red de dicho equipo. Como ambos están conectados entre sí, podríamos incluso acceder a ese equipo que tenemos por encima.

Ajustando el firewall - Reglas de input y TCP MSS​

En el firewall de ambos equipos necesitamos hacer un par de ajustes. Obviamente permitir el tráfico de IPSec en el chain de input (puertos 4500 y 500), permitiremos también el tráfico del protocolo 50 para ESP. En el router de tipo branch, además, permitiremos el tráfico de entrada encriptado, desde la red lan HQ, para administrar ese router de forma remota, una vez el túnel esté levantado.
Fijaos que en ninguno de los dos lados nos hará falta una regla de masquerade como nos pasa con otro tipo de VPN's, puesto que la regla general que enmascara el tráfico que sale por la WAN ya lleva un tipo de policy "out,none" que nos evita tener que hacerlo. Del resto, se encargan las templates del apartado Policies en ambos lados de la conexión, auto-mágicamente.

Firewall -> Filter (Lado Servidor, HQ)

Código:

/ip firewall filter
add action=accept chain=input comment="allow ipsec" dst-port=500,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp

Firewall -> Filter (Lado Cliente, Branch). Permitimos también la administración remota desde la LAN de HQ.

Código:

/ip firewall filter
add action=accept chain=input comment="allow ipsec" dst-port=500,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input comment="allow HQ access to router" ipsec-policy=in,ipsec src-address=192.168.88.0/24

Por último nos queda ajustar el MSS de los paquetes TCP. Y diréis, ¿qué narices es eso? Pues bien, aunque tal y como está la conexión os va a dar un buen resultado, el tema se puede mejorar aún más si ajustamos el tamaño del paquete. Al estar trabajando con IPSec y con tráfico encriptado, no toda la información del los 1500bytes del tamaño de paquete la podemos usar para transportar información útil, puesto que el propio encapsulado y el encriptado se come parte de ese tamaño. Para evitar dicha fragmentación, lo que haremos será modificar el valor del tamaño del paquete para los mensajes que se intercambien como TPC SYN, tal que si un cliente remoto quiere enviarnos información, lo primero que hará será mandarnos ese paquete de sincronización, donde ya le estaremos advirtiendo de que nuestra capacidad de mandar información útil es algo menor que los 1500bytes del MTU. Esto es algo que en otras VPN que manejan interfaces es automático, puesto que llevan un flag llamado "Clamp TCP MSS", que por defecto ya viene marcado (mirad por ejemplo los túneles de tipo L2TP o EoIP), pero al estar trabajando sin interfaces e ir directamente por IP, no tenemos esa opción. Para esto crearemos las siguientes reglas de mangle, que harán exactamente lo mismo:

Mangle, en el router HQ, Servidor (2x road warrior + 1x de entrada por cada de LAN de oficina remota).

Código:

/ip firewall mangle
add action=change-mss chain=forward comment="ike2-road-warrior clamp tcp mss" ipsec-policy=in,ipsec new-mss=1360 passthrough=yes protocol=tcp src-address=192.168.68.0/24 \
    tcp-flags=syn tcp-mss=!0-1360
add action=change-mss chain=forward dst-address=192.168.68.0/24 ipsec-policy=out,ipsec new-mss=1360 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=!0-1360
add action=change-mss chain=forward comment="ike2-branch clamp tcp mss" dst-address=192.168.88.0/24 ipsec-policy=in,ipsec new-mss=1360 passthrough=yes protocol=tcp \
    src-address=192.168.98.0/24 tcp-flags=syn tcp-mss=!0-1360

Mangle, en el router de la branch (una única entrada, para el tráfico de entrada al router HQ).

Código:

/ip firewall mangle
add action=change-mss chain=forward comment="ike2-hq clamp tcp mss" dst-address=192.168.98.0/24 \
    ipsec-policy=in,ipsec new-mss=1360 passthrough=yes protocol=tcp src-address=192.168.88.0/24 tcp-flags=syn \
    tcp-mss=!0-1360

En realidad vamos a conectar un puerto del router B como si perteneciera al router A. 

También añadiremos un bridge en cada uno de los routers en los cuales añadiremos los puertos que nosotros queramos utilizar, sea uno o varios.

Vamos a imaginar que nuestro router A es nuestro domicilio principal y nuestro router B es nuestra segunda residencia. A través del tunel EoIP accederemos a nuestro abono televisivo utilizando un segundo desco conectado al Router B. En este caso utilizamos ether2 en los dos routers para conectar los descos, pueden ser los puertos que queramos. Y los ether2 perteneceran respectivamente a un bridge. El tunel EoIP está securizado mediante IPsec ( mismo password ).

El túnel está establecido en el routerA y al otro lado hay un servidor dhcp sobre el bridge-EoIP que te estará dando una IP del segmento de red remoto a cualquier equipo que conectes al puerto ether2 del RouterB.

Router A = ip cloud 1234567890.sn.mynetname.net = router principal = ether2 (bridge-iptv)

Router B = ip cloud abcdefghijk.sn.mynetname.net = router secundario = ether2 (bridge-EoIP)

ROUTER A

/ip cloud set ddns-enabled=yes

/interface eoip

add allow-fast-path=no disabled=yes ipsec-secret=MyPassword \

    !keepalive mtu=1500 name=\

    eoip-tunnel1-to-RouterB remote-address=abcdefghijk.sn.mynetname.net \

    tunnel-id=0

/interface bridge port add bridge=bridge-iptv interface=ether2

/interface bridge port add bridge=bridge-iptv interface=eoip-tunnel1-to-RouterB

 ROUTER B

 

/ip cloud set ddns-enabled=yes

 

/interface eoip

add allow-fast-path=no disabled=yes ipsec-secret=MyPassword \

    !keepalive mtu=1500 name=\

    eoip-tunnel1-to-RouterA remote-address=1234567890.sn.mynetname.net \

    tunnel-id=0

/interface bridge port

add bridge=bridge-EoIP interface=ether2

add bridge=bridge-EoIP interface=eoip-tunnel1-to-RouterA

 

/ip dhcp-client

add add-default-route=no disabled=no interface=bridge-EoIP use-peer-dns=no \

    use-peer-ntp=no

Información obtenida del foro AdslZone-Mikrotik.

 

En la siguiente configuración podéis cambiar los datos de red (.89.), usuarios y contraseñas a vuestro gusto.

Aprovechamos que Mikrotik nos regala un dominio DDNS referenciado a nuestro equipo para así poder acceder a él desde el exterior de nuestra red.

/ip cloud set ddns-enabled=yes

Podemos ver nuestro dominio utilizando Winbox en el menú IP>Cloud con el formato 123xyz123xyz.sn.mynetname.net

Código:

/ip pool

add name=vpn-pool-l2tp ranges=192.168.89.10-192.168.89.50

/ppp profile

add change-tcp-mss=yes interface-list=LAN local-address=192.168.89.1 name=\

    vpn-profile remote-address=vpn-pool-l2tp use-encryption=yes

/interface l2tp-server server

set authentication=mschap2 default-profile=vpn-profile enabled=yes \

    ipsec-secret=MyPasswordIPSEC use-ipsec=yes

/ip firewall filter

add action=accept chain=input comment="allow IPsec" dst-port=500,4500 \

    protocol=udp

add action=accept chain=input comment="allow l2tp" dst-port=1701 protocol=udp

add action=accept chain=input comment="accept vpn encrypted input traffic" \

    ipsec-policy=in,ipsec src-address=192.168.89.0/24

/ip firewall nat

add action=masquerade chain=srcnat comment="masq. vpn l2tp traffic" src-address=\

    192.168.89.0/24

/ppp secret

add name=User01 password=Password01 service=l2tp

add name=User02 password=Password02 service=l2tp

Información obtenida del foro AdslZone-Mikrotik.

Muchas veces tenemos la necesidad de asignar una IP fija (estática) a una máquina concreta, dentro de nuestra red. Por ejemplo, cuando tenemos un servidor web, de vpn, o cualquier otro tipo de máquina que lleve un mapeo de puertos. Obviamente, dado que el mapeo de puertos va asociado a una IP concreta, nos interesa que se le otorgue siempre la misma IP a dicho equipo y que no cambie, o el mapeo de puertos nos funcionará relativamente poco tiempo.

Mucha gente tiene la tentación de asignar IP's a mano dentro de los equipos (ip, máscara, puerta de enlace y dns) y para mi esto es un grandísimo error. No es que per se esto está mal, que no lo está, pero es un paso atrás enorme: empiezas a distribuir distintas configuraciones por distintos equipos, en lugar de centralizar la configuración en el router. Si mañana cambias tu router principal, te va a tocar modificar a mano ese equipo, a menos que respetes con pelos y señales cada detalle que pusiste. Y, cuando tienes una máquina...ni tan mal. Pero, ¿y cuando tienes 30 interruptores en casa domotizados? O cuando tienes 50 impresoras en una empresa.. ¿vas a querer ir metiendo la IP de cada una a mano? Obviamente no, para esto está el servidor DHCP, que nos entrega direcciones automáticas. Pero, ¿podríamos hacer que también las entregue estáticas? Pues sí, vinculando la IP que queremos entregar a la MAC address o dirección física del dispostitivo en cuestión.

Para hacerlo, tenemos dos opciones:

Abriendo un agujero en el pool de direcciones del DHCP: esta opción no es necesaria, aunque sí puede ser conveniente si vamos a mezclar reserva de direcciones estáticas en el DHCP con las que nosotros metamos a pelo en los dispositivos. Si mi pool de direcciones va de la 192.168.88.2-192.168.88.254, puedo modificar el comienzo y decirle que arranca en el 20, y así asinar de la 2 a la 20 esas direcciones como las estáticas. El pool iría entonces de la 192.168.88.20 - 192.168.88.254, y cuando diera de alta una IP estática en la reserva, la asociaría a un número del 192.168.88.2 al 192.168.88.19.

Sin abrir dicho agujero: simplemente vamos a asociar una IP del rango del pool a una MAC concreta. El propio servidor DHCP se encargará de reservar esa dirección para entregarla sólo a la dirección MAC asociada, ignorándola en la asignación normal de direcciones dinámicas.

De cualquiera de las dos formas, la manera más sencilla es ir a la pestaña Leases dentro del servidor DHCP, y localizar el dispositivo que nos interesa por su dirección MAC. Una vez localizado, seleccionaremos esa entrada (doble click en winbox, un click en webfig) y pulsaremos el botón Make Static.

Una vez hecho esto, pasan dos cosas: la primera, se quita la "D" que aparece en la primera columna, y que nos indicaba que la entrada era dinámica. La segunda: que dicha entrada se vuelve editable, y podemos volver a hacer doble click en ella y modificar ahora su dirección IP. En ese momento, le otorgaremos la dirección que queramos que tome, y dicha dirección será entregada en el siguiente proceso de renovación del lease del DHCP (cuando el cliente vuelva a preguntarle al servidor, "oye, dame u na IP", y este le conteste con la reservada, en lugar de decirle "quédate con la dinámica que ya tienes"), lo cual pasa a la mitad del tiempo del Lease que tengáis configurado. Por defecto está en 10 minutos, así que las IP's renuevan cada 5. No pasa nada porque escojáis una IP que ya está en uso dinámico para la reserva, y asignada a otra máquina: el servidor DHCP es inteligente, y se quedará con la tarea de desasignar esa IP a quien la tiene como dinámica, y asignarle otra nueva en el siguiente lease. Puede que os de un warning en el log, avisando de ello, pero lo resuelve él solito. La reservada siempre manda sobre el resto.

Por último comentaros que el servidor DHCP de mikrotik es de lo mejorcito que tienen estos equipos. Lo he visto funcionando sin pestañear incluso otorgando direcciones por intenet sobre una conexión pésima a través de túneles EoIP. Así que creo que no hay razón alguna para seguir metiendo IP's a mano en los dispositivos finales, or recomiendo enfáticamente no hacerlo y usar esto en su lugar. Y creedme cuando os digo que es capaz de manejar una tabla de leases con muchos muchos equipos, sin mayor problema.

Información obtenida del foro AdslZone-Mikrotik.