VPN Windows

Pessoal, a situação é a seguinte:

Umas das pontas eu sei que é um Ruindows 2000 Server, a outra eu não sei. A seguinte mensagem de erro na conexão acontece quando tento conectar:

Erro: 721: O computador remoto não respondeu. Para obter ajuda blá, blá, blá...

Fica um tempo verificando o nome de usuário e senha e depois dá esse erro.
Essa VPN funcionava muito bem até eu colocar um servidor proxy entre o roteador e o gateway dos clientes. Infelizmente não posso voltar a estrutura anterior, pois além de melhorar muito a velocidade de navegação dos clientes das outras mídias, vou ficar mal com a diretoria e minha situação aqui já não é boa... :D .
A estrutura era mais ou menos assim:

internet <> router <> gateway_de_cabo <> servidor_vpn_cliente

Agora tá assim:

Internet <> Router <> proxy <> gateway de cabo <> VPN-Server-do-cliente

Se eu coloco uma máquina entre o proxy e o gateway, consigo conectar na VPN normalmente. Já se passo para trás do proxy, ou seja, entre o router e o proxy, aparece a mensagem de erro acima.
Já troquei a máquina do proxy toda e chegou a funcionar uma vez e parou... não sei mais o que fazer.... o pior é que esse cliente é da prefeitura e já está com esse problema faz um tempão...
Socorro.

Abraços.

Caro,

Vamos lá:

IPT=caminho_do_iptables
IF_WAN=interface_da_internet
IP_WAN=IP_da_internet

$IPT -t nat -A PREROUTING -i $IF_WAN -p tcp --dport 1723 -j DNAT --to 192.168.0.150:1723
$IPT -t nat -A PREROUTING -i $IF_WAN -p tcp --dport 1723 -j DNAT --to 192.168.0.150
$IPT -t nat -A PREROUTING -i $IF_WAN -p tcp --dport 1723 -j DNAT --to 192.168.0.150
$IPT -t nat -A PREROUTING -i $IF_WAN -p 47 -j DNAT --to 192.168.0.150
$IPT -A INPUT -i eth0 -p tcp -d $IP_WAN --dport 1723 -j ACCEPT
$IPT -A INPUT -i eth0 -p 47 -j ACCEPT
$IPT -A FORWARD -p TCP --dport 1723 -j ACCEPT
$IPT -A FORWARD -p 47 -j ACCEPT

Vale lembrar que 192.168.0.150 seria IP do Servidor Interno, o windows.

Citação:

---

Postado originalmente por wrochal

Caro,

Vamos lá:

IPT=caminho_do_iptables
IF_WAN=interface_da_internet
IP_WAN=IP_da_internet

$IPT -t nat -A PREROUTING -i $IF_WAN -p tcp --dport 1723 -j DNAT --to 192.168.0.150:1723
$IPT -t nat -A PREROUTING -i $IF_WAN -p tcp --dport 1723 -j DNAT --to 192.168.0.150
$IPT -t nat -A PREROUTING -i $IF_WAN -p tcp --dport 1723 -j DNAT --to 192.168.0.150
$IPT -t nat -A PREROUTING -i $IF_WAN -p 47 -j DNAT --to 192.168.0.150
$IPT -A INPUT -i eth0 -p tcp -d $IP_WAN --dport 1723 -j ACCEPT
$IPT -A INPUT -i eth0 -p 47 -j ACCEPT
$IPT -A FORWARD -p TCP --dport 1723 -j ACCEPT
$IPT -A FORWARD -p 47 -j ACCEPT

Vale lembrar que 192.168.0.150 seria IP do Servidor Interno, o windows.

---

Esqueci de informar... o cliente tá com IP Válido na interface...

Abraços.

Basta colocar na variavel IP_WAN

Sem Mais,

Citação:

---

Postado originalmente por wrochal

Basta colocar na variavel IP_WAN

Sem Mais,

---

Não entendi... deixa eu ser mais claro:

Meu cliente tem ip válido na interface dele... ou seja:

ROUTER <200.x.x.1 | 200.x.x.13> PROXY <200.x.x.19 | 200.x.x.30> GW_CABO <200.x.x.130 | 200.x.x.139> CLIENTE

E como eu falei: se eu colocar um computador na mesma rede onde estão ligados o PROXY e o GWCABO (no switch), consigo conectar na VPN dele normalmente, pois ele me forneceu um usuario/senha de teste e desta forma venho testando.
O arquivo que contém as regras no GWCABO é o mesmo do PROXY, com a diferênça que, no PROXY, na FORWARD eu to permitindo o livre tráfego de pacotes de uma interface para a outra sem restrição, ou seja, não filtro nada. Essa máquina não faz mais nada que não seja proxy transparente na porta 80. Só isso.

Realmente não sei o que fazer. Alguém tem mais alguma idéia?

Abrigado pela ajuda.

:D :D :D :D :D :D :D :D

Pessoal, resolvi o problema.

Monitorando no GWCABO as tentativas de conexão através do utilitário IPTRAF, percebi que o protocolo GRE aparecia apenas na interface externa e nunca na interna. Como o tráfego era em direção a rede dos clientes (externa > interna), lembrei-me de que na ACL eram tratadas apenas os protocolos ICMP, TCP e UDP, além do que a política padrão da chain FORWARD é DROP... Ora bolas, se o protocolo que estava tentando atravessar a interface não estava sendo tratado na ACL, como que a conexão seria estabelecida????? Resumindo:
FALTA DE ATENÇÃO deste Administrador de Sistema...
Provisoriamente incluí em minha ACL na seção de FORWARD uma regra que permitia o protocolo GRE ser roteado da interface externa para a interna. XAZAM! funcionou na hora.

Código :

---

$IPTABLES -A FORWARD -p gre -i $IF_INTERNA -o IF_EXTERNA -j ACCEPT

---

Abraços a toda a comunidade e espero que seja a luz para aguém (se é que alguém seria tão estúpido quanto eu) resolver um problema parecido.