Accueil / Articles / Autoriser son adresse IP : pare-feu SQL Server et Azure SQL

› Article

Autoriser son adresse IP dans le pare-feu de SQL Server et d'Azure SQL.

Une connexion refusée alors que tout est correct vient souvent d'une règle de pare-feu qui ne connaît pas votre adresse IP. Voici comment la trouver, l'autoriser proprement et la retirer ensuite.


Quelle adresse faut-il autoriser ?

Le serveur ne voit pas l'adresse de votre poste (192.168.x.x), mais l'adresse publique de votre connexion, celle de votre box, de votre réseau d'entreprise ou de votre VPN.

Le plus simple est de la demander à un site dédié, comme monip.click, outil gratuit sans publicité que nous avons créé. Il affiche l'adresse vue depuis Internet. En ligne de commande, curl https://monip.click renvoie directement l'adresse en texte brut.

  • Une connexion domestique a souvent une adresse dynamique : elle peut changer, et la règle devient inutile.
  • Derrière un réseau d'entreprise ou un VPN, plusieurs adresses de sortie peuvent exister : demandez-les à l'équipe réseau.
  • Connectez-vous depuis le poste concerné : l'adresse change selon le réseau (domicile, bureau, partage de connexion du téléphone).

Azure SQL Database : règle de pare-feu du serveur

L'erreur 40615 (« Client with IP address ... is not allowed to access the server ») indique l'adresse refusée. On peut l'autoriser depuis le portail Azure, ou en T-SQL, dans la base master :

T-SQL
-- Autoriser une adresse (début et fin de plage identiques)
EXECUTE sp_set_firewall_rule N'Poste-admin', '203.0.113.10', '203.0.113.10';

-- Lister les règles du serveur
SELECT name, start_ip_address, end_ip_address FROM sys.firewall_rules;

-- Retirer la règle quand elle n'est plus utile
EXECUTE sp_delete_firewall_rule N'Poste-admin';

Une règle de niveau base (sp_set_database_firewall_rule) limite l'accès à une seule base : c'est plus restrictif, donc préférable quand c'est suffisant.

SQL Server sur serveur ou machine virtuelle

Le pare-feu Windows doit autoriser le port de l'instance (1433 par défaut) depuis l'adresse concernée, et celle-là seulement :

PowerShell
New-NetFirewallRule -DisplayName "SQL Server 1433 - poste admin" `
    -Direction Inbound -Protocol TCP -LocalPort 1433 `
    -RemoteAddress 203.0.113.10 -Action Allow

Pour vérifier l'adresse qu'une session présente réellement au serveur :

T-SQL
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id = @@SPID;

Dans Azure SQL, cette adresse peut être celle d'une passerelle interne : fiez-vous plutôt à l'adresse indiquée par l'erreur 40615.

Les bonnes pratiques

  • N'ouvrez jamais la plage complète (0.0.0.0 à 255.255.255.255) : c'est exposer la base à tout Internet.
  • Limitez à une adresse unique, ou à la plus petite plage possible.
  • Supprimez les règles temporaires dès la fin de l'intervention. Une règle oubliée reste active des années.
  • Pour un accès durable, préférez un réseau privé : VPN, point de terminaison privé (Private Endpoint), serveur de rebond.
  • N'exposez pas le port 1433 directement sur Internet pour une instance hébergée sur un serveur.

Outil gratuit, sans publicité : monip.click

Affichez en un clic votre adresse IP publique, celle à déclarer dans un pare-feu. En ligne de commande : curl https://monip.click.

Ouvrir monip.click →

À retenir

  • Il faut autoriser l'adresse IP publique de la connexion, pas l'adresse locale du poste.
  • Sur Azure SQL, la règle se pose au niveau serveur ou base ; l'erreur 40615 donne l'adresse refusée.
  • Autorisez une adresse précise, puis supprimez la règle quand elle ne sert plus.
  • Pour un usage régulier, préférez un VPN ou un point de terminaison privé.

Un incident, un audit, une question ?

Un premier échange suffit à cadrer l'urgence et le périmètre.

Demander une intervention