Einführung

Virtual Extensible LAN (Kurz VxLAN) bietet uns eine Möglichkeit Layer-2 Domäne über Layer-3 Netzwerke zu strecken.

In diesem Artikel werde ich eine Variante erklären, wie man mittels eines VPN-Tunnel, IPSEC und VxLAN ein Layer-2 Segment, verschlüsselt, über zwei verschiedene Standorte ausdehnen kann.

Ausgangslage

Was wollen wir hiermit erreichen?
Host A und Host B befinden sich im selben Netz (10.240.50.0/24), aber standort technisch sind beide getrennt. Wir werden versuchen mittels VxLAN und IPSEC die Pakete im selben Netz über die zwei Standorte zu übertragen.

 

Konfiguration von VxLAN over IPSEC in einer Fortigate in 4 einfache Schritte

Grundeinstellungen

Site A

config system interface
edit "internal3"
set ip 192.168.3.1 255.255.255.252
next
end

config router static
edit 1
set gateway 192.168.3.2
set device "internal3"
next
end

Site B

config system interface
edit "internal3"
set ip 192.168.3.2 255.255.255.252
next
end
config router static
edit 1
set gateway 192.168.3.1
set device "internal3"
next
end

 

VPN-Tunnel einrichten – Phase 1

Site A

config vpn ipsec phase1-interface
edit "VPN_to_B"
set interface "internal3"
set peertype any
set proposal aes128-sha256
set encapsulation vxlan
set encapsulation-address ipv4
set encap-local-gw4 192.168.3.1
set encap-remote-gw4 192.168.3.2
set remote-gw 192.168.3.2
set psksecret secret
next
end

Site B

config vpn ipsec phase1-interface
edit "VPN_to_A"
set interface "internal3"
set peertype any
set proposal aes128-sha256
set encapsulation vxlan
set encapsulation-address ipv4
set encap-local-gw4 192.168.3.2
set encap-remote-gw4 192.168.3.1
set remote-gw 192.168.3.1
set psksecret secret
next
end

 

Virtual Switch erstellen und Teilnehmer hinzufügen

Site A

config system switch-interface
edit "VxLAN"
set vdom root
set member "internal4" "VPN_to_B"
set intra-switch-policy explicit
next
end

Site B

config system switch-interface
edit "VxLAN"
set vdom root"
set member "internal4" "VPN_to_A"
set intra-switch-policy explicit
next
end

 

VPN-Tunnel einrichten – Phase 2

Site A

config vpn ipsec phase2-interface
edit "VPN_to_B"
set phase1name "VPN_to_B"
set proposal aes128-sha256
next
end

Site B

config vpn ipsec phase2-interface
edit "VPN_to_A"
set phase1name "VPN_to_A"
set proposal aes128-sha256
next
end

 

Firewall Policies

Site A

config firewall address
edit "10.240.50.0"
set subnet 10.240.50.0 255.255.255.0
next
end

config firewall policy
edit 1
set srcintf "internal4"
set dstintf "VPN_to_B"
set srcaddr "10.240.50.0"
set dstaddr "10.240.50.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set srcintf "VPN_to_B"
set dstintf "internal4"
set srcaddr "10.240.50.0"
set dstaddr "10.240.50.0"
set action accept
set schedule "always"
set service "ALL"
next
end

Site B

config firewall address
edit "10.240.50.0"
set subnet 10.240.50.0 255.255.255.0
next
end

config firewall policy
edit 1
set srcintf "internal4"
set dstintf "VPN_to_A"
set srcaddr "10.240.50.0"
set dstaddr "10.240.50.0"
set action accept
set schedule "always"
set service "ALL"
set comments "Verkehr Richtung Site A"
next
edit 2
set srcintf "VPN_to_A"
set dstintf "internal4"
set srcaddr "10.240.50.0"
set dstaddr "10.240.50.0"
set action accept
set schedule "always"
set service "ALL"
set comments "Verkehr aus Site A"
next
end

 

Proof of Concept

Ich hab, wie auf dem Netzwerkdiagramm beschrieben, meine beiden Hosts am Port4 (Port kann von Gerät und Platform varieren) angeschlossen. Da in diesem Netz kein DHCP-Dienst verwendet wird, gab ich die Geräte eine feste IP-Adresse.

Host Site-A: 10.240.50.200 / 255.255.255.0

Host Site-B: 10.240.50.100 / 255.255.255.0

Wie man hier sehen kann, gab es einen Request und einen Reply. Zusätzlich sind die ARP-Abfragen in beiden Richtungen gut zu sehen.

Auf einer der Firewall ist unter den Policies Verkehr zu sehen.

Also hat es geklappt.

Bemerkungen

• Ich fand heraus, dass es zwischen den verschiedenen FortiOS Firmwares Diskrepanzen zwischen die Art und Weise wie man diese Technologie auf die Geräte konfiguriert.
• Wenn ein Befehl nicht wunschgemäss funktioniert, dann mit „?“ die Möglichkeiten auflisten lassen und nach Wunsch entscheiden.
• Ich denke auch, dass es wichtig ist, auf die Fragmentierung der Pakete durch die Interfaces aufmerksam zu machen. Die VxLAN-Verkapselung beträgt rund 50 Bytes und je mehr unsere Geräte fragmentierte Pakete wieder zusammenbauen müssen, desto mehr Ressourcen werden verbraucht. Dies kann zu unerwünschte Nebeneffekte im Netzwerk führen. Um eine Fragmentierung zu vermeiden, können wir das MTU-Size anpassen.
• Ein Software-Switch wird für diese Anleitung eingerichtet. Verkehr, welcher durch diesen SW-Switch fliesst, wird nicht von Netzwerkprozessoren sondern durch die Firewall CPU verarbeitet. Daher solltet ihr mit einer Erhöhung der CPU-Last rechnen.

 

Fazit

VxLAN ist so mächtig und so einfach zu konfigurieren. Abgesehen von den Diskrepanzen zwischen Versionen und Befehle, hatte ich keine Mühe diesen Setup aufzubauen und zu testen.

Was nicht gerade Ideal ist, ist die Verarbeitung des Verkehrs durch die CPU, dies wird, je nach Verkehr, für eine hohe Last sorgen. Hierbei sollte man beim Sizing ein Auge drauf werfen und eventuell eine stärkere Kiste kaufen.