Estava testando um cenário típico: quando o usuário está em casa, pode usar a internet normalmente, mas no escritório quero que eles usem VPN de forma obrigatória, de modo que aconteça de forma transparente, sem intervenção do usuário. Portanto, procurava ideias para reforçar isso. Posso configurar um gateway interno com detecção de informações do usuário, mas neste momento não tenho a opção de servidor interno.
Com base nos comentários, ele quer que seja transparente quando o usuário estiver externo ou interno, então precisará de ambos configurados e configurações de DNS para combinar. Pelo menos, essa seria a minha abordagem.
Para isso, sempre usamos na inicialização com certificado de máquina e Kerberos como SSO para login do usuário cliente.
A máquina inicia, conecta ao GP
Exterior: autentica com certificado, faz hip, etc., e constrói políticas limitadas. Assim que o usuário faz login, o SSO do usuário entra e tudo funciona (quase sempre).
Interno: a mesma coisa, autentica com certificado, faz hip, mas não constrói o túnel, tudo igual ao acima para o restante.
É relativamente transparente para o usuário. Melhor manter a autenticação igual em todos os modos.
O risco de reduzir seus requisitos de autenticação com base no IP de origem pré-nat é que, se alguém usar essa rede em casa ou em outra empresa, você praticamente criou uma fallback baseada apenas no IP.
Exatamente, essa é a finalidade de diferenciar o gateway interno e externo nas configurações do portal. Sem necessidade de configurações de DNS. Basta que o portal seja resolvido e acessível de dentro e de fora.
A única dúvida que tenho é que, se nenhuma configuração de gateway externo for feita, não tenho certeza se o cliente não apresentará uma falha de conexão, mas normalmente não, pois, como não está configurado, ele não tentará se conectar a qualquer gateway externo, e então não falhará.
Este cenário envolve apenas um portal acessível de fora e de dentro, e um gateway interno.
A outra solução é que o gateway interno seja um túnel completo, e o gateway externo seja um túnel dividido. A configuração do cliente do portal permitirá que o cliente determine automaticamente se é interno ou externo, e assim se conectará ao gateway adequado com túnel dividido ou completo. Assim, quando os usuários estiverem fora, navegarão na internet diretamente, mas quando estiverem conectados internamente, todo o tráfego passará pelo túnel. Este cenário envolve um portal acessível de fora e de dentro, e 2 gateways configurados, um interno e um externo.
Acho que você confundiu o papel do portal e do gateway.
Em ambos os cenários acima, o portal precisa ser alcançável de fora e de dentro. Para isso, basta colocar um registro A dentro do domínio público da empresa. Se o DNS interno tiver um encaminhador externo, ele será capaz de resolver de forma transparente. Então, a conexão com os gateways será contínua e definida pela configuração nas configurações do cliente no portal.
Edição: última possibilidade, você pode definir um gateway externo com a configuração de sem túnel.
Todas as empresas que trabalhei nos últimos 10-15 anos tinham configurações de DNS assim. Cada uma mantinha DNS interno e externo separadamente. Entendo que há maneiras melhores de fazer isso. Acho que estamos na mesma linha para o restante.
Sim. Os tempos estão mudando. 
Fizemos no passado uma duplicação interna/externa (como fizemos na rede interna por trás de um firewall com apenas um grande roteador entre usuários e servidores lol). Agora, a solução de DNS consegue lidar bem com isso. Trabalhar também com delegação é muito melhor e mais limpo. Trabalho em grandes empresas atualmente, com centenas de pessoas na equipe de TI, tudo é delegação e encaminhamento condicional. É muito mais fácil de manter e também ajuda a saber quem resolve. Por exemplo: a resolução de a.int.minhaempresa.com é feita internamente, e a.minhaempresa.com é resolvida externamente. Mas se você tentar resolver a.minhaempresa.com via interno, será enviado o encaminhamento adequado, sem problemas de segurança ou risco de túnel DNS. Também já vi DNS view hospedando seus próprios NS na DMZ.
Para websites públicos, fazemos apenas um DNAT de LAN para não confiável, NAT para LAN para DMZ. Não é necessário resolver o IP local do servidor.