Port forwarding só está funcioando com masquerade

Port forwarding só está funcionando com masquerade

Olá.

Tenho um router A que possui alguns endereços IP na Internet. Há o router B, que não possui IP na Internet e está atrás de um NAT em um terceiro router C que possui IP na Internet mas por algumas questões não posso fazer o port forwarding nele. Ambos rodam Mikrotik RouterOS.
Os routers A e B estão ligados por túneis EoIP por meio de um bridge no router C:

router A ---- eoip ---- router C [bridge] ---- eoip ---- router B

Estou tentando fazer o port forwarding de uma range de portas em um dos IPs do router A para o router B através desse túnel.

No router A tenho somente as seguintes regras no firewall, nenhuma mais:
Código :

/ip firewall nat add action=src-nat chain=srcnat disabled=no protocol=tcp src-address=\ <IP DO ROUTER B NO EOIP> src-port=<RANGE DE PORTAS> to-addresses=<IP NA INTERNET> to-ports=\ <RANGE DE PORTAS> add action=dst-nat chain=dstnat disabled=no dst-address=<IP NA INTERNET> \ dst-port=<RANGE DE PORTAS> protocol=tcp to-addresses=<IP DO ROUTER B NO EOIP> to-ports=\ <RANGE DE PORTAS> add action=src-nat chain=srcnat disabled=no protocol=udp src-address=\ <IP DO ROUTER B NO EOIP> src-port=<RANGE DE PORTAS> to-addresses=<IP NA INTERNET> to-ports=\ <RANGE DE PORTAS> add action=dst-nat chain=dstnat disabled=no dst-address=<IP NA INTERNET> \ dst-port=<RANGE DE PORTAS> protocol=udp to-addresses=<IP DO ROUTER B NO EOIP> to-ports=\ <RANGE DE PORTAS>
No router B quero fazer o forwarding de uma dessas portas para um servidor em uma rede interna, e para isso tenho as seguintes regras nele, as únicas regras:
Código :

/ip firewall nat add action=src-nat chain=srcnat disabled=no protocol=tcp src-address=\ <IP DO SERVIDOR INTERNO> src-port=<PORTA> to-addresses=<IP DO ROUTER B NO EOIP> to-ports=\ <PORTA> add action=dst-nat chain=dstnat disabled=no dst-address=<IP DO ROUTER B NO EOIP> \ dst-port=<PORTA> protocol=tcp to-addresses=<IP DO SERVIDOR INTERNO> to-ports=\ <PORTA> add action=src-nat chain=srcnat disabled=no protocol=udp src-address=\ <IP DO SERVIDOR INTERNO> src-port=<PORTA> to-addresses=<IP DO ROUTER B NO EOIP> to-ports=\ <PORTA> add action=dst-nat chain=dstnat disabled=no dst-address=<IP DO ROUTER B NO EOIP> \ dst-port=<PORTA> protocol=udp to-addresses=<IP DO SERVIDOR INTERNO> to-ports=\ <PORTA>
Configurei a interface web do RouterOS no router B para uma das portas na range forwarded, sem restrição de origem de acesso, mas não consigo acessá-la por meio do endereço http://<IP DO ROUTER A NA INTERNET>:<PORTA>.
Fica carregando interminantemente. Também não consigo acessar na rede do router B o servidor interno devidamente configurado na porta encaminhada para ele.

O tracking está ativo no firewall dos dois routers. Quando tento acessar a interface web do router B pelo IP público do router A posso ver que o tráfego está passando pela regra dstnat, somente ela. Vejo que na lista de conexões surgem algumas com destino ao IP do router B no túnel EoIP e a porta que tentei acessar (da interface web), porém o estado delas está sempre em syn-received ou syn-sent. Isso ocorre com qualquer porta que eu tentar acessar, inclusive a que encaminhei no router B para o servidor interno.

No router B não surge nenhum tráfego em regra alguma dstnat ou srcnat, porém vejo na lista de conexões ativas que as mesmas que aparecem no router A aparecem também nesse, e na mesma situação, sempre no estado syn-received ou syn-sent. Isso também ocorre como no caso anterior, em conexões a quaisquer portas, inclusive a que encaminho para o servidor interno.

Eu consigo fazer "funcionar" substituindo de src-nat para masquerade o action das regras do chain srcnat. Porém não quero assim pois o IP que vejo nos acessos que chegam, tanto no router B quanto no servidor interno são dos routers, quando na verdade quero o IP na Internet de quem fez a conexão, como aparece nas conexões com status syn-received e syn-sent na lista, como citei anteriormente.

E aí, galera, o que está acontecendo com esses routers? Como posso resolver isso? Já tentei reiniciar os dois, definir a interface de saída nas regras srcnat e alterar os action para netmap, mas nada solucionou o caso.
Conto com a ajuda de vocês. Até mais.

Boa noite amigo,

Muito interessante esse seu cenário, mas fica praticamente impossível entender sem um desenho. Poderia fazer um esboço?

Abraço

1 Anexo(s)

Citação:

Postado originalmente por gamineiro

Boa noite amigo, Muito interessante esse seu cenário, mas fica praticamente impossível entender sem um desenho. Poderia fazer um esboço? Abraço

Fiz esse aqui, espero que ajude:

Anexo 51731

No router C há um bridge entre o túnel EoIP com o router A e o outro com o router B.
Não mencionei no post inicial nem na imagem, mas entre os routers C e B há um PC rodando Linux que é quem efetivamente faz a conexão entre os dois. Ele faz um NAT bidirecional (uma regra para cada sentido) com masquerade, mas ao meu ver isso não tem influência alguma no problema tratado, por isso não citei esse detalhe.

Resumindo, você precisa que o SERVIDOR navegue na internet por meio do Router A, isso?
Precisa que TODAS as portas saiam por esse router, ou apenas esse range de portas?

Citação:

Postado originalmente por gamineiro

Resumindo, você precisa que o SERVIDOR navegue na internet por meio do Router A, isso?
Precisa que TODAS as portas saiam por esse router, ou apenas esse range de portas?

Não não, preciso que todo tráfego que chegue no router A em uma range de portas específicas (ex.: 8451-8456) seja encaminhado para o router B, que por sua vez encaminha o tráfego em algumas dessas portas (ex.: 8454-8456) para o servidor, enquanto usa as restantes para permitir acesso remoto a si mesmo.

Vamos supor que o IP público no router A que quero usar seja 198.51.100.26.
O túnel EoIP é endereçado na faixa 192.168.84.0/30, sendo que 192.168.84.2 é o router A e 192.168.84.1 é o router B.

O tráfego que chegar em 198.51.100.26, nas portas entre 8451 e 8456 deve ser encaminhado para 192.168.84.1.
Agora no router B, o tráfego que chegar em 192.168.84.1 nas portas entre 8454 e 8456 deve ser encaminhado para o servidor interno, ex.: 10.2.15.121.
As portas restantes, 8451-8453, o router B usará para fornecer acesso a si mesmo pela Internet, ex.: interface web de configuração, SSH e API, acessíveis cada um por uma porta dessas no IP 198.51.100.26.

Configurei nos dois routers as regras que citei no começo do tópico, mas estão ocorrendo os problemas que falei.

Perfeito! Agora estamos no caminho.

Uma ultima pergunta: Qual o gateway do router B? É o router A atraves do tunel, ou o router C?

Citação:

Postado originalmente por gamineiro

Perfeito! Agora estamos no caminho. Uma ultima pergunta: Qual o gateway do router B? É o router A atraves do tunel, ou o router C?

O gateway é o router C.

No router A:

Código :

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=198.51.100.26 dst-port=8451-8456 protocol=tcp to-addresses=192.168.84.1
add action=src-nat chain=srcnat out-interface=INTERFACE-IP-PUBLICO src-address=192.168.84.1 to-addresses=198.51.100.26

No router B:

Código :

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=192.168.84.1 dst-port=8454-8456 protocol=tcp to-addresses=10.2.15.121
add action=src-nat chain=srcnat out-interface=INTERFACE-TUNEL src-address=10.2.15.121 to-addresses=192.168.84.1
 
/ip firewall mangle
add action=mark-connection chain=prerouting dst-port=8454-8456 new-connection-mark=SERVIDOR protocol=tcp src-address=10.2.15.121 passthrough=yes
add action=mark-routing chain=prerouting connection-mark=SERVIDOR new-routing-mark=SERVIDOR passthrough=no
 
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.84.2 routing-mark=SERVIDOR

Acho que isso amigo, testa ai e posta o resultado.

Abraço

Citação:
Postado originalmente por gamineiro
No router A:
Código :

/ip firewall nat add action=dst-nat chain=dstnat dst-address=198.51.100.26 dst-port=8451-8456 protocol=tcp to-addresses=192.168.84.1 add action=src-nat chain=srcnat out-interface=INTERFACE-IP-PUBLICO src-address=192.168.84.1 to-addresses=198.51.100.26
No router B:
Código :

/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.84.1 dst-port=8454-8456 protocol=tcp to-addresses=10.2.15.121 add action=src-nat chain=srcnat out-interface=INTERFACE-TUNEL src-address=10.2.15.121 to-addresses=192.168.84.1 /ip firewall mangle add action=mark-connection chain=prerouting dst-port=8454-8456 new-connection-mark=SERVIDOR protocol=tcp src-address=10.2.15.121 passthrough=yes add action=mark-routing chain=prerouting connection-mark=SERVIDOR new-routing-mark=SERVIDOR passthrough=no /ip route add dst-address=0.0.0.0/0 gateway=192.168.84.2 routing-mark=SERVIDOR
Acho que isso amigo, testa ai e posta o resultado.

Abraço
Obrigado por estar ajudando.
Acho que ainda há um equívoco na sua interpretação. Você está considerando o servidor como um gateway para outra rede, como é possível constar pela sua sugestão da regra de mangle e rota no router B. Na verdade ele é um servidor web/ftp/ssh apenas, ele não roteia nada.

No router A minhas regras estão desse jeito que você postou, exceto por eu não ter informado nelas o parâmetro out-interface, mas já tentei definir isso e não adiantou nada. Com essas regras aí eu já devia estar apto a acessar qualquer coisa rodando nas portas 8451, 8452 ou 8453 no router B, não concorda? Mas isso não ocorre, fica na situação que descrevi no post inicial ainda, com as conexões aparecendo tanto no router A quanto no B, mas com status syn-received e syn-sent e sem tráfego/resposta.

Atualizando: eu notei aqui agora que no router B as conexões que surgem não estão ficando somente nesses estados que falei. Elas estão alternando diretamente para close. E é possível ver que o router B está enviando resposta para o A, pois surgem conexões nesse sentido também, porém nada é recebido em quem tenta acessar. Eu configurei a interface web no B para estar acessível na porta 8451. Quando eu tento acessá-la pelo IP do A, o navegador fica carregando sem parar até causar timeout. É estranho que ontem essas conexões não estavam indo para o estado close. Será que isso pode ser algum outro router na rota entre o A e B fazendo o bloqueio? Há mais uns 4, os quais também administro, entre os routers B e C.

Não amigo. Não estou supondo isso.

Estou dizendo em mangle que os pacotes vindos do servidor (10.2.15.121) nas portas 8454-8456 devem ser encaminhados para o router A (192.168.84.2)

Suas regras do router A estão equivocadas, usando src-port, onde o correto é dst-port.

Se puderes fazer o teste como sugeri, poderás ter sucesso.

Abraço

Citação:

Postado originalmente por gamineiro

Não amigo. Não estou supondo isso. Estou dizendo em mangle que os pacotes vindos do servidor (10.2.15.121) nas portas 8454-8456 devem ser encaminhados para o router A (192.168.84.2) Suas regras do router A estão equivocadas, usando src-port, onde o correto é dst-port. Se puderes fazer o teste como sugeri, poderás ter sucesso. Abraço

Ah sim, é que achei que tinha um dst-address ali no mangle e que na rota era o IP do servidor, hehe.

Sobre as regras, acho que eu devo ter errado algo ao transcrevê-las para cá, pois na verdade estão implementadas igual ao que você sugeriu.

Testei tudo que você sugeriu e nada funcionou. Mas como eu disse no título desse tópico, se no router A eu adicionar ou substituir a regra srcnat atual (inclusive essa que você sugeriu) por uma com action=masquerade, eu consigo o que estou querendo perfeitamente, exceto pelo que o IP de origem do acesso vai ser mascarado, o que não quero.

Então tenho absoluta certeza que o problema envolve somente nas regras srcnat no router A, mas o quê? Já defini a interface de saída, removi a especificação de protocolo e porta, como você sugeriu no penúltimo post.

Como a única diferença do src-nat para o masquerade é a abstração da seleção do IP público e interface de saída, parece que o problema está no IP ou interface que estou selecionando na srcnat, mas não sei o porquê disso. Existe alguma forma de eu ver por qual IP/interface está saindo o tráfego da masquerade?

Atualização: fiz uns testes com o masquerade mudando o src-address e constei que o único que funcionou foi o IP público do router C. Como nesse router - que é pelo qual o router B tem acesso à internet - há um NAT, o tráfego do EoIP está sendo mascarado nele. Mas não entendi o porquê disso ocorrer. O tráfego de um túnel não deveria estar "imune" ao que é feito ao tráfego normal? Ainda mais por estar em uma bridge. E mais, não adianta eu apenas colocar na src-nat o IP do NAT do router C como src-address, não funciona aqui, embora no masquerade ocorra tudo bem. Acredito que seja um problema de identidade da conexão. O dst-nat diz que ela será feita com 192.168.84.1, mas a resposta está vindo de 198.51.100.40 (IP público do router C); a resposta esperada não é daí. Eu tentei fazer o tráfego pelo túnel não passar pelo NAT, mas não consegui. Acho que vou ter que alterar o NAT do PC Linux que está entre os routers B e C de masquerade para dst-nat/src-nat também.

Agora me confundiu de novo. hahahah

Bom, caso queira fazer com que a comunicação da rede internet não seja afetada pela regra de NAT, crie uma address-list com as redes internas, e na regra de NAT em dst-address-list(na segunda aba) coloque !NOME_DA_LISTA.

Espero que ajude.

1 Anexo(s)

Citação:

Postado originalmente por gamineiro

Agora me confundiu de novo. hahahah

Bom, caso queira fazer com que a comunicação da rede internet não seja afetada pela regra de NAT, crie uma address-list com as redes internas, e na regra de NAT em dst-address-list(na segunda aba) coloque !NOME_DA_LISTA.

Espero que ajude.

Hahaha, tentei explicar o mais claramente possível, mas se quiser explico novamente de outra forma.

Eu teria que fazer essa exceção aí também para o src-address(-list), não? Ao invés de address-list, somente um src-address=!192.168.84.0/30 dst-address=!192.168.84.0/30 deve funcionar, certo?

Só que há um outro problema que eu não imaginei que existiria. Como eu disse em algum outro post, entre os routers B e C há um PC Linux, que é quem conecta/funciona como gateway entre os dois e faz algumas outras coisas lá. O tráfego entre esses dois routers é feito por um masquerade. Eu não sabia que o NAT se aplicava também a túneis, por isso achei que não seria problema. Sendo assim, vou ter que mudar esse masquerade para src-nat + dst-nat, ao menos nos protocolos GRE e ICMP, certo?

Diante desse problema, uma correção da imagem anterior:

Anexo 51744

Mais tarde vou testar essas coisas aí, comenta aí se está certo meu raciocínio.
Até mais.

Se você estiver usando EoIP não funciona mesmo, a menos que faça o redirecionamento das portas, como você já sabe.

Existe alguma possibilidade de fazer um túnel entre B e A?

Poderia habilitar um SSTP Server no router A, e criar um sstp-client no router B, assim não teria problema o nat no meio do caminho, precisa apenas um IP público no router A.

Abraço

Citação:

Postado originalmente por gamineiro

Se você estiver usando EoIP não funciona mesmo, a menos que faça o redirecionamento das portas, como você já sabe. Existe alguma possibilidade de fazer um túnel entre B e A?

Poderia habilitar um SSTP Server no router A, e criar um sstp-client no router B, assim não teria problema o nat no meio do caminho, precisa apenas um IP público no router A.

Abraço

Não, não é possível fazer um túnel entre A e B diretamente, por dois motivos:
1: O router A é visível para o B, mas o inverso não é possível pois o B não possui IP público e não está em uma rede do router A
2: A solução para isso seria com rotas, mas não posso mexer nelas no router A pois ele está próximo da borda de um OSPF, o que faria a rota ser distribuída por muitos routers, e no caso de haver uma alteração de IP, teria o trabalho de alterar a rota nele de novo, além de gerar toda a atualização do OSPF. Se não fosse isso, eu poderia definir a rota para o router B passando pelo C. No C tenho a rota para o router B passando pelo PC Linux.

Bom, acho que o SSTP não serve, mas se servisse teria que ser no router C para manter a ideia desse router ser um concentrador de túneis, e também, pela proximidade com ele, a conexão e estabelecimento do túnel seria feito mais rapidamente e com menos chances de uma interrupção no meio do caminho. Só que haveriam alguns problemas: SSTP exige muito do router por usar SSL em todo o tráfego, não preciso disso e os router não têm recursos sobrando assim (PPTP e L2TP estão defasados), e o problema que atinge todos os tipos de VPN: as interface não podem ser usadas em bridges, nem podem haver VLANs sobre elas, além de outras coisas. Caso eu precise fazer algo assim, e imagino cenários onde essas necessidades podem surgir, vou ter problemas. Por isso EoIP é a solução ideal, nem OpenVPN atenderia, pois mesmo não sendo defasado quanto os que citei e nem usar tantos recursos quanto a sua sugestão, ainda há o problema das interfaces passivas (acho que é esse o nome que dão).

Então, acabei de bolar uma solução mais interessante aqui: ao invés de um EoIP entre o router B e C, faço uma VLAN entre o PC Linux e o router C. Essa VLAN está inclusa na bridge com o túnel EoIP com o router A. Nesse PC Linux eu faço um DNAT+SNAT para o router B. Ótimo, consigo ping entre o router A e o PC Linux. Aí, para testar, iniciei um servidor web **no PC Linux** rodando em uma das portas encaminhadas e tentei acessá-lo usando o IP público do router A. E adivinha o que ocorreu? O maldito problema lá do começo continua. Fica carregando e não tem resposta no navegador. No EoIP até era compreensível a ocorrência do NAT por ser um túnel over IP, mas na VLAN não estou entendendo o porquê disso estar ocorrendo. Novamente, action=masquerade funciona perfeitamente, inclusive o mesmo caso do src-address ocorre: somente com o IP público do router C. Ou seja, está passando pelo NAT ainda. Mas não faz sentido, o NAT lá no router C é aplicado somente à faixa de IPs com que as máquinas se conectam a ele. Embora o PC Linux esteja nessa faixa, o tráfego do encaminhamento passa pela VLAN, que está em outra faixa. Está muito estranha essa situação, não sei o que fazer para escapar dessa regra NAT. Será que preciso alterar, talvez no router C, a configuração de ARP para proxy-arp? Não entendo muito bem essa configuração, não sei se devo alterar na bridge ou nas portas dela, se for essa a solução.

Atualização: recém lembrei das rotas. Como o router A está mais próximo da borda do OSPF, ao atribuir um IP na faixa do túnel para ele, ele distribuir no OSPF a rota para essa faixa como sendo ele o gateway, e essa rota chega no router C. Assim, quando o router C vai encaminhar o pacote para o router B, ele vê a rota apontando para o A e manda o pacote pra lá. Quando chega no A, o pacote é enviado novamente para o router B por meio do túnel, chegando novamente no C... enfim, acabei criando um loop na rede. Acho que o problema é esse. Agora o porquê do masquerade fazer esse loop parar eu não estou conseguindo entender. Vou ver se posso fazer algo quanto à distribuição dessa rota específica no OSPF, mas acho que não é possível ignorá-la. Se tiver alguma dica para me dar quanto a isso, agradeço.

Atualização: infelizmente o problema não é esse. Eu alterei a máscara dos IPs no túnel para 29 e adicionei um IP para a bridge no router C; isso faz com que a regra recebida do OSPF fique inválida. No entanto, mesmo assim não consegui fazer funcionar. Eu fiz uns testes no router A tentando fazer o dst-nat/src-nat para um outro router na rede e até para o servidor web de algum site, só para testar. E a surpresa é que não funcionou com nenhum. Aí eu resolvi testar usando o IP do próprio router A no túnel como dst-address e src-nat na dst-nat e src-nat respectivamente, fazendo as devidas adaptações no action. Fiz praticamente o mesmo que um action=redirect, porém especificando o IP do túnel. E sem surpresa, funcionou. Logo está confirmado que é o problema não é com as regras. É alguma outra coisa, provavelmente um NAT, mas não faço ideia de como está ocorrendo isso, sendo que testei a configuração entre dois routers ligados diretamente por um PTP wireless e não funcionou. Alguma ideia?

Algum tempo depois... o problema está parcialmente resolvido, então vou atualizar a situação para o caso de alguém ainda querer contribuir:

Os túneis EoIP estavam muito instáveis, caindo em situações de pico no router A, então troquei tudo por bridges de VLAN nos routers todos que estão na rota entre ele e o PC Linux e isso estabilizou a coisa toda.
Resolvi fazer alguns testes de port forwarding usando o router C diretamente, ao invés do A. Eis que funcionou! As mesmas coisas que estava fazendo no router A fiz no C. Um detalhe que determinou tudo foi o gateway padrão do PC Linux. Com o gateway sendo o router C, tudo funciona, mas se eu mudar para algum router na rede bridge de VLANs, embora tenha conexão com a Internet normalmente, o port forwarding para de funcionar.

Ao meu ver, esse comportamento é muito estranho. Uma conexão não deveria depender do gateway do servidor para achar seu caminho de volta, de resposta. Bom, vou ter que deixar da forma que está, ao menos o objetivo principal foi atingido que era permitir acesso externo a determinadas portas do router C e PC Linux, embora não tenha sido exatamente da forma que planejei.