Default deny rule IPV4
-
Salve pessoal! Tudo bem com vocês?
Bom, sou bem novo no pfSense e infelizmente, devido ao meu cenário, estou tendo bastante dificuldades.
Trabalho em uma empresa de monitoramento de alarmes então meu cenário é bem tenso, não podem haver erros.Em meu servidor de testes instalei o pfSense 2.2.2 + squid3 0.2.8 + squidGuard 1.9.14 e tudo está funcionando relativamente bem com relação à navegação e bloqueios necessários. Inclusive com failover entre meus links de internet.
O problema é que estou configurando o pfSense para substituir um Cisco Router que tenho hoje.
Tenho dois links de internet, portanto, no meu pfSense, configurei as WANs (WAN1 e WAN2 em failover) e uma LAN (172.16.0.1) para minha rede de teste.
Dentro da rede, tenho um servidor de aplicação que escuta as portas 9009 e 9876 e fora da rede tenho inúmeros equipamentos de alarme que se conectam ao meu servidor pela internet.
Ficaria algo como:
Central de alarme <-> Internet <-> Modem <-> pfSense <-> Servidor de aplicaçãoConfigurei o balanceamento entre os links, configurei NAT da WAN1 e WAN2 para o IP do servidor de aplicação (172.16.0.51) pelas portas 9009 e 9876, em Firewall>Rules configurei em cada regra criada pelo NAT a opção avançada TCP Flags para Any Flags e State Type para Sloopy State e, mesmo após tudo isso, continuo tendo pacotes bloqueados sendo logados com o seguinte erro:
@5 block drop in log inet all label "Default deny rule IPv4"
Uma particularidade da WAN2 é que, nesse link, eu tenho 5 IPs públicos. Ou seja, um deles está setado como IP da interface (.234) e os outros quatro IPs (.235, .236, .237 e .238) estão configurados como IPs Virtuais da interface WAN2 para que essa interface responda por todos os IPs públicos deste link (fiz certo?).
Em System>Advanced>Firewall/NAT, no campo Static route filtering marquei a opção Bypass firewall rules for traffic on the same interface (como visto em https://forum.pfsense.org/index.php?topic=77360.msg421692#msg421692) mas também não surtiu resultado algum.
Alguém pode me dar uma ajuda, não sei o que ainda pode ser. :-\
Muito grato desde já,
-
bom dia,
já tentou realizar o nat sem as opções avançadas adicionando a rule automaticamente?
poderia postar a regra de nat e as rules?
os pacotes bloqueados são para a porta 9009 e 9876 certo?
Tanto a WAN1 e WAN2 estão com IPs públicos? Como estão as opções de " Block private networks" e " Block bogon networks "? -
Olá shamuel_, tudo bem?
Obrigado pela resposta!
Confesso que mal dormi noite passada pensando nesse problema e em como resolvê-lo.
MAS… Enfim, resolvi. Vou postar agora o que me pediu e as soluções que tomei, talvez você tenha alguma ideia melhor de como resolver os problemas.
Os primeiros testes que eu fiz foram com as rules criadas automaticamente pelo NAT, não deram certo mas foi por um motivo justo que eu vou explicar no final do post.
ANTES
Em NAT estava da seguinte forma:
Tab Port Forward
WAN1 TCP/UDP * * WAN1 address 9009 172.16.0.51 9009 Allow Intelbras GPRS ConnectionsWAN1 TCP/UDP * * WAN1 address 9876 172.16.0.51 9876 Allow JFL GPRS Connections
WAN2 TCP/UDP * * WAN2 address 9009 172.16.0.51 9009 Allow Intelbras GPRS Connections
WAN2 TCP/UDP * * WAN2 address 9876 172.16.0.51 9876 Allow JFL GPRS Connections
Em Rules estavam:
Tab WAN1
IPv4 TCP/UDP * * 172.16.0.51 9009 * none NAT Allow Intelbras GPRS ConnectionsIPv4 TCP/UDP * * 172.16.0.51 9876 * none NAT Allow JFL GPRS Connections
Tab WAN2
IPv4 TCP/UDP * * 172.16.0.51 9009 * none NAT Allow Intelbras GPRS ConnectionsIPv4 TCP/UDP * * 172.16.0.51 9876 * none NAT Allow JFL GPRS Connections
Em ambas as interfaces, Block Private Networks estão desabilitados e Block Bogon Networks estão habilitados.
A WAN1 é ADSL e tem um IP público mas tem um modem para fazer o serviço de PPPoE. No modem já fiz os devidos redirecionamentos.
A rede que o modem cria é a 10.0.0.0/8, onde a interface da WAN1 do meu pfSense é o 10.0.0.3/8 (mas isso talvêz eu mude depois que tudo estiver ok, deixei assim apenas porque eu precisava de acesso à internet tanto da rede de teste do pfSense quanto da rede de produção).
A WAN2 é um link dedicado. Tem um range de 5 IPs públicos. Por isso configurei um deles (o .234) e criei Virtual IPs na interface WAN2 com os demais IPs da range. Como tenho apenas uma aplicação para responder por estes IPs, não queria usar o NAT 1:1 (que é como uso hoje e não me agrado).Fiz uma pesquisa mais abrangente sobre o erro e vi que é um bloqueio feito porque a conexão ou pacote recebido não se enquadra em nenhuma regra de liberação (certo?). Logo concluí que não eram regras incorretas e sim falta de regras. Eu tinha também habilitado ICMP para as intefaces WANs para fins de monitoramento e, com isso, eu conseguia pingar o IP .234 da WAN2 mas não conseguia pingar os IPs virtuais.
Testei algumas configurações e fiz o seguinte:- Criei um Alias chamado IPs_EMBRATEL e coloquei os quatro Virtual IPs (.235 ~ .238).
- Adicionei os Alias nas regras do NAT:
WAN1 TCP/UDP * * WAN1 address 9009 172.16.0.51 9009 Allow Intelbras GPRS Connections
WAN1 TCP/UDP * * WAN1 address 9876 172.16.0.51 9876 Allow JFL GPRS Connections
WAN2 TCP/UDP * * WAN2 address 9009 172.16.0.51 9009 Allow Intelbras GPRS Connections
WAN2 TCP/UDP * * WAN2 address 9876 172.16.0.51 9876 Allow JFL GPRS Connections
**WAN2 TCP/UDP * * IPs_EMBRATEL 9009 172.16.0.51 9009 Allow Intelbras GPRS Connection V_IP
WAN2 TCP/UDP * * IPs_EMBRATEL 9876 172.16.0.51 9876 Allow JFL GPRS Connection V_IP**
- Isso adicionou novas rules em Tab WAN2 como pode ser visto a seguir:
Tab WAN2
IPv4 TCP/UDP * * 172.16.0.51 9009 * none NAT Allow Intelbras GPRS Connections
IPv4 TCP/UDP * * 172.16.0.51 9876 * none NAT Allow JFL GPRS Connections
**IPv4 TCP/UDP * * 172.16.0.51 9009 * none NAT Allow Intelbras GPRS Connection V_IP
IPv4 TCP/UDP * * 172.16.0.51 9876 * none NAT Allow JFL GPRS Connection V_IP**
Com isso feito, as conexões já estariam prontas para chegar ao pfSense sem serem bloqueadas pois haviam regras para todas as entradas (inclusive, também criei uma regra habilitando ICMP aos IPs_EMBRATEL para verificar se todos estavam respondendo).
Iniciando os testes, verifiquei que vários pacotes começaram a ser barrados no firewall mesmo assim MAS, como dito no começo dessa redação, a causa era justa.
Todas as centrais de alarme estavam em uma conexão estabelecida com o servidor na outra rede pelos mesmos IPs da WAN2 do pfSense. Para testar, tive que desplugar o cabo do Router Cisco e conectar ao pfSense, lógico. Com isso as conexões não estavam sendo finalizadas, apenas ficavam "quebradas" e os pacotes que o firewall estava bloqueando eram TCP:FAs, que estavam sendo enviados para reestabelecer uma conexão já existente mas o pfSense desconhecia essas conexões, então nada mais certo do que bloquear tudo.
Reiniciei o bridge link da Embratel e as conexões foram resetadas.
Assim que começaram a chegar pedidos de conexão (TCP:S) o pfSense autorizava a passagem e as conexões eram estabelecidas normalmente.Ufa, um belo texto, não? Hahaha.
Bom, se você tiver alguma ideia de como melhorar esse cenário, por favor, não exite em postar. Estou super aberto à novas ideias.
Espero que esse post também possa ajudar os outros colegas do fórum que, por acaso, passarem por uma situação semelhante.Atenciosamente,