Ananias,
Eu gostaria de lembrar que a comunidade não recebe nenhum tipo de patrocínio do Endian e quem participa dela, faz porquê gosta do produto ou porquê gosta de ajudar e/ou compartilhar conhecimento. Ninguém tem a obrigação de ajudar e ou de resolver o seu problema.
Caso você queira um comprometimento sério, procure um profissional do ramo que possa ajudar nas soluções dos seus problemas.
Digo isso de uma forma meio rígida, pois eu não me agradei da sua atitude final, se o Endian não serve para os seus propósitos, acho que você está no direito de escolher e testar outras soluções até encontrar uma que agrade ou que preencha todas as suas expectativas. Mas vir para o forum com um ar de desaforo dizendo "não consegui resolver o meu problema então eu vou embora", é um pouco desrespeitoso com o restante da comunidade e principalmente com quem dedicou um pouco do seu tempo para te ajudar.
Agora que eu falei o que ficou entalado na minha garganta, vou comentar sobre o teu problema.
A solução que eu apontei usando uma entrada de DNS interna, é a solução mais indicada para este tipo problema e é a solução que funciona de uma forma transparente. Se o seu aplicativo tem o endereço do servidor de dados "hardcoded", eu preciso comentar que ele foi muito mal-escrito e que você deve ficar atento para a qualidade do software que você está usando.
A propósito... não é recomendável fazer consultas a base de dados diretamente através da internet, pois estas podem acabar tendo um tamanho considerável e causando uma provavel lentidão na aplicação além dos riscos de segurança envolvidos.
Se o aplicativo não tem uma forma padronizada para acesso remoto, verifique a possibilidade de executar ele remotamente através de um terminal service ou citrix metaframe. Estas soluções evitariam a necessidade de trafegar um grande volume de dados através da internet.
Explicando o problema:
O ideal seria você dedicar um tempinho para estudar e entender melhor sobre como funciona o protocolo tcp/ip, mas vou tentar resumir de uma forma bem simples e didática:
Computador A (cliente com ip 192.168.0.15)
Computador B (banco de dados com o ip 192.168.0.10)
Endian 192.168.0.1
Quando A tenta conectar no ip público, 200.222.222.222, o endian recebe este pacote e redireciona para B.
B recebe o pacote de A e responde para A. Como A está na mesma rede que B, B entrega o pacote diretamente para A. A por sua vez, recebe o pacote assinado com o ip de origem de B. A pensa que B está enviando pacotes incorretos, pois este afirma ter uma conexão com A, como a desconhece tal conexão, ele descarta os pacotes recebidos.
Resumindo, 192.168.0.15 mandou um pacote para 200.222.222.222, mas o pacote de resposta veio com o ip de origem 192.168.0.10. Como 192.168.0.15 não conhece a conexão vinda de 192.168.0.10, ele passa a descartar estes pacotes como algo inválido (este é o problema que o tacioandrade estava falando anteriormente).
Como resolver:
- Da forma correta - usando DNS interno
- Da forma correta 2 - Acessos remotos usando VPN, desta forma os clientes sempre vão conectar no servidor de banco de dados 192.168.0.10 (dentro ou fora da empresa).
- Da forma completamente incorreta (o termo certo seria: gambiarra extrema, não tentem isto em casa) - Você pode criar uma regra de SNAT (Source NAT) dizendo que todo o tráfego com origem 192.168.0.0/24 e destino 192.168.0.10 na porta tcp 5230 deve ter o ip de origem alterado para o mesmo ip da rede verde do endian (ex: 192.168.0.1)
Depois uma nova regra dizendo que todo o tráfego com ip de origem 192.168.0.10 e porta de origem (atenção que é origem mesmo e não destino) 5230 com destino a rede 192.168.0.0/24 deve ter o ip de origem alterado para 200.222.222.222.
Desta forma, A manda um pacote para o endereço 200.222.222.222, que o endian redireciona para B trocando o ip de origem do pacote para 192.168.0.1. B pensa que está falando apenas com 192.168.0.1 e devolve este pacote. O endian (que sabe das coisas), vai encaminhar este pacote para A trocando o ip de origem dele para 200.222.222.222.
Moral da história:
A pensa que está falando com 200.222.222.222
B sempre vai pensar que é o endian que está conectando ao banco de dados, ele nunca vai ver A.
Talvez ainda precise adicionar um forward aqui e um forward ali no resto do seu firewall, mas isso eu deixo para você descobrir "se" e "onde" colocar o forward.
Voiala, problema resolvido.
Devo lembrar que esta é uma forma muito "não profissional" de resolver este problema e não deve ser usada pois é suja demais.
Não vou prestar suporte no forum para esta gambiarra, se você implementar é por sua conta e risco.
De qualquer maneira, eu encorajo você a testar outras soluções, acho que isto só vai acrescentar ao seu crescimento pessoal, mas o problema citado vai existir em qualquer distribuição que você testar.
Boa sorte