Tag Archives: Site-to-Site VPN

FortiGate VPN Speedtests

Bandwidth/Delay, Fortinet, IPsec/VPN, , , , , ,

Triggered by a customer who had problems getting enough speed through an IPsec site-to-site VPN tunnel between FortiGate firewalls I decided to test different encryption/hashing algorithms to verify the network throughput. I used two FortiWiFi 90D firewalls that have an official IPsec VPN throughput of 1 Gbps. Using iperf I measured the transfer rates with no VPN tunnel as well as with different IPsec proposals.

I first ran into really slow performances which were related to the default “Software Switch” on the FortiGate. After deleting this type of logical switch, the VPN throughput was almost as expected.

Continue reading FortiGate VPN Speedtests →

Where to terminate Site-to-Site VPN Tunnels?

Design/Policy, IPsec/VPN, , , , , , ,

When using a multilayer firewall design it is not directly clear on which of these firewalls remote site-to-site VPNs should terminate. What must be considered in such scenarios? Differentiate between partners and own remote offices? Or between static and dynamic peer IPs? What about the default routes on the remote sites?

Following is a discussion about different approaches and some best practices. Since not all concepts work with all firewall vendors, the following strategies are separated by common firewalls, i.e., Cisco ASA, Fortinet FortiGate, Juniper ScreenOS, Palo Alto.

Continue reading Where to terminate Site-to-Site VPN Tunnels? →

IPv6 VPN Routing with Dynamic Prefixes

IPv6, Juniper Networks, Routing, , , , , , ,

How to route traffic inside an IPv6 site-to-site VPN tunnel if one side offers only dynamic IPv6 prefixes? With IPv4, the private network segments were statically routed through the tunnel. But with a dynamic prefix, a static route is not possible. That is, a dynamic routing protocol must be used. Here is an example of how I used OSPFv3 for IPv6 between my VPN endpoints.

In detail, I have a home office with a dual stack ISP connection. However, this connection has a dynamic IPv6 prefix: After every reboot or lost connection of the firewall, I get a new IPv6 prefix. This is really bad for building a site-to-site VPN to the headquarter. Since I don’t want to use any kind of NAT/NPTv6 with unique local addresses, I am talking OSPFv3 over the VPN tunnel in order to route the dynamic prefix range (global unicast) via the tunnel.

Continue reading IPv6 VPN Routing with Dynamic Prefixes →

IPv6 Site-to-Site VPN Recommendations

Design/Policy, IPv6, Routing, Security, , , , , , , ,

With global IPv6 routing, every single host has its own global unicast IPv6 address (GUA). No NAT anymore. No dirty tricks between hosts and routers. Great. Security is made merely by firewalls and policies. Site-to-site VPNs between partners can be build without address conflicts. Great again!

However, one problem to consider is the proper IPv6 routing via site-to-site VPNs since both sides now can reach each other even without a VPN. This was (mostly) not true with IPv4 in which both partners heavily relied on private RFC 1918 addresses that were not routable in the Internet. If specific IPv6 traffic should flow through a VPN but does actually traverse the Internet, it would be easy for a hacker to eavesdrop this traffic, leading to a security issue!

The following principles should be realized properly to assure that IPv6 traffic is never routed through the mere Internet when a site-to-site VPN tunnel is in place. Even in a failure of that tunnel. The principles can be applied to any IPv6 tunnels between partners, remote sites, home offices, etc., as long as the other site has its own global unicast IPv6 address space. (For VPNs in which a sub-prefix from the headquarters prefix is routed to a remote site, the situation behaves different. This article focuses on the routing between different IPv6 adress spaces.)

Continue reading IPv6 Site-to-Site VPN Recommendations →

IPsec Site-to-Site VPN FortiGate <-> FRITZ!Box

Fortinet, FRITZ!Box, IPsec/VPN, , , , ,

Hier kommt ein kurzer Guide wie man ein Site-to-Site VPN zwischen einer FortiGate Firewall und einer AVM FRITZ!Box aufbaut. Anhand von Screenshots zeige ich die Einrichtung der FortiGate, während ich für die FRITZ!Box ein Template der *.cfg Konfigurationsdatei bereitstelle.

Continue reading IPsec Site-to-Site VPN FortiGate <-> FRITZ!Box →

IPv6 through IPv4 VPN Tunnel with Juniper SSGs

IPsec/VPN, IPv6, Juniper Networks, Routing, , , , , ,

The most common transition method for IPv6 (that is: how to enable IPv6 on a network that does not have a native IPv6 connection to the Internet) is a “6in4” tunnel. Even other tunneling methods such as Teredo or SixXS are found on different literatures. However, another method that is not often explained is to tunnel the IPv6 packets through a VPN connection. For example, if the main office has a native IPv6 connection to the Internet, as well as VPN connections to its remote offices, it is easy to bring IPv6 subnets to these stations.

Here is how I did it with some Juniper SSG firewalls:

Continue reading IPv6 through IPv4 VPN Tunnel with Juniper SSGs →

FRITZ!OS ab 06.23: IPsec P2 Proposals erweitert

FRITZ!Box, IPsec/VPN, Template, , , , ,

Es geht in eine weitere Runde bei den VPNs von und zur FRITZ!Box. Nach den unglücklichen Änderungen in Version 06.20 hat AVM wieder ein paar Phase 2 Proposals hinzugenommen, die komplett ohne Kompression laufen. Somit ist es wieder möglich, die FRITZ!Box im Aggressive Mode VPN-Verbindungen zu diversen Firewalls aufbauen zu lassen. Komisch nur, dass noch nicht alles ganz wie erwartet funktioniert. Hier kommen meine Testergebnisse.

Continue reading FRITZ!OS ab 06.23: IPsec P2 Proposals erweitert →

Site-to-Site VPNs with Diffie-Hellman Groups 19 & 20 (Elliptic Curve)

Crypto, Fortinet, IPsec/VPN, Juniper Networks, , , , , , , , , , , ,

Similar to my test with Diffie-Hellman group 14 shown here I tested a VPN connection with elliptic curve Diffie-Hellman groups 19 and 20. The considerations why to use these DH groups are listed in the just mentioned post – mainly because of the higher security level they offer. I tested the site-to-site IPsec connections with a Juniper ScreenOS firewall and a Fortinet FortiGate firewall. (Currently, neither Palo Alto Networks nor Cisco ASA support these groups.)

Continue reading Site-to-Site VPNs with Diffie-Hellman Groups 19 & 20 (Elliptic Curve) →

IPsec Site-to-Site VPN FortiGate <-> Cisco Router

Cisco Systems, Fortinet, IPsec/VPN, , , ,

This blog post shows how to configure a site-to-site IPsec VPN between a FortiGate firewall and a Cisco router. The FortiGate is configured via the GUI – the router via the CLI. I am showing the screenshots/listings as well as a few troubleshooting commands.

Continue reading IPsec Site-to-Site VPN FortiGate <-> Cisco Router →

Considerations about IPsec Pre-Shared Keys

Authentication, Crypto, IPsec/VPN, , , , , , ,

Pre-shared keys (PSK) are the most common authentication method for site-to-site IPsec VPN tunnels. So what’s to say about the security of PSKs? What is its role for the network security? How complex should PSKs be? Should they be stored additionally? What happens if an attacker catches my PSKs?

I am listing my best practice steps for generating PSKs.

Continue reading Considerations about IPsec Pre-Shared Keys →

FRITZ!OS ab 06.20: Änderungen bei VPNs

FRITZ!Box, IPsec/VPN, , , , ,

In den Release Notes der neuesten AVM FRITZ!Box Version FRITZ!OS 06.20 stand unter anderem: “VPN-Verbindungen unterstützen jetzt zusätzliche Diffie-Hellman-Gruppen 5, 14 und 15”. Coole Sache, ist doch die Sicherheit bei der Perfect Forward Secrecy mit DH-14 deutlich höher und der heutigen Zeit angemessen. Also habe ich das bei einem meiner VPNs direkt mal eingerichtet und entsprechend getestet. Leider hat sich aber mit der neuen Version die Kompatibilität zu diversen Firewalls/VPN-Gateways deutlich verschlechtert. Es ist also nicht nur Gewinn, die Version 06.20 am laufen zu haben.

Continue reading FRITZ!OS ab 06.20: Änderungen bei VPNs →

IPsec Site-to-Site VPN Juniper ScreenOS <-> Cisco Router w/ VTI

Cisco Systems, IPsec/VPN, Juniper Networks, , , ,

And finally: A route-based VPN between a Juniper ScreenOS SSG firewall and a Cisco router with a virtual tunnel interface (VTI). Both sides with tunnel interfaces and IPv4 addresses. Both sides with a real routing entry in the routing table. Great. ;)

(The VPN between those two parties without a tunnel interface on the Cisco router is documented here. However, use the route-based VPN where you can. It is easier and more flexible. Routing decisions based on the routing table. This is how it should be.)

Continue reading IPsec Site-to-Site VPN Juniper ScreenOS <-> Cisco Router w/ VTI →

IPsec Site-to-Site VPN Palo Alto <-> Cisco Router w/ VTI

Cisco Systems, IPsec/VPN, Palo Alto Networks, , ,

One more VPN article. Even one more between a Palo Alto firewall and a Cisco router. But this time I am using a virtual tunnel interface (VTI) on the Cisco router which makes the whole VPN set a “route-based VPN”. That is: Both devices decide their traffic flow merely based on the routing table and not on access-list entries. In my opinion, this is the best way to build VPNs, because there is a single instance (the routing table) on which a network admin must rely on in order to investigate the traffic flow.

Note that I also wrote a blog post about the “policy-based VPN” between a Cisco router and the Palo Alto firewall. This here is mostly the same on the Palo Alto side while some other commands are issued on the Cisco router.

Continue reading IPsec Site-to-Site VPN Palo Alto <-> Cisco Router w/ VTI →