Conselhos para configurar um SonicWALL NSA 2400 para usar duas sub-redes e o modo de ponte L2

Question

Esta postagem não é uma cópia exata de Como configurar o acesso remoto a várias sub-redes atrás de um SonicWALL NSA 2400 . No entanto, estou tendo este problema, quase literalmente. Infelizmente, até pagamos o suporte da SonicWALL e até mesmo eles estão sendo lançados através de loops.

Quando nos diferenciamos, estou simplesmente tentando usar o modo de ponte de camada 2. Sem NAT, sem roteamento. Nosso desejo é fazer com que o SonicWALL não faça mais do que ouvir na ligação, bloquear todo o tráfego, exceto selecionar portas UDP e TCP, e fornecer inspeção com informações de estado para todos os outros tráfegos indesejados, como ataques de negação de serviço, antivírus, anti-spyware. A interface X1 é configurada na sub-rede A. O restante dos IPs utilizáveis na sub-rede é atribuído a servidores conectados ao switch na porta X2 (DMZ).

Até recentemente, essa configuração funcionou muito bem. No entanto, agora estamos diante de um problema. Usamos toda a sub-rede A e exigimos mais, de modo que recebemos outra sub-rede / 28. Os servidores em execução nesta sub-rede estão conectados ao mesmo switch na porta X2 e as VLANs não estão sendo usadas, portanto, temos duas redes que vivem dentro do mesmo domínio de broadcast. Isso pareceu bom, porque tudo o que o SonicWALL deve fazer é a inspeção de pacotes e não se importar com o aspecto de roteamento do tráfego que passa por ele. Nós teríamos o roteador da rede (que não estamos controlando) na porta X1, preocupados com o roteamento entre as duas sub-redes que estão, na verdade, no mesmo domínio de transmissão.

Da internet, esta configuração funciona bem. Somos capazes de acessar as redes de sub-rede A e de sub-rede B. Ocorre um problema quando queremos que as duas redes se comuniquem com entre si . Esperávamos que as duas redes usassem o roteador no outro lado do SonicWALL para se comunicarem entre si, mas provei que os pacotes não passam do SonicWALL. Não há logs de firewall indicando que está descartando a comunicação devido a regras. Em vez disso, quando executo uma captura de pacote no SonicWALL, posso ver que os pacotes entram na porta X2 e não são encaminhados. O status simplesmente diz "Recebido" (Que, estranhamente, não pode ser encontrado como um status válido em QUALQUER documentação (a documentação diz "DROPPED" é para queda de tráfego devido a uma regra de firewall)).

O suporte me enviou o documento exato mencionado na postagem acima, mas não se aplica a essa situação. Depois de conversar com o suporte mais do que difícil por dias, finalmente fui sugerido para fazer nada mais do que adicionar uma rota estática:

Fonte: Qualquer, Dest: sub-rede B, gateway: 0.0.0.0, interface X2.

A tabela de roteamento atual tem apenas os itens padrão que ela adiciona por conta própria. Então, mesmo que você não saiba nada sobre o SonicWALL especificamente, diga-me se adicionar a rota estática acima faz sentido para qualquer um. A tabela atual é:

Fonte: Qualquer, Dest: Sub-rede Um gateway, gateway: 0.0.0.0, interface X1. Fonte: Qualquer, Dest: Sub-rede A, gateway: 0.0.0.0, interface X1. Fonte: Qualquer, Dest: Qualquer, gateway: Sub-rede Um gateway, interface X1.

Parece estranho para mim que nenhum dos valores já seja X2. Eu sinto como se o fato de um gateway de sub-rede A ser o único motivo para o tráfego sair da sub-rede A, mas não faz sentido como ele volta, já que isso deve deixar a interface X2 e a tabela acima tem X1 listada. Também é interessante que a sub-rede B seja capaz de se comunicar com a Internet, o que eu acho que é devido à última regra. O gateway da sub-rede A e B tem o mesmo endereço MAC: portanto, deve ser apenas uma coincidência que ele funcione. Ainda não faz sentido como o tráfego chega a qualquer sub-rede inicialmente da Internet.

    

Answer 1

Acontece que ninguém foi capaz de resolver o meu problema. Falei com o suporte da SonicWALL por dois meses e não recebi nada além de "soluções" inusitadas. Eles deixaram bem claro que não entenderam os dispositivos que apoiaram e me deram soluções inaceitáveis. Eles não se importaram com o que eu pensava sobre suas soluções inaceitáveis, porque tudo o que fizeram foi sugeri-los novamente. Não há nenhum software de emulação para esses produtos (pelo menos a Cisco tem um rastreador de pacotes) e eles são bem caros, então não havia como testar suas soluções ridículas além do pequeno período de tempo que eu tive no servidor ao vivo -Tempo. Eles também não respeitaram isso e me ligaram na segunda-feira e pediram acesso ao SonicWALL. Eles pareciam desconcertados quando eu disse absolutamente não.

O pior suporte para produtos empresariais que eu já tive, especialmente porque não era livre para ser tratado mal. Nós abandonamos o caso, e eu tenho uma suspeita muito alta que eu encontrei é um bug em seu software. Teria sido muito melhor se eles apenas admitissem isso em vez de me empurrar por dois meses.

Solução: Nós despejamos as duas sub-redes para uma grande, que poderia suportar a maior quantidade de hosts.

    

Answer 2

post antigo, mas vale a pena um bom comentário sobre o status "recebido" no monitor de pacotes. Não consegui encontrar nada sobre esse status na documentação da Sonicwall / Dell. Finalmente tenho uma tecnologia para explicar, na verdade, tenho uma breve descrição ...

Recebido significa que o pacote foi consumido pela interface. Isso significa que o pacote não o fez internamente na rede. O outro uso para o recebimento está em um cenário de VPN em que o pacote é recebido e descriptografado.

    

Answer 3

Parece que você está tentando fazer com que a sonicwall apenas detecte o tráfego, eu configuraria uma porta espelhada (no switch) para isso e depois configuraria as interfaces wan para o sniffing. Eu configuraria a porta como uma zona de 'sniffing' também, já que você não se importa com o roteamento, porque é que o tráfego está adiantado? Não tenho certeza se é isso que você estava tentando fazer ...

Eu tenho usado sonicwall por vários anos, eu gosto de todos os seus produtos em sua maior parte. Não posso dizer que eu realmente uso muito o suporte, mas tive altos e baixos com as melhores chamadas de suporte. Normalmente, a primeira e a segunda linha de suporte são bastante fracas em qualquer lugar.

Usuário do Sonicwall NSA

    

Answer 4

Após 3 semanas, Sonicwall finalmente voltou para mim com uma resposta e, embora eu tenha incluído um link para esta página, eles ainda me deram a mesma resposta que você. O suporte deles não parece saber a diferença entre a camada 2 e a camada 3 no modelo OSI.

Eu fiz uma reclamação e mandei um dos funcionários de suporte me telefonar, mas ele não parecia saber o que estava fazendo e eu tive que continuar corrigindo ele, ele finalmente desistiu e aceitou que estava além dele e disse ele precisaria passá-lo para um engenheiro.

Alguém deseja US $ 15.000 em NSAs de sonicwall? Claramente, são problemas com o Sonicwall Layer 2 Bridging, para não mencionar o suporte que leva três semanas para enviar uma resposta automática por e-mail.

    

Answer 5

Possível solução / correção para isso: Instale um roteador barato como um roteador de acesso simples entre as duas sub-redes. Aponte uma rota estática para ela a partir do painel sonicwall para que todo o tráfego que passa entre as duas sub-redes ocorra através do 'outro' roteador.

    

Answer 6

Se você estiver executando o modo de ponte, há uma opção na interface de ponte para "não rotear nesse par de ponte", que resolve o problema e as sub-redes podem falar novamente (isto é: uma passagem verdadeira).

O problema depois disso é que todo o tráfego sai, atinge seu roteador e está sujeito a regras de firewall no caminho de volta (então você precisa de mais regras para permitir seus próprios ip's). Também pode ser uma dor quando você tem um packetshaper antes de seu roteador (ou mesmo se o seu roteador tiver apenas uma interface de 100m em vez de 1gb), pois isso sem dúvida moldará o tráfego à medida que ele passa e diminui tudo. É por esta razão que entrei em contato com a sonicwall e concordo, eles são terríveis e eu não estarei renovando o contrato de suporte quando for devido. Tudo que eu recebo deles são respostas irrelevantes e coladas que são completamente inúteis.

Temos um NSA 4500 que não é um kit barato e eu esperava mais deles. Vamos esperar que a aquisição da Dell possa mudar as coisas. Eu duvido que ...

    

Answer 7

O problema é que você não usou uma VLAN, você tinha sub-redes sobrepostas no mesmo domínio de broadcast de ethernet. Isso é design ruim e sempre será.