1. Home
  2. pfSense International Support
  3. Portuguese
  4. [RESOLVIDO] Host pfsense acessando serviços em redes openvpn

[RESOLVIDO] Host pfsense acessando serviços em redes openvpn

  • M

    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 ms

    O 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't_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 ovpnc2

    Como 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.

    0
  • P

    @maguiar:

    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 ms

    O 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't_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 ovpnc2

    Como 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.

    0
  • M

    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 tables

    Internet:
    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      ovpnc2

    TRACE 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:

    0
  • P

    @maguiar:

    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 tables

    Internet:
    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      ovpnc2

    TRACE 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/24

    Quem são os gateways ?

    0
  • M

    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.

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

© 2020 Rubicon Communications, LLC | Privacy Policy