[resolvido]Emails não funcionam apenas no Link da Copel
-
Boa tarde a todos, tenho dois Servidores PFSense em duas matrizes aqui na cidade e estou com um novo problema, já pesquisei em tudo lugar mais só achei algo nesse linkhttp://lists.pfsense.org/pipermail/pfsense-pt/2013-March/001679.html o que não resolveu!
Tenho dois Links chegando nas placas Wan's do Servidor do PFSENSE, versão 2.1.5(amd64), GVT e COPEL, fazendo Balanceamento, tudo funcionando certinho, proxy transparente, Squid3-dev 3.3.10, SquidGuard Squid3 1.4, com certificados para bloquear as solicitações https, seguindo o tutorial do Marcelloc https://forum.pfsense.org/index.php/topic,62263.00html e o do Joao Batistahttps://www.youtube.com/watch?v=neXcYtFDRLA, VPN interligando as duas matrizes seguindo o tutorial do Brivaldo Junior https://www.youtube.com/watch?v=nCGKIIEXU7Q, tudo perfeito acessando entre elas, perfeito, até que hoje me deparei com um problema que nem tinha percebido que ocorria!
Se eu escrever algo errado ou sem sentido é porque estou com um pouco de pressa!
Quando caiu o link da GVT, que era a internet que estava no LB(load balance) como 2° opção nas regras para as conexões das portas, 110,587,995,993,465, ou seja, todas que usam emails, os emails pararam de funcionar, ai então fui la e mudei a opção do Gateway apenas para a copel, achando que tinha algo errado no LB, mas mesmo assim nada de funcionar, coloquei o Gateway como Default, e mesmo assim nada, verifiquei se tinha algo bloqueando no firewall, e as liberações estavam tudo ok, liberadas as portas, mostrando origem e destino, normal, então, percebi também que alguns sites não abriam pela copel, sendo assim, fiz o teste na minha outra matriz tirando todas as saidas das mesmas portas deixando apenas pelo link da copel, mesma coisa, não funciona, alguns sites não abrem, os emails não funcionam, não sei o que fazer, pois fiquei sem a GVT hoje por 4 horas, e durante esse tempo, a empresa parou com emails.
O detalhe maior, é que eu configurei um IP publico da copel direto na minha maquina e o mesmo funciona normal, abre tudo, recebe e envia emails normalmente, é eu colocar no PFSense, seja qual for deles(matriz1 ou matriz2) para de funcionar! Ja pesquisei e ache algo pra mudar as configurações de MTU e MSS, nas configs das interfaces, mas nada, não funciona por nada, tentei ate mudar o ip publico do firewall e nada alguém poderia me ajudar?
-
Chegou a verificar se o problema não são os DNS que não estão resolvendo? Tem DNS específico para a rede da copel ou esta tentando usar um DNS da GVT através da copel? Ja aconteceu isso comigo, estava usando dns errado e quando a rede da OI caiu a outra tabem pois estava usando um dns da OI na outra rede que estava fora do ar.
-
reinaldo.feitosa, vou tentar quando chegar la daqui a pouco e ja falo, nao tinha pensado nisso ainda!
-
Eu uso os DNS do Google, conforme imagem abaixo, deixando as opções "Use Gateway" como none em todas!
Será que está errado?, alguém faz diferente?
-
Eu uso o dns oficial de cada operadora especificando o Gateway, pois pode haver algum bloqueio de DNS externo na operadora e deixo o do google nome como opcional.
-
Fiz o procedimento mas mesmo assim não funciona os emails, ai Jesuis, não sei mais o que fazer, se a GVT cair novamente vai parar tudo de novo :-\ :'(:
-
Será que ninguém passou por isso ou outro Link? Será que é algo na Copel? o estranho é que direto no pc funciona!
-
Posta suas regras da interface LAN
-
Sera que adianta? Pois cheguei a liberar a regra padrao que libera todas as portas para todas as origens e destinos com o gateway da copel, e o pior, no outro link funciona normal
-
Então tudo indica que o problema é a rede da copel. Ja testou ele direto em um computador?
-
Sim, falei ali em cima, direto no computador funciona normalmente!
-
Duas sugestões:
-
Desmarcar o allow dns server to be overwriten… e marcar o do no use Dns forwarder
-
Monitorar via tcpdump as requisições para o servidor via link da copel
-
-
OK marcelloc, vou tentar!
Obrigado por enquanto… -
marcelloc, boa tarde, quanto as opções que me passou mudei, mas não funcionou.
Agora, não sei se estou errado, mas mesmo liberando a regra padrão: "Default allow LAN IPv4 to any rule", saindo pelo Gateway da Copel, acho que não teria o que mostrar no tcpdump não é? ou ele mostra algo a mais além dos endereços e portas? Pois fiz o teste e ele me mostra os mesmos endereços e portas que no firewall logs:
Olha o erro que sempre aparece no Gerenciador de emails:
olha os resultados do TCPDUMP:
Esse filtrei por porta:[2.1.5-RELEASE][admin@fw-pl.pl.local]/root(13): tcpdump -nn -ni re2 src host 10.1.3.111 and dst port 110 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re2, link-type EN10MB (Ethernet), capture size 96 bytes 17:12:39.339219 IP 10.1.3.111.50257 > 192.185.216.95.110: Flags [s], seq 3219110602, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:12:42.334694 IP 10.1.3.111.50257 > 192.185.216.95.110: Flags [s], seq 3219110602, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:12:48.340358 IP 10.1.3.111.50257 > 192.185.216.95.110: Flags [s], seq 3219110602, win 8192, options [mss 1460,nop,nop,sackOK], length 0 17:13:00.356980 IP 10.1.3.111.50258 > 192.185.216.95.110: Flags [s], seq 2235869731, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:13:03.363095 IP 10.1.3.111.50258 > 192.185.216.95.110: Flags [s], seq 2235869731, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:13:09.368679 IP 10.1.3.111.50258 > 192.185.216.95.110: Flags [s], seq 2235869731, win 8192, options [mss 1460,nop,nop,sackOK], length 0 ^C 6 packets captured 62 packets received by filter 0 packets dropped by kernel [b]Esse filtrei por ip do host:[/b] [code][2.1.5-RELEASE][admin@fw-pl.pl.local]/root(14): tcpdump -nn -ni re2 host 10.1.3.111 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re2, link-type EN10MB (Ethernet), capture size 96 bytes 17:14:29.740560 ARP, Request who-has 10.1.3.1 tell 10.1.3.111, length 46 17:14:29.740578 ARP, Reply 10.1.3.1 is-at 00:1a:3f:66:0f:49, length 28 17:14:29.742674 IP 10.1.3.111.50259 > 192.185.216.95.110: Flags [s], seq 2092259479, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:14:32.748237 IP 10.1.3.111.50259 > 192.185.216.95.110: Flags [s], seq 2092259479, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:14:38.754488 IP 10.1.3.111.50259 > 192.185.216.95.110: Flags [s], seq 2092259479, win 8192, options [mss 1460,nop,nop,sackOK], length 0 17:14:50.769891 IP 10.1.3.111.50260 > 192.185.216.95.110: Flags [s], seq 1114360082, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:14:53.792053 IP 10.1.3.111.50260 > 192.185.216.95.110: Flags [s], seq 1114360082, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:14:59.798420 IP 10.1.3.111.50260 > 192.185.216.95.110: Flags [s], seq 1114360082, win 8192, options [mss 1460,nop,nop,sackOK], length 0 17:15:07.881355 IP 10.1.3.111 > 224.0.0.252: igmp v2 report 224.0.0.252 17:15:08.377956 IP 10.1.3.111 > 239.255.255.250: igmp v2 report 239.255.255.250 17:15:39.239543 IP 77.234.41.63.80 > 10.1.3.111.49185: Flags [P.], ack 1828825761, win 2, length 154 17:15:39.449729 ARP, Request who-has 10.1.3.1 tell 10.1.3.111, length 46 17:15:39.449742 ARP, Reply 10.1.3.1 is-at 00:1a:3f:66:0f:49, length 28 17:15:39.451717 IP 10.1.3.111.49185 > 77.234.41.63.80: Flags [.], ack 154, win 67, length 0 17:15:39.662062 IP 77.234.41.63.80 > 10.1.3.111.49185: Flags [P.], ack 1, win 2, length 214 17:15:39.710014 IP 10.1.3.111.49185 > 77.234.41.63.80: Flags [P.], ack 368, win 67, length 278 17:15:39.919955 IP 77.234.41.63.80 > 10.1.3.111.49185: Flags [.], ack 279, win 2, length 0 ^C 17 packets captured 119 packets received by filter 0 packets dropped by kernel [b]Esse filtrei pelo IP de destino:[/b] [code][2.1.5-RELEASE][admin@fw-pl.pl.local]/root(16): tcpdump -nn -ni re0 host 192.185.216.95 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes 17:18:33.948078 IP 200.150.74.171.24161 > 192.185.216.95.110: Flags [s], seq 3359416536, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:18:36.956789 IP 200.150.74.171.24161 > 192.185.216.95.110: Flags [s], seq 3359416536, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:18:42.962713 IP 200.150.74.171.24161 > 192.185.216.95.110: Flags [s], seq 3359416536, win 8192, options [mss 1460,nop,nop,sackOK], length 0 17:18:54.981771 IP 200.150.74.171.23301 > 192.185.216.95.110: Flags [s], seq 2619394052, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:18:57.987279 IP 200.150.74.171.23301 > 192.185.216.95.110: Flags [s], seq 2619394052, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 17:19:03.993783 IP 200.150.74.171.23301 > 192.185.216.95.110: Flags [s], seq 2619394052, win 8192, options [mss 1460,nop,nop,sackOK], length 0 ^C 6 packets captured 42761 packets received by filter 0 packets dropped by kernel Será que os comandos estão certos?[/s][/s][/s][/s][/s][/s][/code][/s][/s][/s][/s][/s][/s][/code][/s][/s][/s][/s][/s][/s] -
Se a re0 é a sua interface da copel, pode encaminhar os dumps para eles. Seu firewall está enviando o trafego mas a conexão não é estabelecida.
-
A interface re0 é sim da copel, desculpe a ignorância, mas o que seria "dumps", encaminhar pra quem? não entendi :-[
-
O que tudo indica é que seu provedor não está aceitando conexões a partir do seu ip da copel.
Os dumps são a saída do tcpdump que você postou, abra chamado no provedor e na operadora se for o caso.
-
Então marcelloc, mas se eu configuro num computador um IP Público da copel funciona normal, somente no firewall que não vai!
Inclusive estou usando a muito tempo um IP fixo (publico) direto no meu micro! -
Um ip público ou o mesmo ip público? Faz um teste mudando o ip público do firewall.
O tcpdump mostra o pacote saindo do firewall com a tradução do nat e tudo mais.
-
OK, vou colocar o endereço IP público que estou usando aqui na minha maquina!
