Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved Portuguese
    5 Posts 2 Posters 816 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      maguiar
      last edited by

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

      1 Reply Last reply Reply Quote 0
      • P
        pskinfra
        last edited by

        @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%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 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.

        --
        E-mail: tleite@bsd.com.br
        Whatsapp: (021) 9 6403-5250

        1 Reply Last reply Reply Quote 0
        • M
          maguiar
          last edited by

          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:

          1 Reply Last reply Reply Quote 0
          • P
            pskinfra
            last edited by

            @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 ?

            --
            E-mail: tleite@bsd.com.br
            Whatsapp: (021) 9 6403-5250

            1 Reply Last reply Reply Quote 0
            • M
              maguiar
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.