Regra oculta no pfsense
-
@mcury Não entendi oque você quis dizer com o endereçamento da Lan 172.16.251.0.
Veja se fica mais claro -> traceroute 192.168.13.156 (este é o servidor de aplicação que fica na prefeitura, eu estou no hospital, as redes do hospital e da prefeitura são interligadas por fibra do provedor de internet que é o mesmo.)
1 pfSense.fhomuv.net (192.168.1.9) (meu gateway ele tem o ip 192.168.12.9 também)
2 192.168.12.1 (192.168.12.1) (Equipamento de fibra do provedor de internet)
3 172.16.254.1 (172.16.254.1) (Equipamento do provedor)
4 172.16.21.253 (172.16.21.253) (Equipamento do provedor)
5 vector156.fhomuv.net (192.168.13.156) (Servidor de aplicação)Observação: Eu acesso o servidor de aplicação por remote desktop. O servidor precisa acessar meu printserver (192.168.12.9), eles se pingam mas quando vou adicionar uma impressora ou mandar uma impressão simplesmente trava tudo por causa dessa regra. Ela trava a comunicação que sai do printserver 192.168.12.9 na porta 631 e deveria ir para o servidor 192.168.13.156.
-
@tifhomuv said in Regra oculta no pfsense:
O servidor precisa acessar meu printserver (192.168.12.9), eles se pingam mas quando vou
Infelizmente não deu para entender a sua explicação
Pelo que eu entendi até agora:
Cliente acessando o servidor de impressão chega com o IP: 172.16.254.1
Servidor de impressão: 192.168.12.10Simplificando, seria isso?
Nesse caso, você enxerga bloqueio de TCP:SA (retorno de pacote que no seu caso acredito estar associado a assimetria), de uma regra que diz que o pacote não está vindo da rede atrás da interface xn0.
-
@mcury Na verdade o cenário seria esse da figura:
O servidor de aplicação tem uma impressora instalada que está no servidor de impressão. Quando tento mandar imprimir o servidor de aplicação trava porque não recebe resposta.
Quando vou olhar no firewall o log mostra o bloqueio da rede 192.168.12.0 conforme inicio do post.
Pelo que entendi o servidor de aplicação alcança o de impressão, mas na volta o de impressão não consegue retornar para o de aplicação por causa dessa regra que não fui eu quem criei. -
Lá na interface WAN que conecta ao modem 192.168.12.1, confirma se isso está habilitado, se estiver desabilite e tente novamente:
-
@mcury Está desabilitado. Um amigo já tinha dado esta dica por já estar atraz do firewall do provedor. O PFSense estou usando mais é para gerenciamento da rede local, dhcp, dns, proxy entre outros serviços de rede.
-
Tem um NAT no modem da ISP, então o pacote vindo da origem chega como 172.16.254.1.
O pacote chega no servidor de impressão, e tenta retornar, onde o pfsense bloqueia..
Pode confirmar se o gateway configurado no servidor de impressão está correto?
Deveria ser 192.168.12.9 o gateway, me parece que você configurou 192.168.12.10? -
Lá nos logs do pfsense, você enxerga o TCP:S ou apenas o TCP:SYN ACK com bloqueio?
Confirma se a regra que permite o acesso está com a opção de logar as solicitações, ai tenta de novo e confirma se o primeiro pacote da conexão, que é um TCP:S está sendo permitido pelo firewall..Nos seus logs só dá para ver o TCP:SYN ACK sendo bloqueado
-
@mcury Na verdade eu filtrando o log do printserver é esse o resultado:
E não há regra de bloqueio nem de liberação, estou com as regras padrões do PFSense, lembrando que eu acesso o servidor de aplicação, uso o sistema normalmente via remote desktop.
Mas segue o print das regras.
Lan:
Wan:
-
Se você não enxerga o SYN, é porque você está com algum tipo de assimetria na sua rede.
O three way handshake do TCP funciona da seguinte forma:
1- SYN
2 - SYN ACK
3 - ACKSe o pfsense não enxerga o primeiro pacote SYN, ele vai bloquear o resto dos pacotes que tentarem passar.
Por isso acredito que você tenha algum tipo de assimetria na sua rede, onde o pfsense não recebe o SYN, e quando chega a resposta do servidor de impressão SYN ACK, ele bloqueia.
-
@mcury Tem alguma sugestão do que devo fazer?
-
Garanta que o pacote está fazendo o mesmo caminho, na ida e na volta.
cliente -> Gateway A ---Provedora--- Gateway B -> servidor
servidor -> Gateway B --- Provedora --- Gateway A -> clienteSe o pacote está chegando por um gateway e o servidor devolvendo por outro, o problema acontece..
As vezes o servidor tem mais de uma placa de rede, e se ele não tiver uma rota específica para devolver por uma placa de rede, ele pode devolver pela rota default, que pode não ser a placa de rede por onde o pacote chegou, causando a assimetria.
Você pode fazer uma captura de pacotes para ajudar a identificar o problema.