Acesso ssh Externo via PFsense

gbrlCaim
(usa Debian)

Enviado em 18/10/2012 - 09:42h

Pessoal,

Estou com um problema aqui meio complicado.

Tenho uma rede, onde o firewall é um pfsense (de cara pra internet com ip dedicado) e preciso fazer acesso ssh externo (de fora pra dentro) até um servidor rodando CentOS 5.3.

====

Na tabela NAT do pfsense ja montei o seguinte redirecionamento de porta:

If | Proto | Src. addr | Src. ports | Dest. addr | Dest. ports | NAT IP | NAT Ports

WAN | TCP/UDP | * | * | * | 3522 | 192.168.10.251 | 22 (SSH)

Ou seja onde qualquer conexão que venha através da rede WAN na porta 3522 seja redirecionada ao servidor na porta 22 (pelo menos essa é minha idéia)
====

No servidor criei a seguinte regra:

====

iptables -A INPUT -p tcp -s 0/0 --dport 22 -j ACCEPT
ou seja, criei uma regra para as requisições via protocolo tcp na porta 22 de qualquer IP sejam aceitas

====

Alterei o /etc/ssh/sshd_config e descomentei a opção: Port 22

O problema é que Não consigo o acesso via o putty. No entando consigo acesso via putty quando é interno

Obs: Quando vou utilizar o MSTSC para conexão remota aos servidores Windows o PF faz o redirecionamento
certinho da porta utilizada para o IPdoservidor na porta 3389

Alguém tem alguma idéia do que pode estar acontecendo???

Obrigado pela ajuda!!!

renato_pacheco
(usa Debian)

Enviado em 18/10/2012 - 10:17h

Vc precisa liberar tb o FORWARD para a porta criada (3522):

iptables -A FORWARD -p tcp -s 0/0 --dport 3522 -j ACCEPT

 

gbrlCaim
(usa Debian)

Enviado em 18/10/2012 - 10:33h

Renato, Obrigado por ter respondido.

Fiz o que voce falou. Não deu certo.

Pelo pouco que eu entendo, Ao criar o redirecionamento de porta no firewall a requisição chega na porta 3522 e é encaminhada para porta 22 do servidor em questão, mesmo assim no servidor é necessário essa regra?

O que eu acho muito estranho é o seguinte, ao solicitar acesso via RDP a um servidor Windows pela porta 5050 ( ex. mstsc IPDEDICADO:5050 ) ele encaminha para 192.168.10.xxx:3389 e me libera o acesso...

Dei uma olhada no log do firewall e a requisição vinda do putty, não está nem chegando ao firewall.
E navego na internet sem problema e pela mesma conexão consigo acesso ao servidor windows...

Tem mais alguma ideia do que pode ser?

Vlw.

renato_pacheco
(usa Debian)

Enviado em 18/10/2012 - 10:50h

Kra, me desculpe. O q vc precisa liberar é o encaminhamento da porta 22 (porta destino). Portanto, é só trocar a porta 3522 para 22 na regra q pus.

gbrlCaim
(usa Debian)

Enviado em 18/10/2012 - 11:02h

Alterei a regra e nada...

Achei uma coisa interessante no /etc/ssh/sshd_config... na ultima linha a um parametro:

DenyGroups deniedssh

Onde eu encontro a lista desse grupo que está sendo bloqueado?

renato_pacheco
(usa Debian)

Enviado em 18/10/2012 - 11:09h

Mas pelo menos chega a conectar ou dá connection refused?

gbrlCaim
(usa Debian)

Enviado em 18/10/2012 - 11:13h

O putty retorna: Network error: Connection timed out

Pelo que eu entendo não está nem chegando no firewall ou o firewall esta dropando a conexão.

Cara... o mais [*****] é que pra todas as outras regras que eu tenho no firewall funcionam perfeitamente....

Acho que isso é mais erro do PF que do linux... que c acha?

renato_pacheco
(usa Debian)

Enviado em 18/10/2012 - 11:16h

Muito estranho. Mais estranho ainda é vc usar iptables no pfSense. O q eu sei é q o firewall dele é o ipfw...

gbrlCaim
(usa Debian)

Enviado em 18/10/2012 - 11:19h

Nao uso iptables no PF...
hehehehe

estou usando iptables no CentOS..

No PF faço as regras pelo WebGUI =D

renato_pacheco
(usa Debian)

Enviado em 18/10/2012 - 11:24h

Sabia q tinha algo errado... no seu CentOS o SELinux tá habilitado? Vc mexe com tcpwrappers (hosts.allow, hosts.deny etc.)? Se o firewall da sua rede é o pfSense, pq vc mexe com o firewall do CentOS?

gbrlCaim
(usa Debian)

Enviado em 18/10/2012 - 11:43h

Pra garantir que a requisição hora que chegar ao centOS nao seja bloqueado pelo firewall dele.

Não mexo... segue abaixo regras do firewall:

[root@news ssh]# iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `BANDWIDTH_IN:'
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 192.168.10.233 0.0.0.0/0 tcp spts:21:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 192.168.10.99 0.0.0.0/0 tcp dpt:5432 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 192.168.10.42 0.0.0.0/0 tcp dpt:5400 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 192.168.10.90 0.0.0.0/0 tcp dpt:5400 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000 state NEW,RELATED,ESTABLISHED
ACCEPT all -- 192.168.10.250 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 192.168.10.252 0.0.0.0/0 udp dpts:161:162 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22

Chain FORWARD (policy ACCEPT)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `BANDWIDTH_OUT:'
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `BANDWIDTH_IN:'
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3522
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22

Chain OUTPUT (policy DROP)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `BANDWIDTH_OUT:'
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:21:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:8080 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 192.168.10.42 tcp spt:5400 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 192.168.10.99 tcp spt:5432 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 192.168.10.90 tcp spt:5400 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:22 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:10000 state NEW,RELATED,ESTABLISHED
ACCEPT all -- 0.0.0.0/0 192.168.10.250
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 192.168.10.252 udp spts:161:162 state NEW,RELATED,ESTABLISHED

renato_pacheco
(usa Debian)

Enviado em 18/10/2012 - 12:31h

É aquele lance: se tá conectando localmente, é pq tá funcionando. Vc tá tentando sempre com o msm usuário, né?