Tag Archives: IPsec

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. Other tunneling methods such as Teredo or SixXS are found on different literatures as well. However, another method that is not often explained is to tunnel the IPv6 packets through a normal 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 comes an example with two Palo Alto firewalls.

The native Android IPsec VPN client supports connections to the Cisco ASA firewall. This even works without the “AnyConnect for Mobile” license on the ASA. If only a basic remote access VPN connection is needed, this fits perfectly. It uses the classical IPsec protocol instead of the newer SSL version. However, the VPN tunnel works anyway.

In this short post I am showing the configuration steps on the ASA and on the Android phone in order to establish a remote access VPN tunnel.

For a basic remote access VPN connection to a Palo Alto Networks firewall (called “GlobalProtect”), the built-in VPN feature from Android can be used instead of the GlobalProtect app from Palo Alto itself. If the additional features such as HIP profiling are not needed, this variant fits perfectly.

I am showing a few screenshots and logs from the Android smartphone as well as from the Palo Alto to show the differences.

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.

Similar to my test with Diffie-Hellman group 14 shown here I tested a VPN connection with the 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 the Palo Alto nor the Cisco ASA support these groups.)

Following is a step-by-step tutorial for a site-to-site VPN between a Fortinet FortiGate and a Cisco ASA firewall. I am showing the screenshots of the GUIs in order to configure the VPN, as well as some CLI show commands.

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.

Here comes the step-by-step guide for building a site-to-site VPN between a FortiGate and a ScreenOS firewall. Not much to say. I am publishing several screenshots and CLI listings of both firewalls, along with an overview of my laboratory.

This is a small tutorial for configuring a site-to-site IPsec VPN between a Palo Alto and a FortiGate firewall. I am publishing step-by-step screenshots for both firewalls as well as a few troubleshooting CLI commands.

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?

In a basic environment with a Cisco ASA firewall I am logging everything to a syslog-ng server. As there aren’t any reporting tools installed, I am using grep to filter the huge amount of syslog messages in order to get the information I want to know. In this blog post I list a few greps for getting the interesting data.

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.)

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.