DDNS não pega ip da WAN
-
Bom dia.
Meu pfsense estar configurado IP DINAMIC.
Roteador em Modo bridge
Provedor net
DDNS Conta no (no-ip) freeWAN 100.xxx.xxx.xxx
Lan 192.xxx.xxx.xxx
DDNS 179.xxx.xxx.xxxEstou com problema na configuração DDNS, quando eu termino de fazer todas as configuração o DDNS do pfsense deveria pegar o ip da minha wan, mas ele pega outro ip do provedor da net.
Atenciosamente,,
Caio Ramos
-
Cara, aqui esta funcionando como vc pode ver nos anexos na versão 2.2.6.
-
A minha configuração estar igual a sua, se sabe o que pode estar acontecendo isso? alguma configuração no roteador..
-
Cara… esse roteador de uma das filiais nao esta nem em bridge, esta como roteador mesmo fornecendo ip de subrede para a wan do pfsense.
Eu andei tendo problemas ano passado fixando o IP, pois funcionava por um tempo e depois simplesmente parava tive dei deixar dinamico e os problema pararam.
Os logs do DDNS ficam na aba General, esta dando algum erro?
-
Sempre tive problema com DDNS no pfSense, optei por deixar um Client instalado em uma maquina da rede.
-
Não tem nenhum erro no meu log, se tem um tutorial de como se fez a conexão adsl com seu modem?
Pode ser alguma regra no nat que não estar recebendo o ip devido? -
Caio,
faça o seguinte, acesse as configurações do modem da net e habilite a DMZ e informe o IP que a WAN do PFsense esta utilizando isso se o seu modem estiver configurado como ROUTER, caso esteja recebendo o IP valido na interface WAN revise ai sua configuração e até mesmo no seu serviço de dns dinamico. Caso nao saiba a senha de acesso do seu modem procure na NET, mas hoje em dia a net tem colocado no modens com wifi a senha o MAC do modem já vi alguns assim.
-
Resolvido, NET estava fornecendo um IP privado CGNAT, por isso que eu recebia um IP diferente da Wan.
-
Não sei até onde utilizart CGNAT seria vantagem. Para usuários domésticos básicos talvez sim, mas para com mais recursos certamente não é.
O Carrier Grade NAT (CGN) ou Large Scale NAT (LSN), definido na RFC 6264, é uma técnica de tradução de grande porte que vem sendo praticada por algumas operadoras de telecomunicações que não possuem mais endereços IPv4 disponíveis e, portanto, se encontram em situação crítica. Essa prática consiste em aplicar o NAT na própria rede da operadora, antes mesmo de chegar ao usuário, entregando para seu cliente um endereço privado.
Se o NAT (também chamado de NAT44), por si só, já é uma agressão aos princípios arquiteturais da Internet por quebrar o modelo fim-a-fim e tornar o funcionamento de algumas aplicações mais complexo, o CGN é ainda mais grave porque implica na prática daquilo que chamamos de NAT444 ou pejorativamente de "NAT do NAT".
Um primeiro problema do NAT444 é o uso de endereços privados 10/8, 172.16/12 e 192.168/16 da RFC1918, afinal, existe a possibilidade de haver conflito entre os planos de endereçamento utilizados nas redes internas dos clientes e das operadoras. Para "sanar" esse problema e evitar o conflito de endereços, a RFC6598 reserva o prefixo 100.64.0.0/10 como sendo uma faixa privada não roteável na Internet e de uso exclusivo das operadoras.
Ao se quebrar o modelo fim-a-fim, perde-se a possibilidade de alcançabilidade "direta" entre os pontos (em layer-3), o que torna o gerenciamento e a configuração da rede mais complexa. No entanto, a empresa (ou usuário residencial) ainda tem autonomia para criar políticas de redirecionamento (port-forwarding) através da escrita de regras em seu roteador de borda, permitindo que seu único endereço público possa direcionar o usuário externo às suas aplicações internas que estão escondidas da Internet por obscuridade.
Com o NAT444, essa autonomia deixa de existir, porque o endereço público que tem alcançabilidade na Internet é de posse da operadora apenas, não mais da empresa. Dessa forma, os administradores da rede vão depender da ação conjunta das operadoras para que as políticas de redirecionamento de tráfego sejam escritas nos próprios roteadores da operadora, o que traz consigo vários problemas para os clientes e também para as operadoras.
Essa prática literalmente acaba com a autonomia da empresa/usuário em criar suas políticas de redirecionamento, afinal, ela fica totalmente dependente da operadora para "auxiliar" nesse processo, o que compromete a flexibilidade, escalabilidade e segurança. Cabe destacar que essa técnica é ruim, inclusive para a operadora, afinal, "administrar" as políticas individuais dos seus clientes é oneroso.
Além disso, para aqueles que sempre defenderam o NAT como medida de segurança (o que ele nunca foi, já que NAT foi criado para economizar IPs), a segurança do ambiente fica comprometida. Com CGNAT a operadora conhece detalhadamente quais portas/serviços estão em execução nos servidores privados, ou seja, é o fim da obscuridade para aqueles que defendiam essa prática e o começo da "iluminação absoluta"!
Talvez fosse o caso da NET fazer igual a COPEL, que mudou de IPv4 para IPv6 do dia para a noite, obrigando todos os novos clientes a aderir o protocolo. Talvez com a chegada inevitável do protocolo, a dor de mudar no começo seja menor que a dor de ficar por traz de CGNAT muito tempo.
-
André,
Achei muito boa sua explicação! Valeu mesmo
Mas qual seria o melhor procedimento para solucionar isso? Também estou com o mesmo problema e meu no-ip não pega o ip publico para acessar vpn. Isso ocorreu justamente com a troca do modem em uma manutenção da NET.
Desde já agradeço
Hugo
Não sei até onde utilizart CGNAT seria vantagem. Para usuários domésticos básicos talvez sim, mas para com mais recursos certamente não é.
O Carrier Grade NAT (CGN) ou Large Scale NAT (LSN), definido na RFC 6264, é uma técnica de tradução de grande porte que vem sendo praticada por algumas operadoras de telecomunicações que não possuem mais endereços IPv4 disponíveis e, portanto, se encontram em situação crítica. Essa prática consiste em aplicar o NAT na própria rede da operadora, antes mesmo de chegar ao usuário, entregando para seu cliente um endereço privado.
Se o NAT (também chamado de NAT44), por si só, já é uma agressão aos princípios arquiteturais da Internet por quebrar o modelo fim-a-fim e tornar o funcionamento de algumas aplicações mais complexo, o CGN é ainda mais grave porque implica na prática daquilo que chamamos de NAT444 ou pejorativamente de "NAT do NAT".
Um primeiro problema do NAT444 é o uso de endereços privados 10/8, 172.16/12 e 192.168/16 da RFC1918, afinal, existe a possibilidade de haver conflito entre os planos de endereçamento utilizados nas redes internas dos clientes e das operadoras. Para "sanar" esse problema e evitar o conflito de endereços, a RFC6598 reserva o prefixo 100.64.0.0/10 como sendo uma faixa privada não roteável na Internet e de uso exclusivo das operadoras.
Ao se quebrar o modelo fim-a-fim, perde-se a possibilidade de alcançabilidade "direta" entre os pontos (em layer-3), o que torna o gerenciamento e a configuração da rede mais complexa. No entanto, a empresa (ou usuário residencial) ainda tem autonomia para criar políticas de redirecionamento (port-forwarding) através da escrita de regras em seu roteador de borda, permitindo que seu único endereço público possa direcionar o usuário externo às suas aplicações internas que estão escondidas da Internet por obscuridade.
Com o NAT444, essa autonomia deixa de existir, porque o endereço público que tem alcançabilidade na Internet é de posse da operadora apenas, não mais da empresa. Dessa forma, os administradores da rede vão depender da ação conjunta das operadoras para que as políticas de redirecionamento de tráfego sejam escritas nos próprios roteadores da operadora, o que traz consigo vários problemas para os clientes e também para as operadoras.
Essa prática literalmente acaba com a autonomia da empresa/usuário em criar suas políticas de redirecionamento, afinal, ela fica totalmente dependente da operadora para "auxiliar" nesse processo, o que compromete a flexibilidade, escalabilidade e segurança. Cabe destacar que essa técnica é ruim, inclusive para a operadora, afinal, "administrar" as políticas individuais dos seus clientes é oneroso.
Além disso, para aqueles que sempre defenderam o NAT como medida de segurança (o que ele nunca foi, já que NAT foi criado para economizar IPs), a segurança do ambiente fica comprometida. Com CGNAT a operadora conhece detalhadamente quais portas/serviços estão em execução nos servidores privados, ou seja, é o fim da obscuridade para aqueles que defendiam essa prática e o começo da "iluminação absoluta"!
Talvez fosse o caso da NET fazer igual a COPEL, que mudou de IPv4 para IPv6 do dia para a noite, obrigando todos os novos clientes a aderir o protocolo. Talvez com a chegada inevitável do protocolo, a dor de mudar no começo seja menor que a dor de ficar por traz de CGNAT muito tempo.
-
Pessoal, bom dia!
Estou com esse problema da NET fornecendo um IP privado CGNAT e por isso não consigo conectar vpn usando Dyndns. Alguém conseguiu contornar esse problema? A NET informa que não problema e preciso encontrar um contorno.
O modem está em Bridge normalmente.
Agradeço qualquer dica.
Obrigado