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 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
Em Rules estavam:
Tab WAN1
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
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
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,
