Https/ssh mgmt over SSL VPN

VPN
1

H folks,

j’avais réfléchi à tout cela, donc j’ai décidé de poster ici pour voir si quelqu’un d’autre aurait des suggestions :

J’ai configuré un VPN SSL sur mon 40f. J’ai dû le faire de manière indirecte car mon FG est actuellement derrière mon modem ISP qui fournit une adresse privée 1918 à mon interface wan1. Sur le modem, j’ai configuré le transfert de port vers un port non standard et mon VPN SSL est configuré pour écouter sur une interface de boucle locale qui utilise un VIP pour correspondre de l’extérieur vers l’intérieur.

Je peux me connecter via le VPN SSL sans problème et je peux pinger à travers les réseaux locaux après avoir activé https, ssh, ping, etc. sur les interfaces et avoir construit les politiques nécessaires. Cependant, lorsque j’essaie de faire ssh ou d’utiliser https, je ne peux pas atteindre ma boucle locale pour la gestion ou toute autre interface où https/ssh est activé.

En analysant le trafic http, je vois le trafic sortir de ssl

024-03-18 00:08:53.129008 ssl.root in 10.199.24.1.55711 -> 10.10.10.10.7734: syn 4185843426 
2024-03-18 00:08:54.109256 ssl.root in 10.199.24.1.55711 -> 10.10.10.10.7734: syn 4185843426 
2024-03-18 00:08:55.129084 ssl.root in 10.199.24.1.55711 -> 10.10.10.10.7734: syn 4185843426 
2024-03-18 00:08:57.126960 ssl.root in 10.199.24.1.55711 -> 10.10.10.10.7734: syn 4185843426

Je ne voyais pas de réponse et j’ai lancé un debug flow utilisant src de ssl et dst ip/port de l’IP du LB. Lors de la tentative de démarrer une session https :

find SNAT : IP-10.10.10.10 (depuis l'IPPOOL), port-55760
policy-10 est matchée, act-accept
après iprope_captive_check() : is_captive-0, ret-matché, act-accept, idx-10
en-[Loopback], out-[], skb_flags-02000000, vid-0
gnum-100011, check-ffffffbffc02d3f0
après vérification : ret-no-match, act-drop, flag-00000000, flag2-00000000
vérifié gnum-10000e policy-4294967295, ret-no-match, act-accept
...
policy-4294967295 est matchée, act-drop
gnum-10000f résultat de la vérification : ret-matched, act-drop, flag-00000800, flag2-00000000
après vérification : ret-matched, act-drop, flag-00000800, flag2-00000000
iprope_in_check() vérification échouée sur la politique 0, suppression

iprope_in_check() vérification échouée sur la politique 0, suppression

Là, cela indiquerait que le trafic de SSL vers Loopback circule, mais il n’y a pas de chemin retour et par conséquent, le trafic est rejeté ? J’ai reconstruit et supprimé mes politiques, en élargissant les adresses source/destination pour tout/all. Je cherche à obtenir plus de directions sur ce que je pourrais manquer.

*ÉDIT 18/03*

le problème d’accès était dû au fait que les hôtes de confiance manquaient la plage SSL. Une fois appliquée, j’ai pu faire ssh & https sur ssl.

​

2

Vérifiez vos hôtes de confiance.
Ne pas utiliser la NAT dans la politique.
Vérifiez si vous avez une route de retour vers le pool SSL-VPN.
Utilisez-vous du PBR ? Si oui, vérifiez que vous avez configuré la politique correctement.

3

Mettez votre modem ISP en mode bridge afin qu’il transmette le public à votre pare-feu.

4

Peut-être vous manque-t-il une route de retour ?

5

Souvent, pour les interfaces de boucle locale, vous avez besoin de politiques dans les deux sens, essayez de créer les politiques IN/OUT entre votre boucle locale et le sslvpn !

6

Optez pour celui-ci ici.

7

super commentaire ; c’était le problème. il fallait ouvrir les hôtes de confiance pour inclure les adresses ssl

merci pour l’aide ici.

8

j’ai essayé cela – ce qui est étrange, c’est qu’en ayant activé cela, j’ai tout/all juste pour voir si je voyais réellement les hits sur la politique et je n’ai vu aucun hit sur la politique.

9

si vous utilisez le transfert de port… utilisez un VIP et incluez l’adresse de destination VIP dans la politique, pas l’IP de boucle locale. et vous avez besoin d’une politique entrante.