[RESOLVIDO] Host pfsense acessando serviços em redes openvpn
-
Prezados,
Tenho um cliente que possui uma matriz e seis filiais todas conectadas por OPENVPN, todas as redes internas utilizam um classe C privado.
192.168.0.0/24 matriz e 192.168.101.0/24 até 192.168.106.0/24 filiais.
Devido ao fato do cliente possuir telefonia VOIP todas as redes se comunicam entre sim sem problema algum.
Para facilitar a administração do ambiente configuramos autenticação do pfsense no Active Directory o que está funcionando perfeitamente no site onde fica o próprio pfSense.
Exemplo: pfSense (192.168.0.2) faz login via LDAP no AD (192.168.0.10) com sucesso (inclusive utilizando LDAPS - isso deu um baita trabalho).
Agora o problema:
Os pfSense remotos não conseguem se autenticar no servidor AD.
A conectividade entre o host pfSense remoto e o servidor AD não acontece.
Em Diagnostics –-> Ping quando tento acessar o servidor AD deixando o campo "Source address" em "Automatically selected (default) as vezes funciona por um tempo e depois para, quando utilizo o "Source address" "LAN" eu tenho sucesso no acesso.
Aqui se vê o resultado do ping
[2.4.2-RELEASE][admin@xxxxxx.com.br]/root: ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10): 56 data bytes
^C
–- 192.168.0.10 ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss[2.4.2-RELEASE][admin@xxxxx.com.br]/root: ping -S 192.168.104.1 192.168.0.10
PING 192.168.0.10 (192.168.0.10) from 192.168.104.1: 56 data bytes
64 bytes from 192.168.0.10: icmp_seq=0 ttl=127 time=2.505 ms
64 bytes from 192.168.0.10: icmp_seq=1 ttl=127 time=2.066 ms
64 bytes from 192.168.0.10: icmp_seq=2 ttl=127 time=2.857 ms
64 bytes from 192.168.0.10: icmp_seq=3 ttl=127 time=2.208 ms
^C
–- 192.168.0.10 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.066/2.409/2.857/0.303 msO problema se assemelha ao relatado abaixo, porém por se tratar de outra VPN a solução não se aplica.
https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN
IPv4 Routes
Destination Gateway Flags Use Mtu Netif Expire
default 189.8.91.201 UGS 1625133 1500 rl0
8.8.8.8 189.8.91.201 UGHS 110370 1500 rl0
10.0.101.0 link#8 UHS 0 16384 lo0
10.0.101.0/24 10.0.101.1 UGS 0 1500 ovpnc2
10.0.101.1 link#8 UH 0 1500 ovpnc2
127.0.0.1 link#4 UH 55 16384 lo0
189.8.91.200/30 link#1 U 0 1500 rl0
189.8.91.202 link#1 UHS 0 16384 lo0
192.168.0.0/24 10.0.101.1 UGS 1481275 1500 ovpnc2
192.168.24.0/24 10.0.101.1 UGS 40 1500 ovpnc2
192.168.101.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.102.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.103.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.104.0/24 link#3 U 279549 1500 bfe0
192.168.104.1 link#3 UHS 0 16384 lo0
192.168.105.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.106.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.107.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.108.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.109.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.110.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.160.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.180.0/24 10.0.101.1 UGS 2216 1500 ovpnc2
192.168.210.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.220.0/24 10.0.101.1 UGS 0 1500 ovpnc2Como solução de contorno, eu publiquei a porta LDAP do AD no firewall na Matriz (utilizando porta alta fazendo nat para a porta interna do AD), consigo autenticar todos os pfsense, mas fico incomodado do próprio host pfsense nao conseguir conectar nos serviços de outra rede, sendo algo intermitente.
-
Prezados,
Tenho um cliente que possui uma matriz e seis filiais todas conectadas por OPENVPN, todas as redes internas utilizam um classe C privado.
192.168.0.0/24 matriz e 192.168.101.0/24 até 192.168.106.0/24 filiais.
Devido ao fato do cliente possuir telefonia VOIP todas as redes se comunicam entre sim sem problema algum.
Para facilitar a administração do ambiente configuramos autenticação do pfsense no Active Directory o que está funcionando perfeitamente no site onde fica o próprio pfSense.
Exemplo: pfSense (192.168.0.2) faz login via LDAP no AD (192.168.0.10) com sucesso (inclusive utilizando LDAPS - isso deu um baita trabalho).
Agora o problema:
Os pfSense remotos não conseguem se autenticar no servidor AD.
A conectividade entre o host pfSense remoto e o servidor AD não acontece.
Em Diagnostics –-> Ping quando tento acessar o servidor AD deixando o campo "Source address" em "Automatically selected (default) as vezes funciona por um tempo e depois para, quando utilizo o "Source address" "LAN" eu tenho sucesso no acesso.
Aqui se vê o resultado do ping
[2.4.2-RELEASE][admin@xxxxxx.com.br]/root: ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10): 56 data bytes
^C
–- 192.168.0.10 ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss[2.4.2-RELEASE][admin@xxxxx.com.br]/root: ping -S 192.168.104.1 192.168.0.10
PING 192.168.0.10 (192.168.0.10) from 192.168.104.1: 56 data bytes
64 bytes from 192.168.0.10: icmp_seq=0 ttl=127 time=2.505 ms
64 bytes from 192.168.0.10: icmp_seq=1 ttl=127 time=2.066 ms
64 bytes from 192.168.0.10: icmp_seq=2 ttl=127 time=2.857 ms
64 bytes from 192.168.0.10: icmp_seq=3 ttl=127 time=2.208 ms
^C
–- 192.168.0.10 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.066/2.409/2.857/0.303 msO problema se assemelha ao relatado abaixo, porém por se tratar de outra VPN a solução não se aplica.
https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN
IPv4 Routes
Destination Gateway Flags Use Mtu Netif Expire
default 189.8.91.201 UGS 1625133 1500 rl0
8.8.8.8 189.8.91.201 UGHS 110370 1500 rl0
10.0.101.0 link#8 UHS 0 16384 lo0
10.0.101.0/24 10.0.101.1 UGS 0 1500 ovpnc2
10.0.101.1 link#8 UH 0 1500 ovpnc2
127.0.0.1 link#4 UH 55 16384 lo0
189.8.91.200/30 link#1 U 0 1500 rl0
189.8.91.202 link#1 UHS 0 16384 lo0
192.168.0.0/24 10.0.101.1 UGS 1481275 1500 ovpnc2
192.168.24.0/24 10.0.101.1 UGS 40 1500 ovpnc2
192.168.101.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.102.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.103.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.104.0/24 link#3 U 279549 1500 bfe0
192.168.104.1 link#3 UHS 0 16384 lo0
192.168.105.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.106.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.107.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.108.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.109.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.110.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.160.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.180.0/24 10.0.101.1 UGS 2216 1500 ovpnc2
192.168.210.0/24 10.0.101.1 UGS 0 1500 ovpnc2
192.168.220.0/24 10.0.101.1 UGS 0 1500 ovpnc2Como solução de contorno, eu publiquei a porta LDAP do AD no firewall na Matriz (utilizando porta alta fazendo nat para a porta interna do AD), consigo autenticar todos os pfsense, mas fico incomodado do próprio host pfsense nao conseguir conectar nos serviços de outra rede, sendo algo intermitente.
maguiar, quem são os gateways remotos das duas filiais ?
Mostre a saída do "traceroute ou mtr" das origens (gw remotos) para o destino da matriz!
Possivelmente, os gw remotos estão saindo pela rota default (internet ). 8)
Att.
-
prezado, a rota default é pra interface wan.
para as redes da vpn existem rotas apontando para o tunnel, a questão está em como dizer que as redes da vpn saiam pelo tunel e nao pela wan
[2.4.2-RELEASE][admin@unicamp.labfranceschi.com.br]/root: netstat -r
Routing tablesInternet:
Destination Gateway Flags Netif Expire
default 189.8.91.201 UGS rl0
google-public-dns- 189.8.91.201 UGHS rl0
10.0.101.0 link#8 UHS lo0
10.0.101.0/24 10.0.101.1 UGS ovpnc2
10.0.101.1 link#8 UH ovpnc2
10.250.0.0/16 10.0.101.1 UGS ovpnc2
localhost link#4 UH lo0
189.8.91.200/30 link#1 U rl0
189.8.91.202 link#1 UHS lo0
192.168.0.0/24 10.0.101.1 UGS ovpnc2
192.168.24.0/24 10.0.101.1 UGS ovpnc2
192.168.101.0/24 10.0.101.1 UGS ovpnc2
192.168.102.0/24 10.0.101.1 UGS ovpnc2
192.168.103.0/24 10.0.101.1 UGS ovpnc2
192.168.104.0/24 link#3 U bfe0
unicamp link#3 UHS lo0
192.168.105.0/24 10.0.101.1 UGS ovpnc2
192.168.106.0/24 10.0.101.1 UGS ovpnc2
192.168.107.0/24 10.0.101.1 UGS ovpnc2
192.168.108.0/24 10.0.101.1 UGS ovpnc2
192.168.109.0/24 10.0.101.1 UGS ovpnc2
192.168.110.0/24 10.0.101.1 UGS ovpnc2
192.168.160.0/24 10.0.101.1 UGS ovpnc2
192.168.180.0/24 10.0.101.1 UGS ovpnc2
192.168.210.0/24 10.0.101.1 UGS ovpnc2
192.168.220.0/24 10.0.101.1 UGS ovpnc2TRACE padrão:
[2.4.2-RELEASE][admin@asdfasdom.br]/root: traceroute 192.168.0.10
traceroute to 192.168.0.10 (192.168.0.10), 64 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
^C
[2.4.2-RELEASE][admin@asdfacom.br]/root:TRACE usando ip de LAN como origem:
[2.4.2-RELEASE][admin@sfasdcom.br]/root: traceroute -s 192.168.104.1 192.168.0.10
traceroute to 192.168.0.10 (192.168.0.10) from 192.168.104.1, 64 hops max, 40 byte packets
1 10.0.101.1 (10.0.101.1) 2.156 ms 2.243 ms 2.490 ms
2 192.168.0.10 (192.168.0.10) 2.015 ms 2.453 ms 2.496 ms
[2.4.2-RELEASE][admin@adsfasom.br]/root: -
prezado, a rota default é pra interface wan.
para as redes da vpn existem rotas apontando para o tunnel, a questão está em como dizer que as redes da vpn saiam pelo tunel e nao pela wan
[2.4.2-RELEASE][admin@unicamp.labfranceschi.com.br]/root: netstat -r
Routing tablesInternet:
Destination Gateway Flags Netif Expire
default 189.8.91.201 UGS rl0
google-public-dns- 189.8.91.201 UGHS rl0
10.0.101.0 link#8 UHS lo0
10.0.101.0/24 10.0.101.1 UGS ovpnc2
10.0.101.1 link#8 UH ovpnc2
10.250.0.0/16 10.0.101.1 UGS ovpnc2
localhost link#4 UH lo0
189.8.91.200/30 link#1 U rl0
189.8.91.202 link#1 UHS lo0
192.168.0.0/24 10.0.101.1 UGS ovpnc2
192.168.24.0/24 10.0.101.1 UGS ovpnc2
192.168.101.0/24 10.0.101.1 UGS ovpnc2
192.168.102.0/24 10.0.101.1 UGS ovpnc2
192.168.103.0/24 10.0.101.1 UGS ovpnc2
192.168.104.0/24 link#3 U bfe0
unicamp link#3 UHS lo0
192.168.105.0/24 10.0.101.1 UGS ovpnc2
192.168.106.0/24 10.0.101.1 UGS ovpnc2
192.168.107.0/24 10.0.101.1 UGS ovpnc2
192.168.108.0/24 10.0.101.1 UGS ovpnc2
192.168.109.0/24 10.0.101.1 UGS ovpnc2
192.168.110.0/24 10.0.101.1 UGS ovpnc2
192.168.160.0/24 10.0.101.1 UGS ovpnc2
192.168.180.0/24 10.0.101.1 UGS ovpnc2
192.168.210.0/24 10.0.101.1 UGS ovpnc2
192.168.220.0/24 10.0.101.1 UGS ovpnc2TRACE padrão:
[2.4.2-RELEASE][admin@asdfasdom.br]/root: traceroute 192.168.0.10
traceroute to 192.168.0.10 (192.168.0.10), 64 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
^C
[2.4.2-RELEASE][admin@asdfacom.br]/root:TRACE usando ip de LAN como origem:
[2.4.2-RELEASE][admin@sfasdcom.br]/root: traceroute -s 192.168.104.1 192.168.0.10
traceroute to 192.168.0.10 (192.168.0.10) from 192.168.104.1, 64 hops max, 40 byte packets
1 10.0.101.1 (10.0.101.1) 2.156 ms 2.243 ms 2.490 ms
2 192.168.0.10 (192.168.0.10) 2.015 ms 2.453 ms 2.496 ms
[2.4.2-RELEASE][admin@adsfasom.br]/root:Os pfsenses nas redes remotas, são os gw das redes privadas?
Matriz = 192.168.0.0/24
Filial A = 192.168.101.0/24
Filial B = 192.168.106.0/24Quem são os gateways ?
-
Cansado de mexer no ambiente em produção para descobrir o problema e por vezes derrubando todas as conexões resolvi construir um laboratório de maquinas/redes virtuais e segui este tutorial criando um ambiente do zero.
https://forum.pfsense.org/index.php?topic=144212.0
E consegui conectividade entre si entre todos os hosts pfsense também entre hosts pfense e os servidores localizados na matriz.
Com este resultado fui no ambiente de produção e criei um novo openvpn server em porta diferente e comecei a migrar as filiais da antiga configuração para novo com sucesso.
O link acima é muito prático e produz muito pouca configuração nos clientes, controlando quase tudo pela configuração.
Obrigado aos amigos que tentaram ajudar.
Agora vou poder descansar a cabeça, 8) 8) 8) 8), pois faz mais de 7 dias que nao pensava em outra coisa.