[SOLUCIONADO] [NO USAR 169.254/16] No logro routear entre dos redes
-
Hola a todos, tengo una pequeña instalación con un pFsense 2.1, en el cual tengo dos interfaces de red montado sobre la misma interface de red usando dos VLAN distintas.
Una interface de red es RED_SCH con IP 169.254.0.1/16
La otra interface de red es LAN con IP 172.16.1.1/16
Estoy intentando routear entre las dos pero no lo logro.
Desde la LAN he logrado hacer Ping a 169.254.0.1 pero a equipos de esa subred, como por ejemplo 169.254.0.2 no logro hacer ping.
Me tiene loco porque no se si es fallo mio o no, he incluso usado el WireShark para ver si salen del interface de red los paquetes y entran por la LAN pero no salen por el RED_SCH.
Tengo las siguientes reglas anexas a este post.Gracias por vuestra ayuda.
 -
Las preguntas "de siempre":
-
Supongo que las interfases LAN y RED_SCH están sin una puerta definida. Error frecuente poner una Gateway en interfases LAN. Sólo deben tener puerta las interfases WAN.
-
¿Los equipos en RED_SCH tienen como puerta la interfase RED_SCH de pfSense?
-
¿Los equipos en RED_SCH tienen cortafuegos por software activado? ¿Admiten que se les pinguee desde otra subred?
-
-
Hola !! gracias por responder, las dos interfaces de red estan sin Gateway, los equipos de la red LAN tienen como Defailt Gateway la dirección IP de la Interface LAN.
De hecho, los equipos de la LAN acceden a internet a traves de las WAN y todo eso perfectamente y a otras subredes.
Lo unico extraño es que para poder hacer ping desde el equipo de LAN a la IP del interface RED_SCH tuve que meter la ruta manual.
Route add 169.254.0.0 MASK 255.255.0.0 172.16.1.1He hecho una captura de paquetes en el interface RED_SCH desde el pFsense y no veo salir los paquetes hacia la red SCH
Es raro, me tiene muy liado.
-
No deberías usar rango clase B para enlace local, 169.254.0.0/16
http://es.wikipedia.org/wiki/Direcci%C3%B3n_de_Enlace-Local
http://es.wikipedia.org/wiki/Red_privada#Direcciones_de_enlace_local
https://forum.pfsense.org/index.php?topic=32651.msg168694#msg168694
http://tools.ietf.org/html/rfc3927#section-1.6
169.254.0.0/16 es un rango para direcciones privadas, pero está reservado. Un equipo que esté configurado por DHCP toma una dirección aleatoria dentro de este rango si no consigue una dirección de un servidor DHCP en la red. No es recomendable trabajar dentro de este rango.
(Véase http://www.ietf.org/rfc/rfc3330.txt y http://www.ietf.org/rfc/rfc3927.txt )
-
Gracias!! Entonces entiendo que no puedo lograr que me pase los paquetes de un interfaces a otro ni aunque use Nat o algún truco.
Es que la red 169.254.0.0/16 ya existía de antes, la instaló una empresa subcontratada antes de que yo llegara, yo gestionó la Lan y ha surgido la necesidad de interconectarlas ahora.
En la red Sch hay equipos de medida de energía y no puedo cambiar las direcciones IP.
He intentado que fucione con Nat pero tampoco.
La verdad que me han dejado un buen mochuelo.
Gracias por todo, si se te ocurre algún modo de comunicarlas… -
Muéstranos cómo "probaste con NAT" ?
-
Hice un "Outbound NAT" en el interfaz de La red Sch, pero tampoco sirve porque los paquetes los descartan.
-
No tendrás activada la opción "Block bogon networks" en LAN / RED_SCH ?
A ver cómo tienes el NAT ?
-
No entiendo muy bien lo que me intentas explicar, el "Outbounf NAT" para los WAN lo tengo aplicado al WAN, no se como dices que lo haga, ¿me lo explicas?
No tengo activado lo de "Bogon Network". -
De todas formas, hagas lo que hagas, no va a funcionar
Con "pfctl -sr" encuentras:
scrub on em2 all fragment reassemble scrub on em0 all fragment reassemble scrub on em1 all fragment reassemble anchor "relayd/*" all anchor "openvpn/*" all anchor "ipsec/*" all block drop in log quick inet from 169.254.0.0/16 to any label "Block IPv4 link-local" block drop in log quick inet from any to 169.254.0.0/16 label "Block IPv4 link-local" block drop in log inet all label "Default deny rule IPv4" block drop out log inet all label "Default deny rule IPv4" block drop in log inet6 all label "Default deny rule IPv6" block drop out log inet6 all label "Default deny rule IPv6"https://forum.pfsense.org/index.php?topic=82472
@cmb:
That's not a valid configuration. The fact Linux forwards link local doesn't mean it should work. It shouldn't. From RFC 3927:
An IPv4 packet whose source and/or destination address is in the
169.254/16 prefix MUST NOT be sent to any router for forwarding, and
any network device receiving such a packet MUST NOT forward it,
regardless of the TTL in the IPv4 header.http://tools.ietf.org/html/rfc3927#section-2.7
FreeBSD doesn't forward that traffic, the fact it goes outbound is a quirk, the reply hits the part of the OS that won't forward traffic that "MUST NOT" be forwarded per the RFC. I was recently contemplating putting in a block all 169.254/16 in and out rule in the back end.
You shouldn't be doing that, use RFC 1918 or the CGN 100.64.0.0/10 reserved space. Anything that follows RFCs isn't going to forward that traffic. Anything that does forward that traffic is broken.
@cmb:
It's hard coded into FreeBSD itself to not route that space, because it's not valid to do so. The NATed traffic just happens to bypass that check because it hits a "route-to" out which bypasses normal routing portions of the kernel, the reply doesn't and can't.
What you're attempting is fundamentally broken. The fact it ever worked should be written off, and you should implement a proper network.
-
Pues me toca cambiar la IP a todos los cacharros de esa red, gracias por todo compañeros.
Por cierto tu eres el mismo Ptt que el Ptt del foro de Ubiquiti??
Por curiosidad, yo también estoy en el otro foro. -
Si, Cuningan, también andan por aquí acriollo, azcarlos2 (ZAC ), infex987 ….. y seguro me estoy olvidando de algún otro compañero :D
-
Asi es mi estimado ptt, Buena liga la que pasaste. Se me hace que te las aprendes de memoria o ya te divorciaron por no estar en casa por que como decimos en mexico eres "ajonjoli de todos los moles" jajajaja ;D
Saludos!
-
¿Quien cambia los post en este foro a "solucionado"? ¿Se pueden dar algo parecido a "kudos"?
-
El usuario que hace una intervención puede modificarla. Hay un límite de días para hacerlo pero no sé cuantos son.
El administrador/moderador del foro puede modificar cualquier intervención, separar intervenciones de un hilo o unir hilos.
Espero haber aclarado el tema.
Los usuarios deberíamos indicar que un hilo está SOLUCIONADO cuando el problema se ha descrito, se han hallado sus causas y ha quedado claro el proceso de resolución. Como que casi nadie lo hace, en algunas ocasiones me permito hacerlo. Disculpas si ello haya podido molestarte. Recuerda que tu mismo puedes cambiar el Subject de la primera intervención, si lo consideras necesario.
En ocasiones cambio también los Subject para que quede más claro de qué se habla.
Saludos
bellera
Moderador de este foro, https://forum.pfsense.org/index.php?board=10.0 -
No hay problema, si no es que me haya molestado es saber si existe una forma de darle puntos o algo a quien te lo haya solucionado el problema.
Costumbre del foro de Ubiquiti, no sabía lo que hacer al estar resuelto el asunto como tu ya has visto.
Gracias por todo. -
Tienes 2 opciones/formas….. el botón "Thank You" y el "Karma" que puede ser "Positivo --> Applaud" o "Negativo --> Smite"
Ahh, y una "Funcionalidad" que considero interesante (y que les había sugerido a los muchachos de Ubiquiti), es la Habilidad que tiene el autor del Hilo/Tema de "Cerrarlo" (Lock Topic) en caso que considere que no tiene sentido seguir discutiendo el tema ;) y si eventualmente lo "reconsidera" y decide seguir el debate, tiene la opción de volver a abrir el tema (Unlock Topic)
