[OpenVPN] Site à site - coupures intempestives

jdh

Sous pfSense 1.2.3, il n'est pas possible d'avoir des règles pour le flux OpenVPN : la preuve, il n'y a pas d'onglet OpenVPN.
Sous pfSense 2.0RC, il est possible d'avoir des règles pour le flux OpenVPN ! De plus, pfSense intègre l'administration des certificats.

Dans un contexte prod, on peut considérer OpenVPN comme certificats de confiance à partir du moment où on gère correctement les certificats (en mettant à jour les CRL par exemple). Mais je n'accorderai de certificats qu'au personnel de l'entreprise : les intervenants extérieurs ne devraient pas utiliser le même accès ! Dans ces cas, on peut se passer de filtrage et rester en 1.2.3.

Je n'ai pas noté de déconnexion intempestive (dès lors que l'on active le "ping de maintien").

bezourox

Bonjour,

Sous 1.2.3, effectivement pas d'onglet VPN en natif, mais ce n'est pas pour autant qu'on ne peut pas gérer le flux sur le tunel…

http://doc.pfsense.org/index.php/OpenVPN_Traffic_Filtering_on_1.2.3

En revanche, vous me parlez de ping de maintien à activer, ou se trouve cette option ? Il faut sans doute que je l'active.

zsunol

Bonjour,

Il me semble que cette option ne soit pas dispo, par contre coté client dans la conf tu peux la modifier / activer:

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120

@bezourox:

Bonjour,

Sous 1.2.3, effectivement pas d'onglet VPN en natif, mais ce n'est pas pour autant qu'on ne peut pas gérer le flux sur le tunel…

http://doc.pfsense.org/index.php/OpenVPN_Traffic_Filtering_on_1.2.3

En revanche, vous me parlez de ping de maintien à activer, ou se trouve cette option ? Il faut sans doute que je l'active.

bezourox

Ok je viens de check mes fichiers de conf et tout me parait OK :

Côté serveur :
Mon /var/etc/openVPN_server1.conf

writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
daemon
keepalive 10 120
ping-timer-rem
persist-tun
persist-key
dev tun
proto tcp-server
cipher BF-CBC
up /etc/rc.filter_configure
down /etc/rc.filter_configure
ifconfig 10.0.7.1 10.0.7.2
lport 1193
push "dhcp-option DOMAIN blabla.local"
push "dhcp-option DNS 10.163.135.14"
push "dhcp-option NTP 10.163.135.14"
route 10.145.7.0 255.255.255.0
secret /var/etc/openvpn_server1.secret
comp-lzo
persist-remote-ip
float
–ifconfig 10.0.7.1 10.145.7.4
management 127.0.0.1 1193

Côté client :
Mon /var/run/openvpn_client1.conf

writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
daemon
keepalive 10 120
ping-timer-rem
persist-tun
persist-key
dev tun
proto tcp-client
cipher BF-CBC
up /etc/rc.filter_configure
down /etc/rc.filter_configure
remote 109.2.99.144 1193
lport 1195
ifconfig 10.145.7.2 10.145.7.1
route 10.163.135.0 255.255.255.0
secret /var/etc/openvpn_client1.secret
comp-lzo
–ifconfig 10.145.7.4 10.0.7.1

Le problème vient du côté client où je vois les logs me disant que le trafic a été bloqué.
On voit ici le résultat de mes 2 tests, un ping et une connexion SSH sur 2 machines.

Aug 23 11:38:55 VPN 10.163.135.29:1763 10.145.7.17:22 TCP:S
Aug 23 11:39:14 VPN 10.163.135.29 10.145.7.12 ICMP

Côté serveur, rien à signaler…

Le message d'erreur suivant montre qu'une règle me bloque (la 48)
Où trouve t-on ces règles ?

The rule that triggered this action is:
@48 block drop in log quick all label "Default deny rule

jdh

Il est à conseiller de suivre les indications du site d'OpenVPN et, notamment, du choix d'udp comme protocole transport !

NFS, qui est un protocole très sérieux et établi, utilise le transport par … udp !

Mais là, dans le cas d'un VPN, il est IMPORTANT de comprendre les motivations du choix udp !
Au besoin, lire les explications CALECA ou de FrameIp (de mémoire).

Perso, j'avais initialement choisi, pour une entreprise et pour ma première mise en oeuvre d'OpenVPN, d'utiliser 443/tcp (c'est à dire https).
C'était une mauvaise bonne idée ...

De même, je reste circonspect sur la "bonne idée" de comp-lzo ...

bezourox

Bonjour et merci pour ces infos.
Par contre je viens de modifier la config pour utiliser udp sur mon vpn. J'ai modifié en conséquent les règles de filtrage, et pourtant, toujours le même problème…

zsunol

Bonjour,

Question toute bête as-tu essayé de lancer la connexion depuis un autre PC ( xp sans Antivirus avec FW :-\ ) et une connexion internet différente? ( de chez toi par exemple)

zs

bezourox

Bonjour,

Je me vois mal ramener chez moi la tour sur laquelle j'ai mis pfsense juste pour tester si ça marche mieux ;D ;D
Et puis je n'y vois pas l'intéret… le problème ne vient pas de l'OS puisque j'ai testé du Windows mais aussi du ssh sur terminal linux.
De plus la connexion internet est stable, le ping est continu, et les logs pfsense me parlent d'un blocage par une règle d'interdiction par défaut.
Donc pour moi le problème c'est pfsense, pas ma connexion internet ou un client distant du vpn

zsunol

ok ;)
@bezourox:

Bonjour,

Je me vois mal ramener chez moi la tour sur laquelle j'ai mis pfsense juste pour tester si ça marche mieux ;D ;D
Et puis je n'y vois pas l'intéret… le problème ne vient pas de l'OS puisque j'ai testé du Windows mais aussi du ssh sur terminal linux.
De plus la connexion internet est stable, le ping est continu, et les logs pfsense me parlent d'un blocage par une règle d'interdiction par défaut.
Donc pour moi le problème c'est pfsense, pas ma connexion internet ou un client distant du vpn

bezourox

Problème résolu.
Le problème était le mauvais routage sur le poste de test distant.