TCP:SA Block

bellera

¿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

juancho

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…

juancho

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

red.png_thumb

bellera

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.

juancho

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)

bellera

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.

juancho

Gracias amigo.. donde puedo encontrar el libro??

bellera

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

juancho

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??

peterfranca

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.