Home › Comunidade Brasileira Endian Firewall › Endian Firewall › Endian Firewall – Suporte › Redes usando OpenVPN não se conversam
- Este tópico contém 22 respostas, 11 vozes e foi atualizado pela última vez 10 anos, 11 meses atrás por Eduardo Silva.
- AutorPosts
- junho 16, 2010 às 8:08 pm #373RogerParticipante
Olá pessoal,
Estou tentando montar uma configuração de VPN entre dois Endians 2.4, usando OpenVPN,
mas não estou obtendo sucesso na conectividade entre todas as maquinas envolvidas.
Já vasculhei a internet tanto em sites em inglês como em português para buscar informações
a respeito do meu problema, mas tudo o que encontrei foram referencias a versões anteriores do Endian
ou as soluções propostas não funcionaram.
Minha última cartada é recorrer a algum fórum, e como este fórum aparenta ser bem mais ativo do que
o próprio forum do Endian.com, estou começando por aqui.. 🙂
Esta é a rede em questão:
PC A1 ---| "Rede A"
PC A2 ---+
LAN
Endian A
+
PC A3 ---| (192.168.50.0/24) OPENVPN SERVER |
|
|
| VPN-Tunnel (pela Internet)
|
PC B1 ---| "Rede B" |
PC B2 ---+
LAN
Endian B
+
PC B3 ---| (192.168.1.0/24) OPENVPN GW2GW
Se eu configurar a VPN usando IPSEC, todos os PCs e os Endians das 2 redes se conversam.
Se, porém, eu utilizar OpenVPN Server & OpenVPN Gw2Gw, as coisas não funcionam tão bem.
Maiores detalhes:
Configuração feita no Endian A:
– “Block DHCP responses coming from tunnel” está ligado
– “Don’t block traffic between clients” está ligado
– “Push these networks” está ligado, com estes valores:
192.168.1.0/24
192.168.50.0/24
– Foi criada uma conta de VPN com a configuração “Networks behind client” igual a:
192.168.1.0/24
Green IP: 192.168.50.2/24
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.50.0 * 255.255.255.0 U 0 0 0 br0
189.120.128.0 * 255.255.240.0 U 0 0 0 eth1
default 189.120.128.1 0.0.0.0 UG 0 0 0 eth1Este Endian está numa máquina virtual, dentro do VMWare… vasculhando a internet, achei
referencias sobre a necessidade de permitir o modo promíscuo da interface de rede. Já fiz isso.
Configuração feita no Endian B:
– Na aba “OpenVPN client (Gw2Gw)” foi criado um tunel com o usuario, senha e o upload do certificado do Endian A.
Green IP: 192.168.1.2/24
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.50.0 * 255.255.255.0 U 0 0 0 tap2
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
201.6.246.0 * 255.255.255.0 U 0 0 0 eth1
default c906f601.virtua 0.0.0.0 UG 0 0 0 eth1Todas as configurações a respeito de VPN dos 2 Endians que não foram comentados são porque mantive os valores originais.
Ambos os Endians estão com o Firewall “VPN traffic” desligados.
Eu consigo estabelecer a VPN… o Endian B consegue acessar todas as máquinas da rede A (Endian A, PC’s A1, B1 e C1).
O que não está funcionando:
– os PC’s da rede B (B1, B2 e B3) não conseguem acessar nada da rede A
– nenhuma máquina da rede A consegue acessar alguma máquina da rede B (nem o Endian e nem as máquinas B1, B2 e B3)
Eu já achei diversas referências na internet sobre criar regras no Firewall Outgoing, ou System Access, ou Source NAT, mas nada funcionou como o esperado.
Eu li o tutorial “Passo a Passo VPN”, mas ele menciona que o “Direct all client traffic through the VPN server” deve ser ligado…
mas se eu fizer isso todo o tráfego da rede B com a internet vai acabar passando pela rede A, o que é algo indesejável no meu caso.
Alguém poderia me dar uma pista do que eu devo configurar, a partir da configuração que foi descrita acima ?
Muito obrigado,
Roger
PS: Há algumas semanas atras eu tinha o Endian 2.2 na rede A e o Endian 2.3 na rede B… a configuração que eu necessito
funcionava (e pelo que estou lembrado eu tive que alterar alguma regra de firewall para fazer todas as maquinas se conversarem).
O problema é que houve um problema físico no HD e essa configuração se perdeu… resolvi instalar o Endian mais recente nas duas pontas,
e agora estou travado nesse problema
Wireguard_webadmin
Sistema gratuito (Open Source) para gestão de VPN's WireGuard com uma Web interface intuitiva e fácil de usar.
Principais funcionalidades:
- Sistema de Firewall completo e flexível.
- Encaminhamento de portas
- Suporte a multi usuário com níveis diferentes de acesso
- Múltiplas instâncias do Wireguard
- Crypto key routing para configuração de VPN site-to-siteO projeto é Open Source, fácil de instalar e está disponível em wireguard_webadmin
- junho 17, 2010 às 9:41 am #5148Eduardo SilvaParticipante
Olá Roger,
Bem vindo a comunidade 🙂
Gostei da sua topologia em ASCII, facilitou bastante na visualização do ambiente.
Numa primeira olhada, eu pude observar que no seu endian A você não possui rota para a rede B. Esta pode ser a origem do problema.
Ajuste o problema das rotas e faça novos testes.
Notas:
– Direct all client traffic through the VPN server – No seu caso realmente não é uma boa idéia
– É recomendável utilizar firewall e permitir apenas os protocolos necessários. No firewall do endian existe uma parte reservada apenas para tráfego de VPN. (não é necessário nenhuma regra manual para isto).
– Pessoalmente eu também prefiro o OpenVPN ao invés do IPSec.
[]’s
- junho 17, 2010 às 10:24 am #5149Eduardo SilvaParticipante
Bem, complementando:
Se não for só este problema, vamos debugar um pouco mais a sua rede:
Logue nos dois endians via SSH e digite
iptables -I FORWARD -s 192.168.0.0/16 -d 192.168.0.0/16 -p icmp -j ACCEPT (liberando ping e traceroute)
iptables -I FORWARD -s 192.168.0.0/16 -d 192.168.0.0/16 -p tcp –dport 3389 -j ACCEPT (liberando o TS para teste).
Testes nas redes:
A partir de uma máquina na rede A execute:
– ping para o IP do endian remoto
– ping para uma máquina da rede B
– traceroute para uma máquina da rede B
– Telnet para a porta 3389 de uma máquina da rede B (habilitar o terminal service/remote desktop da máquina em questão).
A partir de uma máquina na rede B execute:
– ping para o IP do endian remoto
– ping para uma máquina da rede A
– traceroute para uma máquina da rede A
– Telnet para a porta 3389 de uma máquina da rede A (habilitar o terminal service/remote desktop da máquina em questão).
* Lembre-se de desativar o firewall das máquinas envolvidas no teste (não o firewall do endian)
* Para remover as regras do iptables inseridas no teste, substitua o -I por -D
* Utilizar o tcpdump no endian (dos dois lados) pode ser MUITO, mas MUITO útil para encontrar o problema. Caso tenha dúvidas sobre como utilizar, escrevi umas dicas aqui: http://linux.eduardosilva.eti.br/canivete-suico-para-redes
* Se todos estes testes forem concluídos com sucesso, as suas rotas estão corretas e você só vai precisar ajustar o seu VPN firewall. Habilite-o e utilize regras apenas pela web interface.
- junho 17, 2010 às 4:32 pm #5150RogerParticipante
Oi Eduardo,
Grato pela recepção e pelas respostas… 🙂
Alguns comentários em relação às suas observações:
* As suspeitas em relação a regras de firewalls nas máquinas PC’s das duas redes não se aplicam, uma vez que consigo pingar e fazer SSH entre elas numa boa quando uso IPSEC entre os 2 Endians.
* Eu havia comentado na minha msg original que ambos os Endians estavan com o Firewall “VPN traffic” desligados. Pela documentação que eu li e pela configuração que eu lembro de ter quando usava Endians 2.2 e 2.3, esse firewall só é utilizado no modo OpenVPN, mas se ele estiver desligado o policy padrão é ACCEPT. Eu já havia inclusive tentado colocar regras do tipo “libera geral” nos 2 Endians, mas não surtiu efeito.
Agora a boa notícia: eu executei esse comando no Endian A:
# route add -net 192.168.1.0/24 192.168.50.221
e tudo passou a funcionar, como se eu estivesse utilizando IPSEC… todas as máquinas passaram a se enxergar. Consegui fazer SSH entre os PC’s das 2 redes, enfim funcionou 100%.
Agora uma pergunta: O Endian não deveria fazer isso automaticamente para mim (a exemplo do que ele faz quando usamos o IPSEC) ?
Perceba que eu usei como gateway o IP 192.168.50.221, mas isso porque o ifconfig rodando no Endian B me mostrou que essa era o IP da interface tap2.
Na minha situação real, vou ter CINCO redes com Endian Gw2Gw2 se conectando no Endian A… não dá para prever qual IP o Endian A vai dar para o Endian da outra ponta [1].
Uma outra forma de configurar a rota (no braço) foi fazer:
# route add -net 192.168.1.0/24 dev tap0
Aí ficou legal… mas o problema é como configurar isso pelo admin do Endian ?
[1] – Dá pra configurar um IP estático para cada conta de usuário do OpenVPN… aí eu poderia fazer:
# route add -net 192.168.1.0/24 IP_ESCOLHIDO_PARA_REDE_X
# route add -net 192.168.2.0/24 IP_ESCOLHIDO_PARA_REDE_Y
# route add -net 192.168.3.0/24 IP_ESCOLHIDO_PARA_REDE_Z
Só que, pelo admin do Endian, eu criei uma rota dessa maneira:
Source Network: <deixei em branco e também testei com 192.168.50.0/24>
Destination Network: 192.168.1.0/24
Route via [Static Gateway] : 192.168.50.221
Só que essa rota não me aparece quando digito “route” no shell do Endian… e só o Endian A passa a enxergar a rede B… as outras maquinas da rede A não conseguem chegar na rede B.
Mas pelo menos já sei que não se trata de regras de firewall.. 🙂
Se você ou mais alguém tiver comentários pra fazer sobre essa situação, sou todo ouvidos. 🙂
- junho 17, 2010 às 9:30 pm #5151RogerParticipante
Novidades !!
Usar roteamento diretamente para o device é uma furada quando se coloca mais uma rede como OpenVPN Gw2Gw:
# route add -net 192.168.1.0/24 dev tap0
# route add -net 192.168.2.0/24 dev tap0
No entanto, ao configurar as rotas pelo admin do Endian, desse jeito:
Source Network: <nao preencher>
Destination Network: 192.168.1.0/24
Route via [Static Gateway] : 192.168.50.221
Source Network: <nao preencher>
Destination Network: 192.168.2.0/24
Route via [Static Gateway] : 192.168.50.222
Funciona muito bem… a única coisa intrigante é o fato dessas rotas não aparecerem quando se executa o comando “route” no shell. As máquinas de todas as redes se enxergam…
Semana que vem vou alterar todos os Endians para usarem OpenVPN… aí eu notifico vocês como foi o resultado (vai que alguma bucha aparece na última hora…)
Abraços
- junho 17, 2010 às 11:09 pm #5152Albaney BaylãoParticipante
O route não funciona por que você está adicionando a rota por dispositivo e não por gw.
Por exemplo, os comandos abaixo funcionariam:
# route add -net 192.168.1.0/24 gw 192.168.50.221
# route add -net 192.168.2.0/24 gw 192.168.50.222
Funcionariam, mas o melhor mesmo é sempre fazer pela interface quando possível.
- junho 18, 2010 às 11:20 am #5153RogerParticipante
Não, não Albaney… você me compreendeu mal…
Mesmo usando a interface do Endian para montar as rotas, como você pode ver nesta imagem:
http://img15.imageshack.us/img15/1827/adminrotas.jpg
Veja como ficou a execução do comando “route”:
root@efw-abc:~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
189.120.128.0 0.0.0.0 255.255.240.0 U 0 0 0 eth1
189.120.128.0 0.0.0.0 255.255.240.0 U 0 0 0 ipsec0
0.0.0.0 189.120.128.1 0.0.0.0 UG 0 0 0 eth1
As rotas estão funcionando, porque se eu desabilitá-las, eu nao consigo mais acessar as maquinas das outras redes. No entanto, o Endian continua não me mostrando as rotas pelo shell.
Se eu executar os “route add -net …” no shell, as rotas funcionam e elas aparecem durante o “route -n”.
- junho 18, 2010 às 12:10 pm #5154Albaney BaylãoParticipante
Não, Roger, você que me compreendeu mal…
O que eu havia dito é apenas sobre o comando fora da interface dando problema.
Quanto a rota ela não aparece mesmo no “route”, use os comandos a seguir para ver o efeito da regra (no meu exemplo a regra criada era a que destinava todo o trafego da rede 192.168 para o gateway 172.16.201.2):
# ip rule show
0: from all lookup local
10: from all to 172.16.201.0/24 lookup main
10: from all to 192.168.0.0/16 lookup 5
10: from all to 10.0.0.0/8 lookup main
199: from all fwmark 0x7e0/0x7f8 lookup uplink-main
200: from 172.16.201.2 lookup uplink-main
200: from 172.16.201.5 lookup uplink-main
32766: from all lookup main
32767: from all lookup default
# ip route show table 5
default via 172.16.201.2 dev eth1
- junho 18, 2010 às 12:41 pm #5155RogerParticipante
Oi Albaney, agora entendi a sua colocação.
Muito bacana esse comando “ip”… achei as minhas rotas agora… 🙂
Grande abraço,
Roger
PS: Não sei quem é o admin do forum, mas poderia sugerir uma coisa ?
Que tal incluírem o “pre” na listagem das marcações permitidas, no rodapé da textarea onde se redigem os posts ?
Esse “pre” já funciona, mas eu fui induzido a achar que não funcionava, ao ver a lista restrita de tags html. Como meu diagrama de rede não ficava legal, apelei para o PRE e por sorte funcionou.
Talvez até fosse bom colocar uma recomendação do uso do PRE ao tentar se digitar texto onde a diagramação seja importante (pode ser que haja pessoas que não manjem muito de html).
Apenas meus 2 modestos centavos… 🙂
- junho 21, 2010 às 8:38 pm #5156Eduardo SilvaParticipante
Roger,
Ao que me conste o “pre” tem o mesmo efeito do “code” que por sua vez tem o mesmo efeito do acento grave (posso estar errado) 😛
Quanto ao forum, estou pensando em implementar algumas coisas, mas ao mesmo tempo estou esbarrando em algumas chatices do bbpress…
Nos próximos dias irei fazer um estudo de viabilidade de migração para uma plataforma mais completa e mais flexível como por exemplo o smf.
Se por algum motivo isto for inviável, vou focar os esforços para melhorar este bbpress.
Obrigado pela sugestão 😉
[]’s
- junho 22, 2010 às 2:47 pm #5157RogerParticipante
Oi Eduardo,
O “pre” tem semelhança com o “code” no sentido de exibir o texto com uma fonte mono-espaçada (um “i” fica com a mesma largura que um “W”)
O “pre”, entretanto, consegue algo a mais… fazer respeitar as quebras de linha sem o uso de “br” a todo instante.
Isso, claro, se não houver uma customização de CSS que bagunce todo o coreto. 🙂
[]s
- setembro 19, 2010 às 1:52 am #5158magraParticipante
Roger e Albaney,
Tenho o mesmo problema do Roger. Estou tentando ligar duas redes através do Endian
1 – Matriz com Open server
2 – Filial – cliente gw2gw
A conexão é estabelecida e do Endian da filial pingo todas as máquinas inclusive pelo nome, porém não consigo fazer com que os pcs acessem nada na rede da matriz, nem ping.
Da matriz, consigo pingar e acessar tudo (ping acesso TS) da filial.
Pergunto: Preciso executar também uma conexão client gw2gw da matriz para filial, ou seja, configurar na filial o Open server e na matriz fechar uma conexão com a filial?
Existe algum passo a passo ensinando a configurar este tipo de conexão?
- setembro 21, 2010 às 2:21 pm #5159Eduardo SilvaParticipante
magra,
Você ressuscitou um post de 3 meses atrás pedindo um passo a passo? Leia o post acima, e tente realizar os testes citados, a maioria das informações acima aplicam-se ao seu ambiente sem maiores adaptações. Tente debugar o seu problema, caso não consiga, crie um novo post explicando detalhadamente o seu ambiente, que testes foram realizados, o que funcionou e o que não funcionou.
Mesmo assim, quanto mais informações você repassar mais fácil fica de ajudar a resolver o seu problema.
[]’s
- setembro 21, 2010 às 3:14 pm #5160magraParticipante
Eduardo, primeiramente muito obrigado pelo feedback.
Executei exatamente os passos descritos acima, porém acho que falta algum detalhe para fazer funcionar a contento. Por isso solicitei um passo a passo.
Hoje eu somente consigo acessar tudo da matriz para a filial, ou seja da rede Openserver para rede onde está o Cliente Gw2gw.
Do cliente GW2GW, somente do Endian é que consigo pingar tudo da rede onde está o Open Server. Nada dos pcs.
Diante disso, comecei a executar algumas alterações que não tiveram efeito. Habilitei no cliente GW2GW a opção bridge.
Meu cenário hoje é:
No firewall: trafego VPN desabilitado em ambos, nada configurado em system acess, tráfego de interzona habilitado, porém com tudo padrão e outgoing com as entradas padrão e incoming sem nada configurado.
- setembro 23, 2010 às 3:44 pm #5161Hugo Cesar OliveiraParticipante
Boa tarde a todos, eu consegui fazer de forma bem simples:
Tenho um Endian 2.4 no Ponto A e outo no ponto B.
Criei uma conta no ponto A e outra no ponto B e depois fui no servidor A e criei uma conexão Gw2Gw do A para o B com o certificado importando do B e depois fiz a mesma coisa no B. As estacõoes da A e da B se falam tranquilamente. Não mexi em nenhuma regra de Firewal. Espero ter ajudado.
- novembro 9, 2010 às 7:44 pm #5162jabinhaParticipante
O minha também funciona perfeito, tenho 16 Redes internas – 12 Filiais, casa das filiais C matriz B , E – Etc ou melhor + 12 redes, usando para link OpenVPN
o tráfego só é liberado nas configurações em tráfego VPn, da filial para Matriz, da Matriz para filial apenas uma simples regras no User quando Criar.
lembrando de aplicar as rotas e regras .
- novembro 9, 2010 às 8:48 pm #5163centenoParticipante
Pessoal…..
Deu preguiça ler tudo. hehehe
Uso VPN DIRETO entre Endians ( Server e GW ) e também só com o Endian como Server e clientes com OPENVPN Client ( Clientes dinâmicos ).
NUNCA precisei mexer em nada de roteamento , etc….a mão. Uso tudo pela ADM WEB, sem stress.
Três coisas para tentar ajudar:
1 – Você está tentando acessar os micros por NOME ou por IP ???
Eu uso sempre por IP. Se sou obrigado a usar nomes ( NETBEUI ), apenas declaro hosts para os micros e pronto.
2 – Eu só EMPURRO ( Push ) as redes que o SERVIDOR conhece. As redes do Cliente, o Cliente já conhece.
3 – Como tá teu Firewall VPN.
Quem sabe tu liga ele, cria uma regra liberando tudo e marcar para gerar LOG.
Espero ter ajudado.
[]´s
- novembro 16, 2010 às 2:30 pm #5164tadaogParticipante
Quem estiver usando VMWare Hypervisor, o default da configuração de placas ethernet é Reject em Promiscuous Mode, que é necessário para roteadores.
Alterar selecionando o host no VSphere Client, na tab Configuration, Networking, alterar todos os vSwitch(es) e VMNetwork(s) para Accept em Promiscuous. Eu particularmente deixo todos os 3 itens em Accept.
E pronto, todo os roteamentos, forwardings passam a funcionar como esperado!
- novembro 18, 2010 às 1:27 pm #5165tadaogParticipante
Não é recomendado devido a problemas nas tabelas de roteamento efetuar conexões gw2gw em ambos os sentidos. O administrador do forum de bug support da Endian garantiu claramente que as rotas são bi-direcionais e que qualquer problema de não ocorrer a conversação é devida a problemas de regras de firewall. Assim, o correto é de um Endian escolhido, conectar com o client gw2gw no outro Endian no papel de servidor, sem conectar com o client gw2gw no sentido oposto.
Na maioria (senão todos) os casos que resolvi, o problema foi resolvido corrigindo os direitos de execução por sudo para o usuario openvpn para executar os comandos que acrescentam as rotas remotas e tambem ajustam o dnat,que deve ser ajustado no arquivo /etc/sudoers, acrescentando as linhas abaixo, executando o comando “nano /etc/sudoers” (ou vi):
openvpn ALL=NOPASSWD: /usr/local/bin/setdnat.py
openvpn ALL=NOPASSWD: /usr/local/bin/remoteroute.py
Assim, as rotas são adicionadas corretamente, lembrando que todos os Endian firewall envolvidos devem estar com o sudoers corrigido corretamente.
Cada conexão deve ser criada associada a um usuario para conexão no Endian remoto com o campo networks behind client preenchidos com as redes locais no Endian remoto (servidor).
- maio 10, 2011 às 1:23 pm #5167lucastavarestgaParticipante
Amigos,
Estou com o mesmo problema de Endian Firewall, tenho instalado na matriz e em uma filial o Endian Firewall 2.4.1.
Configurei todos serviços, inclusive VPN via client funciona perfeitamente.
Porém quando ativo OpenVPN client (Gw2Gw), a filial conecta na matriz e consegue acessar todos endereços porém a matriz não acessa a rede da filial.
Faixa de rede Matriz: 10.1.1.0/24
Faixa de rede Filial: 10.1.2.0/24
Na Matriz criei o usuário e senha de acesso em OpenVPN client (Gw2Gw)
Na filial configurei o usuário e senha de acesso em OpenVPN client (Gw2Gw) para acessar a matriz
Gostaria de saber se existe um procedimento para configuração correta do Endian Firewall, para que funcione OpenVPN client (Gw2Gw).
Quem puder ajudar eu agradeço.
- outubro 10, 2011 às 11:51 am #5168Gilberto MendesParticipante
Olá bom dia a todos.
Gostaria de lhes dizer que NUNCA ví um forum tão seleto quanto este, e cheio de profissionais e suas soluções. Bem fiz minha escolha pelo Endian faz dois anos, e sinceramente não tenho nada que reclamar nem tampouco se arrepender.
Eu estava com esta dificuldade do colega acima, no início do topico, eu resolvia com exatamente duas VPN´s, uma indo e outra voltando, pois no meu ponto Servidor tenho o Servidor de aplicativos e somente os drivers das impressoras que possuo, pois os usuario acessam via TS. Porém não uso o redirecioanamento de impressoras por conta da bagunça que isso causa, eu instalei a impressora propriamente dita e lá deixei, quando o usuario pede impressão da impressora por exemplo do ponto filial tem uma impressora com o driver apontando para um print server na filial, isso só dava certo com as duas VPN´s sendo IP válidos e fixos. Fato que ocorrem problemas de conxão da filial e perco o IP válido, e agora como resolver? Apareceu esse tópico. Estou imprimindo sem problemas depois da adição de uma rota dentro do Endian do ponto Servidor –> Cliente e terminaram os problemas. Consigo pingar as maquinas no sentido Servidor –> Cliente, coisa que não conseguia, agora tem um pequeno porém que gostaria de lhes perguntar, não conseguigo descobrir as maquinas na rede Filial (Cliente) através do comando Executar –> \ip-da-maquina (ele não alcança) tem algo mais que possamos fazer pra complementar esta tarefa? Ficaria grato com mais esta ajuda, pois comeste tópico, somente assistindo resolvi muita coisa.
Atenciosamente,
Gilberto de Freitas Mendes,
- maio 14, 2013 às 11:59 am #5169rbsParticipante
Revivendo este topico,
Estou com o mesmo problema para fechar uma VPN usando OpenVPN Server & OpenVPN Gw2Gw,na versão 2.5.1, a Openvpn client conecta, mostra a conexão estabilizada, mas nao roteia os pacotes entre as redes atras dos servidores VPN, de servidor a servidor consigo pingar nos Ips da VPN mas nao consigo pingar nos Ips atras da VPN.
Alguem ja passou por isso e conseguiu resolver? qual a solução? pois tentei tudo que estava neste topico e nao deu certo.
- maio 14, 2013 às 12:23 pm #5170Eduardo SilvaParticipante
Se a VPN estabelece, você pode ter 2 problemas:
– Rotas
e/ou
– Firewall
Para testar as rotas, realize um traceroute de uma rede para a outra, e verifique nos resultados, se o caminho percorrido está correto (se vai por dentro da VPN ou se está saindo pelo link principal de internet).
Se os pacotes nos dois lados estiverem saindo corretamente através da VPN, então provavelmente você precisa liberar acesso no firewall.
[]’s
- AutorPosts
- O tópico ‘Redes usando OpenVPN não se conversam’ está fechado para novas respostas.