TCP:SA Block



  • Saludos, tengo dias intentando resolver un este detalle con 2 pfsense.. ambos estan conectado via directa (frame relay punto a punto) el escenario es:

    lan2–-pfsense2--------conexcion directa-------pfsense1-----lan1

    El caso es que instale un web server en la lan 1 pero cuando intento llegarle desde a lan 2 el pfsense1 me da el mensaje

    block
    Jan 27 23:59:34 LAN 172.31.91.35:80 192.168.0.2:5411 TCP:SA

    tengo una ruta estatica en cada router que me permite ver la red del otro, he activado el bypass en la opcion advanced-firewall/nat ademas tengo reglas que me permite el trafico entre redes.. pero no logro ver el servidor web!!

    el asunto es que si me conecto via ssh y traceroute y tcptraceroute me responden bien y llegan al equipo servidor..

    POdrian darme unas luces con este asunto.. la verdad ya no logro dar pie con bola



  • ¿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 	none 	
    

    donde 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 	none 	  
    

    Notese 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 flags

    IPv4 TCP Redes * 192.168.0.2 * datos none

    IPv4 * Redes * 192.168.0.2 * datos none

    
    ![tcpflags.jpg](/public/_imported_attachments_/1/tcpflags.jpg)


  • 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.


Log in to reply