# [OPENVPN] Problème de routage (résolu)

## zyprexa

bonjour, je suis en train de m'arracher les cheveux sur un problème.

J'ai souscris  à un abonnement chez un fournisseur de service vpn basé sur openvpn.

Sont sympas ils filent même le fichier de conf avec le cerificat.

Sauf qu'une fois le tunnel mis en place les routes... deviennent dingues et je reçoi un beau message : "host unreachable"

En pré-requis je dirais qu'iptables est ouvert à fond, j'utilise la box de mon fai (10.0.0.1/ :Cool:  et ma machine est sur 10.0.0.14/8.

Le module tun est chargé, les droits sont permissifs (chmod 666 /dev/net/tun) et j'ai mis le script en place "the gentoo way" : /etc/openvpn/vpntunnel.conf && cd /etc/init.d/ && ln -s openvpn openvpn.vpntunnel

Le fichier de conf du fournisseur de service :

```
float

client

dev tap

proto udp

nobind

; CERT

ca /etc/openvpn/keys/ca.crt 

ns-cert-type server

cipher BF-CBC

; HOST

remote-random

remote anna.vpntunnel.se 10010

remote anna.vpntunnel.se 10020

remote anna.vpntunnel.se 1194

resolv-retry infinite

; redirect-gateway

; AUTH

auth-user-pass pass.txt

persist-key

persist-tun

comp-lzo

verb 3
```

Avant de lancer le vpn:

route -n :

```
0.0.0.0         10.0.0.1        0.0.0.0         UG    2003   0        0 wlan0

10.0.0.0        0.0.0.0         255.0.0.0       U     2003   0        0 wlan0

127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo
```

ip route show :

```
default via 10.0.0.1 dev wlan0  metric 2003 

10.0.0.0/8 dev wlan0  proto kernel  scope link  src 10.0.0.14  metric 2003 

127.0.0.0/8 via 127.0.0.1 dev lo 
```

cat resolv.conf :

```
domain home

nameserver 10.0.0.1
```

Apres avoir lancé le vpn :

/etc/init.d/openvpn.vpntunnel start

```
* Caching service dependencies ...                                                                                                [ ok ]

  * Starting openvpn.vpntunnel ...                                                                                                  [ ok ]

   * WARNING: openvpn.vpntunnel has started, but is inactive
```

tail /var/log/messages :

```
Dec 13 11:45:42 localhost start-stop-daemon: pam_unix(start-stop-daemon:session): session opened for user nobody by (uid=0)

Dec 13 11:45:42 localhost openvpn[11878]: OpenVPN 2.2.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Dec 13 2011

Dec 13 11:45:42 localhost openvpn[11878]: WARNING: file 'pass.txt' is group or others accessible

Dec 13 11:45:42 localhost openvpn[11878]: NOTE: the current --script-security setting may allow this configuration to call user-defined s

cripts

Dec 13 11:45:42 localhost openvpn[11878]: LZO compression initialized

Dec 13 11:45:42 localhost openvpn[11878]: Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]

Dec 13 11:45:42 localhost openvpn[11878]: Socket Buffers: R=[124928->131072] S=[124928->131072]

Dec 13 11:45:42 localhost openvpn[11878]: Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]

Dec 13 11:45:42 localhost openvpn[11878]: Local Options hash (VER=V4): 'd79ca330'

Dec 13 11:45:42 localhost openvpn[11878]: Expected Remote Options hash (VER=V4): 'f7df56b8'

Dec 13 11:45:42 localhost openvpn[11879]: UDPv4 link local: [undef]

Dec 13 11:45:42 localhost openvpn[11879]: UDPv4 link remote: 178.73.212.236:10010

Dec 13 11:45:42 localhost /etc/init.d/openvpn.vpntunnel[11681]: WARNING: openvpn.vpntunnel has started, but is inactive

Dec 13 11:45:42 localhost openvpn[11879]: TLS: Initial packet from 178.73.212.236:10010, sid=f9e80d50 9528f8d7

Dec 13 11:45:42 localhost openvpn[11879]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to pre

vent this

Dec 13 11:45:42 localhost openvpn[11879]: VERIFY OK: depth=1, /C=SE/ST=CA/L=SanFrancisco/O=Fort-Funston/CN=Fort-Funston_CA/emailAddress=me@myhost.mydomain

Dec 13 11:45:42 localhost openvpn[11879]: VERIFY OK: nsCertType=SERVER

Dec 13 11:45:42 localhost openvpn[11879]: VERIFY OK: depth=0, /C=SE/ST=CA/L=SanFrancisco/O=Fort-Funston/CN=server/emailAddress=me@myhost.mydomain

Dec 13 11:45:42 localhost openvpn[11879]: WARNING: 'dev-type' is used inconsistently, local='dev-type tap', remote='dev-type tun'

Dec 13 11:45:42 localhost openvpn[11879]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1574', remote='link-mtu 1542'

Dec 13 11:45:42 localhost openvpn[11879]: WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'

Dec 13 11:45:42 localhost openvpn[11879]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

Dec 13 11:45:42 localhost openvpn[11879]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Dec 13 11:45:42 localhost openvpn[11879]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

Dec 13 11:45:42 localhost openvpn[11879]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Dec 13 11:45:42 localhost openvpn[11879]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Dec 13 11:45:42 localhost openvpn[11879]: [server] Peer Connection Initiated with 178.73.212.236:10010

Dec 13 11:45:45 localhost openvpn[11879]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

Dec 13 11:45:45 localhost openvpn[11879]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 80.67.0.2,dhcp-option DNS 91.213.246.2,redirect-gateway def1,route-gateway 178.73.222.65,topology subnet,ping 10,ping-restart 160,ifconfig 178.73.222.91 255.255.255.192'

Dec 13 11:45:45 localhost openvpn[11879]: OPTIONS IMPORT: timers and/or timeouts modified

Dec 13 11:45:45 localhost openvpn[11879]: OPTIONS IMPORT: --ifconfig/up options modified

Dec 13 11:45:45 localhost openvpn[11879]: OPTIONS IMPORT: route options modified

Dec 13 11:45:45 localhost openvpn[11879]: OPTIONS IMPORT: route-related options modified

Dec 13 11:45:45 localhost openvpn[11879]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

Dec 13 11:45:45 localhost openvpn[11879]: ROUTE default_gateway=10.0.0.1

Dec 13 11:45:45 localhost openvpn[11879]: TUN/TAP device tap0 opened

Dec 13 11:45:45 localhost openvpn[11879]: TUN/TAP TX queue length set to 100

Dec 13 11:45:45 localhost openvpn[11879]: /sbin/ip link set dev tap0 up mtu 1500

Dec 13 11:45:45 localhost openvpn[11879]: /sbin/ip addr add dev tap0 178.73.222.91/26 broadcast 178.73.222.127

Dec 13 11:45:45 localhost openvpn[11879]: /etc/openvpn/up.sh tap0 1500 1574 178.73.222.91 255.255.255.192 init

Dec 13 11:45:45 localhost /etc/init.d/openvpn.vpntunnel[12480]: status: inactive

Dec 13 11:45:45 localhost openvpn[11879]: /sbin/ip route add 178.73.212.236/32 via 10.0.0.1

Dec 13 11:45:45 localhost openvpn[11879]: /sbin/ip route add 0.0.0.0/1 via 178.73.222.65

Dec 13 11:45:45 localhost openvpn[11879]: /sbin/ip route add 128.0.0.0/1 via 178.73.222.65

Dec 13 11:45:45 localhost openvpn[11879]: Initialization Sequence Completed
```

route -n :

```
0.0.0.0         178.73.222.65   128.0.0.0       UG    0      0        0 tap0

0.0.0.0         10.0.0.1        0.0.0.0         UG    2003   0        0 wlan0

10.0.0.0        0.0.0.0         255.0.0.0       U     2003   0        0 wlan0

127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo

128.0.0.0       178.73.222.65   128.0.0.0       UG    0      0        0 tap0

178.73.212.236  10.0.0.1        255.255.255.255 UGH   0      0        0 wlan0

178.73.222.64   0.0.0.0         255.255.255.192 U     0      0        0 tap0
```

ip route show :

```
0.0.0.0/1 via 178.73.222.65 dev tap0 

default via 10.0.0.1 dev wlan0  metric 2003 

10.0.0.0/8 dev wlan0  proto kernel  scope link  src 10.0.0.14  metric 2003 

127.0.0.0/8 via 127.0.0.1 dev lo 

128.0.0.0/1 via 178.73.222.65 dev tap0 

178.73.212.236 via 10.0.0.1 dev wlan0 

178.73.222.64/26 dev tap0  proto kernel  scope link  src 178.73.222.91 
```

cat /etc/resolv.conf :

```
# Generated by openvpn for interface tap0

nameserver 80.67.0.2

nameserver 91.213.246.2
```

ping www.free.fr:

```
ping: unknown host www.free.fr
```

en décommentant le paramètre default-gateway:

route -n :

```
0.0.0.0         178.73.222.65   128.0.0.0       UG    0      0        0 tap0

0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 wlan0

10.0.0.0        0.0.0.0         255.0.0.0       U     2003   0        0 wlan0

127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo

128.0.0.0       178.73.222.65   128.0.0.0       UG    0      0        0 tap0

178.73.212.236  10.0.0.1        255.255.255.255 UGH   0      0        0 wlan0

178.73.222.64   0.0.0.0         255.255.255.192 U     0      0        0 tap0
```

ip route show :

```
0.0.0.0/1 via 178.73.222.65 dev tap0 

default via 10.0.0.1 dev wlan0 

10.0.0.0/8 dev wlan0  proto kernel  scope link  src 10.0.0.14  metric 2003 

127.0.0.0/8 via 127.0.0.1 dev lo 

128.0.0.0/1 via 178.73.222.65 dev tap0 

178.73.212.236 via 10.0.0.1 dev wlan0 

178.73.222.64/26 dev tap0  proto kernel  scope link  src 178.73.222.91 
```

Après avoir tenté différentes choses, options, dns (google et opendns comme recommandé sur le site...) ainsi qu'en essayant d'inhiber les fichiers /etc/openvpn/up.sh et /etc/openvpn/down.sh je me suis résolu à installer le bouzin networkmanager pour l'avoir déjà installé chez un poto en constatant que "it just works" (pour un vpn également).

(Au passage, c'est agréable de constater qu'il n'y a plus besoin d'installer la moitié de gnome pour ça).

Avec networkmanager:

route -n :

```
0.0.0.0         178.73.222.1    0.0.0.0         UG    0      0        0 tap0

10.0.0.0        0.0.0.0         255.0.0.0       U     2      0        0 wlan0

127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo

178.73.212.236  10.0.0.1        255.255.255.255 UGH   0      0        0 wlan0

178.73.222.0    0.0.0.0         255.255.255.192 U     0      0        0 tap0
```

ip route show :

```
default via 178.73.222.1 dev tap0  proto static 

10.0.0.0/8 dev wlan0  proto kernel  scope link  src 10.0.0.14  metric 2 

127.0.0.0/8 via 127.0.0.1 dev lo 

178.73.212.236 via 10.0.0.1 dev wlan0  proto static 

178.73.222.0/26 dev tap0  proto kernel  scope link  src 178.73.222.40 
```

On respire mieux... maintenant j'arrive à lire...cependant :

```
ping www.free.fr

PING www.free.fr (212.27.48.10) 56(84) bytes of data.

From cms40.speckledfloor.com (178.73.222.40) icmp_seq=1 Destination Host Unreachable

From cms40.speckledfloor.com (178.73.222.40) icmp_seq=2 Destination Host Unreachable
```

Petit mix côté dns maintenant cat /etc/resolv.conf :

```
cat /etc/resolv.conf 

# Generated by NetworkManager

domain home

search home

nameserver 80.67.0.2

nameserver 91.213.246.2

nameserver 10.0.0.1
```

Bidouiller resolv n'y change rien (opendns, avec ou sans les dns de la box...)

J'espèrais faire fonctionner ça avec networkmanager et copier son comportement (je voudrais faire du cli-only) mais voila où j'en suis.

----------

## guilc

Alors oui, pour tout passer par le VPN, il faut bien :

```
redirect-gateway def1
```

Normalement, ça marche tout simplement. On constate d'ailleurs que ça a bien mis les bonnes routes (0.0.0.0/1 et 128.0.0.0/1).

Attention, la doc précise qu'il faut un argument à "redirect-gateway". Toi tu n'en as pas, mais les routes semblent correctes, donc a priori je pense que "def1" est l'option par défaut !

Ce qu'il faudrait, c'est un traceroute vers l'extérieur, voir pas ou ça passe (ex: traceroute 8.8.8. :Cool: .

La table de routage en configurant par networkmanager est à priori overkill. Pas besoin de changer la route par défaut, le redirect-gateway qui ajoute les routes 0.0.0.0/1 et 128.0.0.0/1 est justement là pour ça : pour ne pas changer la route par défaut, mais seulement la surcharger par une route de métrique inférieur passant pas l'intérieur du VPN.

A priori, je pense que le comportement de networkmanager est équivalent de :

```
redirect-gateway bypass-dhcp
```

[EDIT]

Pour te donner une idée, voila la conf que j'utilise sur mon laptop et qui fonctionne très bien, tout passe dans le VPN (sauf la connexion au serveur VPN of course  :Laughing:  ):

```
client

dev tun

proto tcp

remote 62.212.103.27 1194

resolv-retry infinite

script-security 2

nobind

persist-key

persist-tun

ca /etc/ssl/certs/XwingCA.pem

cert tatooine-openvpn-client.crt

key tatooine-openvpn-client.key

ns-cert-type server

tls-auth ta.key 1

cipher AES-256-CBC

comp-lzo

verb 2

redirect-gateway def1

```

----------

## zyprexa

Tout d'abord merci pour ta réponse  :Smile: 

L'argument def1 je l'avais essayé, mais sans plus de succès.

J'avais fait également des tests avec traceroute sur une URI et une adresse ip (dns orange je crois) mais les résultats ne me semblaient pas significatifs.

 *Quote:*   

> La table de routage en configurant par networkmanager est à priori overkill

 

Clairement

 *Quote:*   

> le redirect-gateway qui ajoute les routes 0.0.0.0/1 et 128.0.0.0/1 est justement là pour ça : pour ne pas changer la route par défaut, mais seulement la surcharger par une route de métrique inférieur passant pas l'intérieur du VPN.

 

Ces maudits masques ip ont toujours été ma bête noire...

Voici le traceroute avec redirect-gateway def1 (mon ip vpn au moment du test est  178.73.219.151) :

```
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

 1  * * *

 2  * * *

 3  * * *

 4  * * *

 5  * * *

 6  * * *

 7  178.73.219.151 (178.73.219.151)  1742.834 ms !H * *
```

Je l'ai pas précisé, mais une fois le vpn lancé je n'accède plus du tout au grand ternet.

----------

## zyprexa

A tête reposée j'ai finalement lancé un petit wireshark qui m'a montré l'interface gueulant sur le broadcast cherchant désespérément à faire sa résolution arp.

Un petit tour dans /proc/sys/net/ipv4/conf/all/proxy_arp et /proc/sys/net/ipv4/conf/all/arp_accept a réglé le problème.

 :Smile: 

----------

