# Pare-feu ufw: pourquoi le client OpenVPN passe ?!?

**URL:** <https://www.debian-fr.org/t/pare-feu-ufw-pourquoi-le-client-openvpn-passe/80817>\
**Category:** Support Debian\
**Tags:** pare-feu\
**Created:** [Décembre 19, 2019, 10:27 UTC](https://www.debian-fr.org/t/pare-feu-ufw-pourquoi-le-client-openvpn-passe/80817 "2019-12-19T10:27:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Steph92](https://www.debian-fr.org/user_avatar/www.debian-fr.org/steph92/32/8720_2.png) [@Steph92](https://www.debian-fr.org/u/Steph92)\
**Post date:** [Décembre 19, 2019, 10:27 UTC](https://www.debian-fr.org/t/pare-feu-ufw-pourquoi-le-client-openvpn-passe/80817/1 "2019-12-19T10:27:13Z")

</div>

Hello,

J’utilise depuis peu un VPS cz OVH sous Debian 10 (dernières versions de tous les composants logiciels).  
Face aux apparentes limites et au manque de doc du parefeu “Firewall Network” d’OVH, je me suis tourné vers **ufw** pour assurer une protection même envers les connexions issues du réseau OVH.

J’ai créé quelques règles simples:

```auto
# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To Action From
-- ------ ----
22/tcp ALLOW IN 87.88.0.0/16 (IP Bouygues mobiles)
22/tcp ALLOW IN xx.xx.xx.xx (IP de ma box)
3389/tcp ALLOW IN 10.8.0.2 (xRDP via VPN poste 1)
3389/tcp ALLOW IN 10.8.0.3 (xRDP via VPN poste 2)
3389/tcp ALLOW IN 10.8.0.4 (xRDP via VPN poste 3)

```

Curieusement, j’arrive à connecter mon client OpenVPN et à surfer sur le web sans avoir ajouté de règle autorisant l’accès au port 1194 d’OpenVPN sur le VPS.  
Pourtant j’ai bien " Default: deny (incoming) " dans le statut du pare-feu !?!  
Là, je pige pas bien… pouvez-vous SVP éclairer ma lanterne ?

Merci!

A+  
Stéph.

---

<div class="post-metadata">

**Author:** ![Steph92](https://www.debian-fr.org/user_avatar/www.debian-fr.org/steph92/32/8720_2.png) [@Steph92](https://www.debian-fr.org/u/Steph92)\
**Post date:** [Décembre 19, 2019, 11:10 UTC](https://www.debian-fr.org/t/pare-feu-ufw-pourquoi-le-client-openvpn-passe/80817/2 "2019-12-19T11:10:00Z")

</div>

Je m’auto-réponds…  
Une règle autorisant l’accès au port 1194 est présente dans iptable alors que je n’ai touché qu’au fw d’OVH qui est entièrement indépendant des iptables des VPS.

* * *

> ~# iptables-save | grep 1194  
> -A INPUT -p udp -m udp --dport 1194 -j ACCEPT

* * *

En fait, c’est le script d’installation d’OpenVPN qui s’en est chargé.

> ~# more openvpn-install.sh | grep iptable  
> ExecStart=/sbin/iptables -I INPUT -p $protocol --dport $port -j ACCEPT  
> …  
> ExecStop=/sbin/iptables -D INPUT -p $protocol --dport $port -j ACCEPT

* * *

**ufw** est assez limité puisqu’il n’affiche pas les règles déjà présentes dans “iptables” ☹

Affaire classée !

Stéph.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 19, 2019, 12:51 UTC](https://www.debian-fr.org/t/pare-feu-ufw-pourquoi-le-client-openvpn-passe/80817/3 "2019-12-19T12:51:36Z")

</div>

> [@](#):
>
> En fait, c’est le script d’installation d’OpenVPN qui s’en est chargé.

C’est très mal. Cela interfère de façon imprévisible avec la politique du pare-feu mise en place par l’administrateur local. Imprévisible car le résultat est différent selon que les règles du pare-feu sont appliquées avant ou après le démarrage du service openvpn.

Je suggère fortement de virer ces commandes du fichier openvpn.service et d’ajouter la règle qui va bien dans ufw.

> [@](#):
>
> **ufw** est assez limité puisqu’il n’affiche pas les règles déjà présentes dans “iptables”

Aucun gestionnaire de pare-feu ne fait ça. Tous ne font qu’afficher leurs propres règles et non les règles iptables réellement en place.