TCP:SA Block
-
¿Ya desactivaste en las WANs la opción Block Private Networks?
¿Tienes en las WANs reglas que admitan el tráfico entrante en la interfase?
¿Puedes detallar más tu topología (subredes empleadas, situación exacta de NAT…).
Recomendaciones al postear
https://forum.pfsense.org/index.php/topic,23265.0.html -
gracias por responder.. si tengo desactiva esa opcion en todas al interfaces.. mañana termino de hacer la topologia y la posteo.. al igual que las reglas que tengo en el firewall. y las posibles soluciones que he pensado hacer…
-
aca les dejo la configuracion de red http://s29.postimg.org/edz2blhqv/red.png
ahora explico.. desde la oficina b puedo hacer ping, tracert, ssh a la sede, pasar archivos via scp etc. pero al intentar llegarle por http a un servidor web interno que tenemos..el firewall (pfsense) de la sede me bloquea el trafico tcp:sa ; ahora desde la sede le llego sin novedad al servidor web de la oficina b.
Cabe destacar que esta conexion entre oficinas es una conexion punto a punto con frame relay es una conexion de datos. la diferencia de las configuraciones del PFSENSE es la siguiente.En la SEDE el fw tiene 3 tarjetas de red LAN, DMZ y WAN y una vlan(datos) asociada a la WAN en la tarjeta WAN llegan dos conexiones de internet y una de datos..(vlan con router cisco)
en la OFC B el firewall tiene igual 3 tarjetas de red LAN, WAN y DATOS esta de datos apunta hacia la WAN(vlan de datos) de la sede central.
se me ocurre que tal vez haciendo un bridge en la ofc B se vea el trafico desde alla hacia la sede como un mismo trafico y no como una red diferente… no se solo son conjeturas.
Que podria revisar para evitar este detalle de conexion?
gracias, saludos
-
ahora explico.. desde la oficina b puedo hacer ping, tracert, ssh a la sede, pasar archivos via scp etc. pero al intentar llegarle por http a un servidor web interno que tenemos..el firewall (pfsense) de la sede me bloquea el trafico tcp:sa ; ahora desde la sede le llego sin novedad al servidor web de la oficina b.
Seguramente el problema es de enrutado asimétrico. Las peticiones llegan al servidor pero este las devuelve por su puerta por defecto. Y esta vuelta no debe seguir el mismo camino que la ida.
se me ocurre que tal vez haciendo un bridge en la ofc B se vea el trafico desde alla hacia la sede como un mismo trafico y no como una red diferente…
Los bridges hay que evitarlos siempre que sea posible. El enrutamiento es más eficaz y seguro.
-
Les comento que logre resolver de la siguiente forma:
Tenia una regla que es esta
IPv4 * Redes * 192.168.0.2 * datos nonedonde Redes es un alias de las redes que tengo en mi lan. Me tenia pensativo el hecho de que solo bloqueaba las conexiones tcp:sa por lo que me enfoque ese tipo de paquetes, revisando la regla anterior decidi colocarla de la siguiente forma
IPv4 TCP Redes * 192.168.0.2 * datos noneNotese que seleccione explicitamente protocolo TCP porque era ese el que me daba problemas, me di cuenta que al seleccionar dicho protocolo me activo una opcion llamada```
TCP flagsIPv4 TCP Redes * 192.168.0.2 * datos none
IPv4 * Redes * 192.168.0.2 * datos none
 -
Consultando el borrador del nuevo libro de pfSense…
If you need to account for more complex scenarios, such as working around asymmetric routing or some other non-traditional combination of traffic
flow, you can alter how the flags are checked.To allow TCP with any flags set, check Any Flags.
Por tanto, acertaste con la solución. No obstante, revisa bien tu topología porque eso es típico de enrutados asimétricos.
En instalaciones multiWAN pueden originarse enrutados asimétricos en servicios abiertos a internet simplemente por el orden de reglas en la LAN donde se encuentre el servidor.
-
Gracias amigo.. donde puedo encontrar el libro??
-
Si tienes una Subscription Gold tienes el libro.
Es una forma de contribuir al proyecto (de código libre).
https://portal.pfsense.org/subscribe-for-access.php
Saludos,
Josep Pujadas-Jubany
Moderador del foro (en castellano) de pfSense -
ummmm triste.. no puedo con ese consto.. pero colaboraré de otra forma con el proyecto
P:D como cambio a solucionado el titulo original del post??
-
I know this is a quite old topic but I will put my solution in here just in case someone come across with the same problem.
Usually, the "TCP:SA" gets blocked by the firewall because the package took a different path on its way back. Pfsense being a stateful firewall needs to know the full path before letting the package go in. The package path should be the same to the network destination and from the network destination any discrepancy in the path the firewall will block it.
If you trust on the IP/Network getting blocked you should set up a thing known as asymmetric routing explained here https://docs.netgate.com/pfsense/en/latest/book/routing/static-routes.html#figure-asymmetric-routing .
This helped me with my issue today. I hope this comment help someone some other day.
