Impossible de se connecter au serveur ipsec fonctionnant dans docker derrière un pare-feu

Vos règles iptables à partir des commentaires de la question :

-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 500 -j ACCEPT 
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 4500 -j ACCEPT 
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 53 -j ACCEPT

Je ne vois pas vraiment pourquoi vous auriez besoin de faire suivre le port 53 : rendre le serveur DNS de votre réseau interne visible par tout le monde sur Internet, c'est favoriser les attaques par usurpation de DNS - ce n'est pas une bonne idée. Une fois le VPN connecté, vous pourrez y accéder en toute sécurité via le tuyau VPN sans aucune règle de pare-feu sur l'hôte de la passerelle Internet. Je vous recommande de supprimer la règle FORWARD pour le port UDP 53, sauf si vous avez une très bonne raison de le faire.

Les règles ACCEPT de la table de filtrage FORWARD d'iptables permettent uniquement au système d'acheminer le trafic qui est déjà correctement adressé à la destination. Puisque votre serveur IPsec semble avoir une adresse 192.168.*.*, vos clients ne peuvent pas utiliser cette adresse pour l'atteindre via Internet.

Au lieu de cela, vous devrez configurer les clients pour qu'ils utilisent l'adresse IP publique du serveur de passerelle Internet, et le serveur de passerelle a besoin de certaines règles DNAT pour rediriger le trafic IPsec entrant vers le serveur IPsec.

Ces règles sont nécessaires sur le serveur de la passerelle Internet en plus des règles FORWARD que vous avez déjà :

-t nat -A PREROUTING -i <internet-side NIC> -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.2.37:500
-t nat -A PREROUTING -i <internet-side NIC> -p udp -m udp --dport 4500 -j DNAT --to-destination 192.168.2.37:4500

Comme il ne semble pas y avoir de suivi automatique des connexions pour IPsec, vous pouvez également avoir besoin des règles inverses pour le trafic sortant :

-t nat -A POSTROUTING -o <internet-side NIC> -s 192.168.2.37/32 -p udp -m udp --sport 500 -j SNAT --to-source <public IP>
-t nat -A POSTROUTING -o <internet-side NIC> -s 192.168.2.37/32 -p udp -m udp --sport 4500 -j SNAT --to-source <public IP> 

(Je ne suis pas vraiment sûr de cette partie : essayez d'abord sans ces règles, et surveillez les réponses sortantes sur l'interface de la passerelle Internet. Si les paquets IPsec sortants ont 192.168.2.37 comme IP source, ajoutez les 2 règles SNAT ci-dessus. Si l'IP source est déjà modifiée par l'IP publique de l'hôte de la passerelle Internet, alors la règle DNAT suit avec succès la connexion et vous n'aurez pas besoin des règles SNAT).

Lorsque le trafic VPN du client arrive à l'hôte de la passerelle Internet (en utilisant initialement son adresse IP comme destination), le trafic entrant passe d'abord par la table PREROUTING. Les règles DNAT qu'elle contient remplacent l'adresse de destination. Ensuite, le trafic entrant passe par la vérification du routage : puisque la règle DNAT vient de remplacer l'IP de destination, le trafic n'est plus adressé à l'hôte de la passerelle Internet lui-même, il passe donc par la table de routage puis par la table de filtrage FORWARD. Après cela, il sort par l'interface "inside" de l'hôte de la passerelle Internet vers l'hôte IPsec.

L'hôte IPsec recevra des paquets avec sa propre adresse 192.168.2.37 dans les en-têtes des paquets IP, mais dans le contenu crypté, il y aura l'IP publique originale du serveur de la passerelle Internet. L'hôte IPsec doit être conscient de NAT_TRAVERSAL pour gérer cela avec succès.

Lorsque l'hôte IPsec répond, l'hôte de la passerelle Internet devra remplacer l'IP source des paquets IPsec sortants par une IP publique valide.