[GTER] CGNat com IPNAT vs Traceroute

[Márcio Elias Hahn do Nascimento]

Depois de mais algum tempo e mais algum estudo, cheguei a conclusão
que os pacotes ICMP Type 11 (TTL Exceeded) chegam a interface WAN do
servidor com NAT e o mapeamento do IPNat não entrega eles na interface
LAN. 

Mesmo o servidor não tendo uma regra de firewall sequer, e
estando com o NAT configurado corretamente de acordo com as man pages,
esse tipo de pacote não chega a interface que está no lado da LAN. 

Já
fiz diversos testes, e estou praticamente pronto para aceitar mais essa
limitação no uso do NAT, de forma que se algum cliente reclamar, é por
que ele é "leigo de menos" pra estar atras do NAT e deve receber IP
público direto. 

Se alguém na lista tem uma implementação parecida e/ou
alguma dica antes de eu bater o martelo e conviver com esse erro, fico
grato! 

---

Att 

Márcio Elias Hahn do Nascimento
(48) 8469-1819 /
3524-0700 - marcio at sulonline.net
INOC-BR: 52977*100
GERÊNCIA DE RECURSOS
DE TIC - Sul Internet [1] 

 [1] 

Em 22/06/2016 14:50, Márcio Elias
Hahn do Nascimento escreveu: 

> Boa tarde pessoal! 
> 
> Estou tento um
comportamento estranho em meu
> ambiente de testes com IPNAT rodando no
FreeBSD 10.3 e gostaria de saber
> se alguém tem alguma ideia do que
pode ser. 
> 
> Como comentado a algum
> tempo aqui na lista, estou
tentando implementar um mapeamento de IP's
> privados para públicos com
mapeamento de portas. 
> 
> Pois bem, tendo
> habilitado roteamento,
ipfilter, (sem regra alguma para bloquear nada,
> propósito de testes
somente) e IPNAT, coloquei esta configuração no
> arquivo ipnat.rules:

> 
> map bce0 100.64.0.1 -> ip.publico portmap tcp/udp
> 5000:7999
>
map bce0 100.64.0.1 -> ip.publico 
> 
> Eu recebendo o IP
> 100.64.0.1
na minha interface PPPoE (cliente) rodo um traceroute para o
> 8.8.8.8 e
tenho essa resposta: 
> 
> Rastreando a rota para
>
google-public-dns-a.google.com [8.8.8.8]
> com no máximo 30 saltos: 
>

> 1 1
> ms 1 ms 1 ms 192.168.0.1
> 2 21 ms 16 ms 9 ms
IP.Concentrador.PPPoE
> 3 2
> ms 2 ms 1 ms IP.CGN.IPNAT
> 4 * * *
Esgotado o tempo limite do pedido.
> 5
> * * * Esgotado o tempo limite
do pedido.
> 6 * * * Esgotado o tempo
> limite do pedido.
> 7 * * *
Esgotado o tempo limite do pedido.
> 8 25 ms
> 25 ms 24 ms
google-public-dns-a.google.com [8.8.8.8] 
> 
> Já se eu rodar o
> mesmo
traceroute não passando pelo IPNAT, todos os hops são
> identificados
corretamente. 
> 
> Bom tirando esse inconveniente todo o
> resto
aparentemente funciona como esperado, acesso a internet normal
> para um
usuário doméstico. Porém fiquei com um pé atras por causa deste
>
comportamento e gostaria de resolver isso antes de por definitivamente
>
em produção. 
> 
> Alguém tem alguma ideia do que possa estar causando
isso?
> 
> -- 
> 
> Att 
> 
> Márcio Elias Hahn do Nascimento
> (48)
8469-1819 / 3524-0700 -
> marcio at sulonline.net
> INOC-BR: 52977*100
>
GERÊNCIA DE RECURSOS DE TIC -
> Sul Internet [1] 
> 
> [1] 
> 
>
Links:
> ------
> [1] http://www.sulinternet.net [1]
> --
> gter list
https://eng.registro.br/mailman/listinfo/gter [2]
 

Links:
------
[1]
http://www.sulinternet.net
[2]
https://eng.registro.br/mailman/listinfo/gter