VPN Client

💡
Toutes les configurations sont commit sur mon github : https://github.com/Nathan0510/Blog

C'est pas trop tôt !

Effectivement ! Et mieux vaut tard que jamais.

Un L3VPN MPLS est assez simple à monter pour un opérateur. C'est qu'une simple VRF à configurer sur tous les PE du backbone.

Le plus compliqué est la sortie internet. Une VRF, c'est une table de routage différente. Il faut donc un équipement qui ait une patte dans le GRT (Global Routing Table) et une autre dans la VRF cliente.

Pour ce faire, on va utiliser un firewall Fortinet. En plus, ça permettra de sécuriser le trafic entrant et sortant du MPLS, pas mal nan ?

Configuration

LNS

Tout d'abord, on passe sur les LNS pour créer la VRF :

LNS1 & LNS2
vrf definition Customer1
 rd 64555:4200000000
 !
 address-family ipv4
  route-target export 64555:4200000000
  route-target import 64555:4200000000
 exit-address-family
!
interface Loopback65000
 vrf forwarding Customer1
 ip address 100.110.1.1 255.255.255.255

Le RD semble bizarre nan ? On en parle après 😋

Pourquoi créer une loopback ?

Pour monter les sessions PPP. Si vous vous en souvenez, le client PPPoE aura pour premier saut l'IP Loopback qu'on a défini sur le LNS (100.127.0.1) mais uniquement pour le GRT ! Tous les clients hors MPLS partagent celle ci, il n'y a pas de problème. Par contre dans le cas d'un L3VPN MPLS, il faut bien que le LNS sache dans quelle VRF monter la session PPP et lui donner le premier saut 😄

Donc une VRF = un client = une Loopback

Cette Loopback peut être mutualisée avec le LNS2, c'est d'ailleurs ce que j'ai fait.

Radius

Pour monter un client dans une VRF, il n'y a pas d'attribut défini comme la Framed-Route ou la Framed-IP-Address. On va utiliser un attribut spécifique vendeur Cisco : Cisco-Avpair.

nathan@naruto.ninja Cleartext-Password := "nathan"
    Service-Type := Framed-User,
    Framed-Protocol := PPP,
    Framed-MTU := 1492,
    Framed-IP-Address := 100.125.0.0,
    Framed-IP-Netmask := 255.255.255.255,
    Framed-Route := "10.1.2.0/24 100.125.0.0",
    Cisco-Avpair := "ip:vrf-id=Customer1",
    Cisco-Avpair := "ip:ip-unnumbered=Loopback65000"

sasuke@naruto.ninja Cleartext-Password := "sasuke"
    Service-Type := Framed-User,
    Framed-Protocol := PPP,
    Framed-MTU := 1492,
    Framed-IP-Address := 100.125.0.1,
    Framed-IP-Netmask := 255.255.255.255,
    Framed-Route := "10.1.1.0/24 100.125.0.1",
    Cisco-Avpair := "ip:vrf-id=Customer1",
    Cisco-Avpair := "ip:ip-unnumbered=Loopback65000"

Dans un MPLS, il faut que tous les subnets LAN du client puissent communiquer entre eux, il faut router le réseau LAN dans le PPP donc la framed-route ici.

On retrouve le Cisco-Avpair. Une pour la VRF : Customer1 et une autre pour la Loopback.

LNS1#sh subscriber session
Codes: Lterm - Local Term, Fwd - forwarded, unauth - unathenticated, authen -
authenticated, TC Ct. - Number of Traffic Classes on the main session

Current Subscriber Information: Total sessions 2
Uniq ID Interface    State    Service     Up-time  TC Ct. Identifier
11      Vi2.2        authen   Lterm       00:00:01 0      sasuke@naruto.ninja
10      Vi2.1        authen   Lterm       00:00:03 0      nathan@naruto.ninja


LNS1#sh ip route vrf Customer1
      10.0.0.0/24 is subnetted, 2 subnets
U        10.1.1.0 [1/0] via 100.125.0.1
U        10.1.2.0 [1/0] via 100.125.0.0
      100.0.0.0/32 is subnetted, 3 subnets
C        100.110.1.1 is directly connected, Loopback65000
C        100.125.0.0 is directly connected, Virtual-Access2.1
C        100.125.0.1 is directly connected, Virtual-Access2.2

Et côté CPE ?

Que dalle ! Hormis rajouter le LAN. Pas besoin de natter. Le but du MPLS est de fournir un L3VPN au client donc la communication intersites.

[admin@Naruto] > /ip address/export
/ip address
add address=10.1.2.1/24 interface=ether3 network=10.1.2.0

[admin@Naruto] /ip/address> /ping 10.1.1.1
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 10.1.1.1                                   56  63 11ms235us
    1 10.1.1.1                                   56  63 9ms357us
    2 10.1.1.1                                   56  63 10ms632us
    sent=3 received=3 packet-loss=0% min-rtt=9ms357us avg-rtt=10ms408us
   max-rtt=11ms235us

Bon super, le L3VPN MPLS est fonctionnel mais :

[admin@Naruto] /ip/address> /ping 1.1.1.1 src-address=10.1.2.1
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 1.1.1.1                                                      timeout
    1 1.1.1.1                                                      timeout
    2 1.1.1.1                                                      timeout
    3 1.1.1.1                                                      timeout
    sent=4 received=0 packet-loss=100%

J'arrive pas à joindre le net !

Et c'est normal, car le VPN du client n'a pas de default route. C'est là que rentre en jeu le forti !

Fortigate

Bon, d'abord, il faut le raccorder à notre réseau. J'ai pris la décision de le brancher sur Leaf2-B1 direct. Est ce une bonne pratique ? Je ne sais pas. Si on fait un client = un forti alors non ce n'est pas une bonne méthode.

On pourrait très bien penser à un firewall mutualisé. Sur un forti, on peut faire le même principe qu'une VRF avec un VDOM.

Une VRF = un routeur virutel
Un VDOM = un forti virtuel

Ce qui permet d'éviter un forti dédié par client.

Malheureusement, je ne peux pas faire de VDOM.... J'utilise la VM Forti et elle est bridée. Dommage ! J'aurai bien voulu tester 🙃

Bon reprenons notre configuration ! Le firewall aura trois interfaces (une pour l'OUT, une pour l'entrée MPLS et une autre pour le hosting, on pense à l'avenir). Bien sûr on propage aussi les VNIs dans la fabric.

vlan 2000
   name OUT-FORTI
!
vlan 2001
   name IN-FORTI
!
vlan 2002
   name MPLS-FORTI
!
interface Ethernet17
   description OUT-FORTI
   switchport access vlan 2000
   switchport mode dot1q-tunnel
!
interface Ethernet18
   description IN-FORTI
   switchport access vlan 2001
   switchport mode dot1q-tunnel
!
interface Ethernet19
   description MPLS-FORTI
   switchport access vlan 2002
   switchport mode dot1q-tunnel
!
interface Port-Channel20
   description PO_IN_LNS1
   switchport trunk allowed vlan 500,2000-2002
   switchport mode trunk
   mlag 20

Pourquoi avoir mis les ports en mode dot1q tunnel ?

La plupart du temps, les forti auront besoin que d'une interco avec les LNS pour monter les sessions BGP. On ne va pas sacrifier un VLAN par interface pour chaque forti...

Le VLAN 2000 servira pour tous les sorties OUT des forti, le 2002 pour le MPLS des clients.

Seule spécificité pour le VLAN IN-FORTI qui lui sera unique pour chaque forti client. En effet, il risque d'avoir des recouvrements de CVLANs si on utilise ce SVLAN pour tous les clients.

Pour les IPs :

Zone Interco LNS1 LNS2 Forti
Out 172.30.254.0/29 172.30.254.1 172.30.254.2 172.30.254.6
Mpls 172.31.254.0/29 172.31.254.1 172.31.254.2 172.31.254.6
interface GigabitEthernet1.20000100
 description OUT-FORTI
 encapsulation dot1Q 2000 second-dot1q 100
 ip address 172.30.254.1 255.255.255.248
end

interface GigabitEthernet1.20020100
 description MPLS-FORTI
 encapsulation dot1Q 2002 second-dot1q 100
 vrf forwarding Customer1
 ip address 172.31.254.1 255.255.255.248
end

J'ai choisi de commencer le CVLAN 100 pour les deux sorties. Si on rajoute un autre MPLS pour un autre client sécurisé par un fortigate, ce dernier aura pour CVLAN le 101 par exemple.

Pour le BGP :

GRT
config router bgp 64555
 bgp asnotation dot
 neighbor 172.30.254.6 remote-as 4200000000
 neighbor 172.30.254.6 description OUT-FORTI
  address-family ipv4
  neighbor 172.30.254.6 default-originate
  neighbor 172.30.254.6 route-map RM_CUSTOMER_PUB in
  neighbor 172.30.254.6 route-map RM_DEFAULT_ROUTE out
  
VRF
config router bgp 64555
  address-family ipv4 vrf Customer1
    redistribute static
    neighbor 172.31.254.6 remote-as 64086.59904
    neighbor 172.31.254.6 description MPLS-FORTI
    neighbor 172.31.254.6 activate
    neighbor 172.31.254.6 soft-reconfiguration inbound
    neighbor 172.31.254.6 route-map RM_DEFAULT_ROUTE in

Pour le GRT, on accepte que les IPs publiques du client en in et on annonce la default route.
Pour la VRF, on accepte que la default route en IN. On fait un redistribute static dans le BGP pour annoncer les subnets des framed-routes des clients PPP.

(Obligé d'ajouter bgp asnotation dot pour la prise en compte des AS 32 bits)

Et côté forti, ca donne quoi ?

Il est là le 4200000000 ! C'est bizarre cette AS vous trouvez pas ?

Pour répondre aux problématiques de la pénurie d'AS, le RIPE a décidé d'ouvrir un nouveau range mais celui codé sur 32 bits.

Et dans ce nouveau range, il y a des AS privées (4200000000 à 4294967294). J'ai décidé de partir sur ce range de 32 bits et pas l'autre (codé sur 16) pour avoir une délimitation des AS clients et des AS backbone.

Les BGP montent ! On peut voir ça avec la table de routage :

Je ne sais pas si vous avez vu, mais j'ai rajouté une Loopback. Mais pourquoi ?

Dans le futur, je voudrai montrer comment faire des IPsec / VPN SSL sur forti donc elle va me servir à ça mais aussi pour natter les flux sortants !

On ne peut toujours pas ping 1.1.1.1 mais on se rapproche !

[admin@Naruto] /ip/address> /ping 1.1.1.1 src-address=10.1.2.1
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 1.1.1.1                                                      timeout
    1 1.1.1.1                                                      timeout
    sent=2 received=0 packet-loss=100%  

Pour ce faire, on configure un pool d'IP pour natter :

Je met chaque interface dans une zone différente :

Dans Policy & Objets, je crée deux adresses :

Que j'appelle dans un groupe d'adresse :

Bon, là je crois que tous les préparatifs pour créer la policy sont enfin terminés !

Pour la règle de flux, ca se passe dans Policy & Object -> Firewall Policy :

On crée une règle de la zone MPLS vers la zone OUT. Dedans, on autorise le groupe avec tous les subnets LAN du client à accéder à all (Internet) sur tous les ports (all).

Verdict ?

[admin@Naruto] /ip/address> /ping 1.1.1.1 src-address=10.1.2.1
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 1.1.1.1                                    56 251 40ms437us
    1 1.1.1.1                                    56 251 23ms536us
    sent=2 received=2 packet-loss=0% min-rtt=23ms536us avg-rtt=31ms986us
   max-rtt=40ms437us

[admin@Naruto] /ip/address> /ping 8.8.8.8 src-address=10.1.2.1
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 8.8.8.8                                    56 251 39ms203us
    1 8.8.8.8                                    56 251 34ms693us
    sent=2 received=2 packet-loss=0% min-rtt=34ms693us avg-rtt=36ms948us
   max-rtt=39ms203us

Ca fonctionne !

Le client a donc son VPN intersites avec une sortie internet sécurisé par un firewall forti ! Plutôt stylé ça non ? On va se faire du blé, c'est moi qui vous le dit 😃

Et maintenant, le client nous demande de bloquer le flux vers 8.8.8.8. Comment fait on ?

Tout con ! On crée une autre policy avec un deny au lieu d'accept. Et en destination, on met l'IP de google (représenté par 8.8.8.8 ici).

Attention, il faut bien penser à mettre la policy au dessus de l'autre. Quand le paquet rentre dans le firewall, il parcourt règle par règle et voit s'il matche avec l'une d'entre elles.

Si la plus permissive est en première, le filtrage ne sert pas à grande chose !

[admin@Naruto] /ip/address> /ping 8.8.8.8 src-address=10.1.2.1
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 8.8.8.8                                                      timeout
    1 8.8.8.8                                                      timeout
    sent=2 received=0 packet-loss=100%

Nickel, le filtrage est good !

Améliorations

Cette épisode est pas parfait du tout !

Tout d'abord, je voulais partir sur des VDOM. C'est plus représentative de la réalité. Malheureusement, les joies du lab me rattrapent ☹️

Il manque la partie prise en main des CPE. Vu que le trafic passe par le firewall, il faut prendre en compte cela et permettre la redistribution des IPs de management (les IPs des PPP clients) dans le BGP.

Le forti n'est pas en HA (High Avaibility). Il faudra le mettre. Au cas où si le master tombe, le slave prend le relais. Il manque aussi la partie secours sur LNS2.

Il faut aussi faire de meilleurs règles de sécurité. On doit pouvoir vendre des licences UTM au client afin qu'il ait à disposition l'antivirus, le web filter, l'IPS, le WAF, etc.

Si le client demande à ce que ses communications intersites aient un filtrage. Comment fait on ?

Il faudrait faire une VRF par liaison et raccorder chaque VRF au forti. Et il est là l'avantage d'avoir utiliser un SVLAN pour l'entrée MPLS ! Une VRF = un CVLAN = le même port physique sur le forti.

Enfin bref, je commence à me retrouver bloquer dû aux différents constructeurs qui ne s'occupent pas de la partie formation. Mis à part payer une fortune pour avoir un instructeur et ainsi avec du matos pas bridé (spoiler Fortinet et Cisco) ...
Ce qui est bien dommage étant donné le bullshit complet des certifications hors de prix de certains revendeurs. Le monopole amène à ce genre de méthode...

Dans le prochain épisode consacré aux clients, je raccorderai une baie housing à cette VRF cliente ! Il faut bien que le client puisse profiter de son externalisation de son SI dans nos baies ahahahah

Je dois aussi faire la sortie internet de mon lab, c'est bien de le simuler via des loopback sur le routeur de transit mais rien de bien folichon. Ca serait quand même beaucoup plus stylé de brancher une VM Debian derrière un mikrotik client pour qu'elle accède à Internet nan ?

Je termine sur un petit mot de fin : Recherche aussi le tome 50 Naruto collector pas trop cher svp