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

    Problema com roteamento em Tunel de VPN - IPSEC

    Scheduled Pinned Locked Moved Portuguese
    16 Posts 2 Posters 16.0k 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.
    • F Offline
      fneto
      last edited by

      Essa é a resposta que tive, quando o pacote volta, o mesmo está querendo ser roteado diretamente para a rede sem sair como o ip 172.x.x.x

      11:26:29.513032 IP (tos 0x0, ttl 64, id 28572, offset 0, flags [none], proto ICMP (1), length 100)
          10.1.1.2 > 10.18.31.252: ICMP echo reply, id 1, seq 44763, length 80

      1 Reply Last reply Reply Quote 0
      • marcellocM Offline
        marcelloc
        last edited by

        11:26:29.513032 IP (tos 0x0, ttl 64, id 28572, offset 0, flags [none], proto ICMP (1), length 100)
           10.1.1.2 > 10.18.31.252: ICMP echo reply, id 1, seq 44763, length 80

        10.18 é o ip de um de seus servidores?

        tenta acertar o acesso de tal forma que voce tenha pacotes neste padrão

        entendendo que 10.1.1.2 é o ip da empresa remota e 172.45.0.10 é um dos ips virutais do seu firewall

        na interface ipsec o tcpdump mostra: 10.1.1.2 > 172.45.0.10

        e na lan o pacote sai desta forma 172.45.0.10 > 10.18.31.252

        Treinamentos de Elite: http://sys-squad.com

        Help a community developer! ;D

        1 Reply Last reply Reply Quote 0
        • F Offline
          fneto
          last edited by

          Não marcelo, você entendeu ao contrário!

          10.1.1.2 é o ip do equipamento que será monitorado na minha rede local

          172.45.0.10 é o ip virtual que meu firewall deveria responder e encaminhar para o ip 10.1.1.2

          já o ip 10.18.31.252 é o ip da empresa remota que fará o monitoramento!

          Na interface ipsec o tcpdump mostra o seguinte:

          12:55:32.559121 (authentic,confidential): SPI 0x091b13c0: IP (tos 0x0, ttl 125, id 51748, offset 0, flags [none], proto ICMP (1), length 60)
              10.18.31.252 > 172.45.0.10: ICMP echo request, id 43542, seq 32514, length 40

          Na interface em0 (rede local) mostra o seguinte
          10.18.31.252 > 10.1.1.2: ICMP echo request, id 43542, seq 34306, length 40
              10.1.1.2 > 10.18.31.252: ICMP echo reply, id 43542, seq 34306, length 40

          o problema é que o pacote com destino a rede 10.18.31.252 não é injetado no túnel ipsec quando volta da minha rede.

          Verifiquei a minha tabela de roteamento e não existe nenhuma rota para a rede 10.18.0.0 declarada isso é normal no ipsec??

          Outra coisa no final o ipsec informa que x pacotes foram recebidos pelo filtro e 0 foram dropados pelo kernel!

          E o principal, se na vpn declarar ao invés desses ips 172 a minha rede local 10.1.1.0/24 a VPN vai beleza sem problema nenhum, porém não posso deixar de usar esses benditos ips!!!

          Será que se criar uma interface de rede exclusiva para isso não resolveria o problema?? Tipo, adiciono uma nova placa de rede e dou o ip 172.45.0.10 para ela e coloco o ip .11 como alias dessa interface. Será que daí não vai??

          1 Reply Last reply Reply Quote 0
          • marcellocM Offline
            marcelloc
            last edited by

            Na configuração do ipsec(pelo menos na versão 1.2.3), voce informava a rede remota.

            Você consegue encontrar esta configuração no setup do seu ipsec?

            Treinamentos de Elite: http://sys-squad.com

            Help a community developer! ;D

            1 Reply Last reply Reply Quote 0
            • F Offline
              fneto
              last edited by

              Sim, a configuração da rede local e remota esta na fase 2 do túnel.

              No caso eu configurei a rede remota como 10.18.0.0/16 e a rede local como 172.45.0.0/24.

              1 Reply Last reply Reply Quote 0
              • marcellocM Offline
                marcelloc
                last edited by

                Consegue fazer o teste do tcpdump + nat como te falei?

                Treinamentos de Elite: http://sys-squad.com

                Help a community developer! ;D

                1 Reply Last reply Reply Quote 0
                • F Offline
                  fneto
                  last edited by

                  Não entendi exatamente como quer que eu teste!

                  a interface da rede local é em0, a da internet é a em2 e a vpn enc0

                  Qual a sintaxe que você quer que eu use no pfsense!

                  1 Reply Last reply Reply Quote 0
                  • F Offline
                    fneto
                    last edited by

                    Então Marcelo, eu pesquisei um pouco mais e acho que sei onde o problema pode estar acontecendo.

                    Parece que o racoon (Ipsec) não se dá muito bem quando tem NAT envolvido no meio da rede.

                    Eu ainda não decobri muito bem a lógica do fluxo de pacotes mas com certeza isso tem a ver.

                    Outra coisa, parece que com o Racoon terei que criar políticas (SPD) para dizer qual tráfego deverá ser encriptado e qual não. Quanto ativo a VPN ela cria o tráfego apenas para a rede 172.45.x.x mas não permite a entrada do tráfego proveniente da rede 10.1.1 neste mesmo túnel.

                    Posso estar enganado mas acredito que a resposta está por aí. Espero ter ajudado também a você entender melhor o meu problema!!

                    Abraços!!!

                    1 Reply Last reply Reply Quote 0
                    • marcellocM Offline
                      marcelloc
                      last edited by

                      É exatamente isto que estou tentando te falar, se não quiser tentar por nat, instale o haproxy e configure todos os serviços que você precisa disponibilizar para a rede remota no ip 172.45.0.10.

                      O resultado via tcpdump precisa ficar assim:

                      tcpdump -ni enc0
                      10.18.31.252 -> 172.45.0.10
                      172.45.0.10 -> 10.18.31.252

                      tcpdump -ni em0 host 10.1.1.2 or host 172.45.0.10 or host 10.18.31.252
                      172.45.0.10 -> 10.1.1.2
                      10.1.1.2 -> 172.45.0.10

                      Treinamentos de Elite: http://sys-squad.com

                      Help a community developer! ;D

                      1 Reply Last reply Reply Quote 0
                      • F Offline
                        fneto
                        last edited by

                        Oá Marcelo, provisoriamente fiz o seguinte, adicionei uma nova interface no firewall e configurei com o ip 172.45 nela, um dos 2 que a empresa passou, o outro ip coloquei como adicional em um servidor linux que tinha também, daí faço o nat direto nele para o equipamento.

                        Porém como só tenho 2 ips nessa rede que foi fornecida (mascara final 252) só tenho agora 1 equipamento mnitorado. Estou tentando verificar se consigo uma rede com mascara final 248, daí posso colocar um ip direto no firewall e troco o ip dos equipamentos para essa faixa de rede.

                        Como isso não é a melhor solução e não sei se conseguirei mais ips eu estou tentando ativar o HAProxy, consegui configurar ele sem dificuldades, porém surgiu uma dúvida, na configuração do front end na lista de interfaces ele só me dá a opção interface address ou any, e não me deixa escolher a interface com o ip 172.45.

                        Tenho que fazer alguma configuração anterior para conseguir selecionar a interface 172 no HAProxy frontend???

                        Abraços!!

                        E Caso não nos falemos mais um ótimo ano novo para você e seus familiares!!!

                        E para todo o pessoal do fórum também!! Abraços a todos!

                        1 Reply Last reply Reply Quote 0
                        • F FelipeMagalhaes referenced this topic on
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.