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