Si les utilisateurs ont un problème de route asymétrique entre l’envoie d’un paquet et sa réception ce qui entraîne une rupture de connexion de la part du FireWall, il faut commencer par regarder la configuration des interfaces car c’est à cet endroit que nous effectuons un routage.
Pour rappel, le FireWall divise en quatre grandes classes l’ensemble des classe IP de l’UFC (chacune à sa VRF).
Sur le FW, plusieurs de ces classes sont réunis et il faut faire extrêmement attention à ne pas créer sur la machine VPN un routage inter-classe qui entraînera pour le moins un dysfonctionnement pour l’utilisateur (au pire un dysfonctionnement d’une partie du réseau de l’UFC).
Avec le code suivant :
auto eth0.168
iface eth0.168 inet static
address 172.20.16.220
netmask 255.255.255.0
network 172.20.16.0
broadcast 172.20.16.255
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
up ip rule add fwmark 18 table admin.pres
down ip rule del fwmark 18
down ip route del table admin.pres
Nous avons deux règles très importantes :
la première :
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
qui implique une route par défaut pour tous les utilisateurs VPN du tag 18 (admin.pres).
la seconde :
up ip rule add fwmark 18 table admin.pres
car c’est par elle que l’on affecte au client le tag 18.
Si le code dans le fichier /etc/network/interfaces ressemble à
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
ip up rule add fwmark 18 table admin.pres
Tous les clients de ce réseaux ne seront pas affecté au tag 18 et donc tout leur trafic transitera par l’interface de routage par défaut de la machine qui est sans aucun doute dans une VRF distincte et donc entraînera un dysfonctionnement des connexion de ces clients vers l’extérieur de leur réseau de connexion.
