This post describes the steps to configure a Site-to-Site VPN between a Juniper ScreenOS firewall and the Cisco ASA firewall. With the correct IKE and IPsec parameters as well as the correct Proxy IDs on both sides, the VPN establishment works without any problems. And since the Juniper firewall can ping an IPv4 address on the remote side through the tunnel (VPN Monitor), the VPN tunnel is established by the firewalls themselves without the need for initial traffic.

Laboratory

The following figure shows my test laboratory:

The Juniper SSG 5 firewall had version 6.3.0r16.0 installed, while the Cisco ASA 5505 ran on version 9.1(4).

Note that I am not showing the creation of the IKE and IPsec parameter sets since their reference names are self-explanatory, such as “pre-g5-aes256-sha1″ and “g5-esp-aes256-sha1-3600″.

Concerning the automatic tunnel establishment: The Juniper VPN Monitor, which pings the inside interface of the ASA, only works if the “Management Access Interface” on the ASA is set to this specific inside network. Otherwise, the ASA will not reply to these ping requests and will generate log messages such as “Failed to locate egress interface for ICMP from outside: …”. Really bad! Especially if you have more than one inside network.

Juniper ScreenOS SSG

The creation of the VPN on the ScreenOS device requires the following steps: tunnel interface, gateway, AutoKey IKE with Proxy IDs, and static IPv4 route through the tunnel. The following screenshots document these steps:

Cisco ASA

On the Cisco ASA, a Group Policy and a Connection Profile must be created. On the following screenshots, I am also showing the created Crypto Map:

Monitoring the VPN Sessions

Due to the VPN Monitor on the Juniper firewall, the tunnel should be established right after all configuration settings are done. The Juniper monitor status will indicate an “Up” link and the logs filtered to the peer IPv4 address will show several success messages:

The same is true for the Cisco ASA, which will reveal the successful VPN tunnel with the chosen security parameters:

Mit diesem Beitrag möchte ich zeigen, wie man ein Site-to-Site VPN von der FRITZ!Box zu einer Cisco ASA Firewall aufbaut. Mein Laboraufbau entspricht dabei dem typischen Fall, bei dem die FRITZ!Box hinter einer dynamischen IP hängt (klassisch: DSL-Anschluss), während die ASA eine statische IP geNATet bekommt.

Beide Geräte habe ein policy-based VPN implementiert, so dass das hier endlich mal ein Fall ist, wo man nicht durch den Mix einer route-based VPN-Firewall und einer policy-based VPN-Firewall durcheinander kommt. Man muss bei beiden Geräten einfach das eigene sowie das remote Netzwerk eintragen, ohne weitere Routen zu ändern.

Hinweis: Eine etwas detaillierte Beschreibung bezüglich der VPN-Einstellungen der FRITZ!Box habe ich hier bei meinem Blogbeitrag beim VPN zur Juniper Firewall beschrieben. Für weitere Informationen also bitte diesen Link verwenden.

Aufbau und Infos

So sieht mein Aufbau konkret aus:

Auf der Cisco ASA 5505 lief Version 9.1(4), während auf meiner FRITZ!Box 7270 das FRITZ!OS 05.53 installiert war.

Leider habe ich es nicht geschafft auf der FRITZ!Box auch für die Phase 2 (IPsec) die Verschlüsselung mit AES-256 und DH-5 zu verwenden. Auch die Phase 1 (IKE) verwendet lediglich DH-2. Das ist insofern suboptimal, da bei DH-5 ein deutlich besserer Session-Key verwendet werden würde (höhere Sicherheitsstufe). Naja, immerhin kann man Perfect Forward Secrecy (PFS) mit DH-2 nutzen. Trotzdem: Falls jemand andere Einstellungen auf der FRITZ!Box hinbekommen hat: Bitte melden!

Cisco ASA

Der VPN-Tunnel bei der ASA wird mit einer Group Policy und einem Connection Profile realisiert. Siehe dazu die folgenden Screenshots inkl. der zusätzlichen Kommentare.

Als IKE Policy muss AES-256, DH-2, SHA-1, pre-share und eine Lifetime von 86400 Sekunden ausgewählt werden. Das IPsec Proposal braucht den Tunnel Mode mit 3DES und SHA-1. In der Crypto Map wird dann noch PFS mit DH-2 ausgewählt. Die Bennenung der Group Policy und des Connection Profiles spielt keine Rolle. Ich habe der Einfachheit halber den FQDN meiner FRITZ!Box gewählt. Das ist für die VPN Einstellungen an sich aber irrelevant.

FRITZ!Box

Folgend ist die Konfigurationsdatei welche ich für das VPN zur Cisco ASA gebaut habe. (Und wie bereits oben geschrieben: Ein paar mehr Details zur Konfigurationsdatei habe ich hier bei einem meiner anderen VPN Beiträge zur FRITZ!Box aufgelistet.)

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "fd-wv-fw03";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 80.154.108.229;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "fdorf.webernetz.net";
                }
                remoteid {
                        ipaddr = "80.154.108.229";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "alt/aes/sha";
                keytype = connkeytype_pre_shared;
                key = "ExdHIoxzmsBbkbW5vnkUVAlCNcNf2n";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.86.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.130.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-3des-sha/ah-no/comp-no/pfs";
                accesslist = "permit ip any 192.168.130.0 255.255.255.0";
        }  ike_forward_rules =	"udp 0.0.0.0:500 0.0.0.0:500", 
								"udp 0.0.0.0:4500 0.0.0.0:4500";
	}

Status der VPN Session

Der Tunnel wird nur dann aufgebaut, wenn initialer Traffic von dem Netz hinter der FRITZ!Box in Richtung Cisco ASA läuft. Ist dann der VPN-Tunnel aufgebaut, sehen die Session Details auf der ASA in etwa so aus:

Bei der FRITZ!Box sieht man in dem VPN Bereich dann folgenden grünen Bubble:

Mission completed!

The Palo Alto firewall supports policy entries that refer to multiple source and destination zones. This is useful especially when there are branch offices with multiple zones and a site-to-site VPN to the main office. In this scenario, every zone in the branch office might have a “permit any any” to the main office and vice versa, while the zones on the branch office should not have a permit among themselves. (Of course, the traffic on the main office is restricted and not permitted generally.) Here are two ways to accomplish that scenario.

My example consists the following: The branch office has three security-zones called trust-user, trust-server, and trust-ra. The zone for the site-to-site VPN is called vpn-s2s. I will show the two options on the basis of two screenshots.

Note that this configuration is set on the branch office firewall only. On the main office firewall, the traffic is of course classified and permitted/denied according to the specific rule set.

One Bidirectional Rule for each Zone

The first possibility is a set of bidirectional rules, in which each role has the same source and destination. That is: Independent of the originating side, the rule will match. A single bidirectional rule is needed for every internal zone on the branch firewall.

Note that these rules also permit traffic from an internal zone to the interface of the Palo Alto firewall itself, e.g., for ping oder DNS Proxy. In order to limit the management access of the Palo Alto interfaces, “Interface Mgmt” profiles can be used.

Two Unidirectional Rules

The second option has two unidirectional rules: Branch -> Main and Main -> Branch. (Unidirectional refers to the initiating side. Of course, all rules are stateful and allow the returning traffic as well.) The vpn-s2s zone is on the one side while the internal zones of the branch office are on the other side:

This option is suitable for branch offices with many internal zones since the whole “permit any any” set is built with these two rules regardless of the number of internal zones.

When talking about VPNs it is almost always clear that they are encrypted. However, it is not so clear on which security level a VPN is established. Since the Perfect Forward Secrecy (PFS) values of “DH group 5″ etc. do not clearly specify the “bits of security”, it is a misleadingly assumption that the security is 256 bits due to the symmetric AES-256 cipher. It is not! Diffie-Hellman group 5 has only about 89 bits of security…

Therefore, common firewalls implement DH group 14 which has a least a security level of approximately 103 bits. I tested such a site-to-site VPN tunnel between a Palo Alto and a Juniper ScreenOS firewall which worked without any problems.

Bits of Security

The traffic over a VPN is encrypted with a symmetric cipher such as AES, but the encryption key is generated with an asymmetric cipher such as Diffie-Hellman. An attacker who captures the complete traffic of a VPN might be able to brute-force the used keys of this Diffie-Hellman key exchange OR he could do a brute-force attack of the encrypted traffic with AES. Of course he would do that attack on the weaker cipher, i.e., on DH and not on AES.

On this Crypto++ wiki, a table that lists the bits of security for different symmetric and asymmetric functions can be found, taken from this PDF file from NIST on p. 64. Another resource is the ECRYPT2 Yearly Report on Algorithms and Keysizes (2010) which has the following (lower) values on p. 30:

• DH with 1024 bits (group 2) has 73 bits of security
• DH with 1536 bits (group 5) has 89 bits of security
• DH with 2048 bits (group 14) has 103 bits of security

That is: If a really secure VPN connection is needed, the phase 1 and phase 2 parameters should use at least Diffie-Hellman group 14 to gain 103 bits of security. Furthermore, at least AES-128 can be used, which has a security of almost 128 bits. However, since AES-256 can be used without any troubles, I don’t know why AES-128 should be used instead (except high CPU load issues).

Test VPN Palo <-> Juniper

While I expect that such VPN settings between firewalls of the same vendor work without any problems, I configured DH group 14 with AES-256 and SHA-256 (also new, instead of SHA-1) for both IKE and IPsec (ESP) on my test VPN between a Palo Alto PA-200 (6.0.1) and a Juniper SSG 5 (6.3.0r16a.0) firewall. It worked.

Here is an appropriate listing from the Palo Alto firewall that shows these correct values for the VPN (DH14/…):

weberjoh@fd-wv-fw02> show vpn ike-sa gateway fd-wv-fw01

phase-1 SAs
GwID/client IP  Peer-Address           Gateway Name           Role Mode Algorithm          Established     Expiration      V  ST Xt Phase2
--------------- ------------           ------------           ---- ---- ---------          -----------     ----------      -  -- -- ------
              1 172.16.1.1             fd-wv-fw01             Init Main PSK/DH14/A256/SHA256 Mar.27 12:38:57 Mar.27 20:38:57 v1 12  4      1

Show IKEv1 IKE SA: Total 1 gateways found. 1 ike sa found.

phase-2 SAs
GwID/client IP  Peer-Address           Gateway Name           Role Algorithm               SPI(in)  SPI(out) MsgID    ST Xt
--------------- ------------           ------------           ---- ---------               -------  -------- -----    -- --
              1 172.16.1.1             fd-wv-fw01             Init DH14/tunl/ESP/A256/SHA256 A2C9F430 38921FFB D8170C56  9  1

Show IKEv1 phase2 SA: Total 1 gateways found. 1 ike sa found.

And similarly, two Juniper listings (grp14/…):

fd-wv-fw01-> get ike cookies

80102f/0003, 172.16.1.2:500->172.16.1.1:500, PRESHR/grp14/AES256/SHA2-256, xchg(5) (fd-wv-fw02/grp-1/usr-1)
resent-tmr 322 lifetime 28800 lt-recv 28800 nxt_rekey 21359 cert-expire 0
responder, err cnt 0, send dir 1, cond 0x0
nat-traversal map not available
ike heartbeat              : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
DPD seq local 0, peer 2491

fd-wv-fw01-> get sa id 00000002
index 0, name fd-wv-fw02, peer gateway ip 172.16.1.2. vsys
auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1> vpngrp:<-1>. sa_list_nxt:<-1>.
tunnel id 2, peer id 0, NSRP Local.     site-to-site. Local interface is ethernet0/6 <172.16.1.1>.
  esp, group 14, a256 encryption, s256 authentication
  autokey, IN active, OUT active
  monitor<1>, latency: 2, availability: 100
  DF bit: clear
  app_sa_flags: 0x24001a7
  proxy id: local 0.0.0.0/0.0.0.0, remote 0.0.0.0/0.0.0.0, proto 0, port 0/0
  ike activity timestamp: 1987333985
  DSCP-mark : disabled
nat-traversal map not available
incoming: SPI 38922007, flag 00004000, tunnel info 40000002, pipeline
  life 3600 sec, 3397 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x47, window 0xffffffff, idle timeout value <0>, idled 1 seconds
  next pak sequence number: 0x0
  bytes/paks:51371280/706390; sw bytes/paks:51371280/706390
outgoing: SPI fd1321fd, flag 00000000, tunnel info 40000002, pipeline
  life 3600 sec, 3397 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 1 seconds
  next pak sequence number: 0x47
  bytes/paks:51371600/706400; sw bytes/paks:51371600/706400

I also tried to configure group 14 values on my VPNs to a Cisco ASA 5505 (9.1(4)) firewall, but an error message said that DH14 is only supported on IKEv2. Hm. Maybe the two other vendors implemented it on their own, or Cisco did not want to implement it for IKEv1. I don’t know.

Further Reading

• At a Glance: Perfect Forward Secrecy
• RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
• RFC 5114: Additional Diffie-Hellman Groups for Use with IETF Standards

This time I configured a static S2S VPN between a Palo Alto firewall and a Cisco IOS router. Here comes the tutorial:

I am not using a virtual interface (VTI) on the Cisco router in this scenario, but the classical policy-based VPN solution. That is, no route entry is needed on the Cisco machine. However, the Palo Alto implements all VPNs with tunnel interfaces. Hence, a route to the tunnel and Proxy IDs must be configured. (I also wrote a guide for a route-based VPN between a Cisco router and a Palo Alto firewall here.)

In my test lab I am running a PA-200 with PAN-OS 6.0.3. The Cisco router is an old Cisco 2621 with IOS 12.3(26) and image “c2600-ik9o3s3-mz.123-26.bin”.

Laboratory

The following figure depicts my test laboratory:

Palo Alto

The configuration steps for the Palo Alto Networks firewall are the following:

1. IKE and IPSec Crypto profiles, e.g., aes256, sha1, pfs group 5, lifetime 8h/1h.
2. IKE Gateway with the pre-shared key and the corresponding IKE Crypto Profile. The “Identification” fields are not needed.
3. Tunnel Interface within a virtual router (e.g., “default”) and a security zone (e.g., “vpn-s2s”). The interface does not need an IP address.
4. IPSec Tunnel: Tying all together: tunnel interface, IKE gateway, IPSec crypto profile. Furthermore, the Proxy IDs (= protected networks) are set here.
5. Static route to the destination network through the tunnel interface (without next hop address).
6. Policy from untrust to untrust with the applications “ike”, “ipsec”, and “ciscovpn” allowed.
7. Policies from trust zones to the zone in which the tunnel interface resides.

Here are my configuration screenshots:

Cisco Router

The Cisco router, configured through the CLI, needs the following lines:

1. crypto isakmp appropriate to the “IKE Crypto” on the PA
2. crypto isakmp key with the pre-shared key
3. crypto ipsec appriopriate to the “IPSec Crypto” on the PA
4. access-list which defines the protected networks, corresponding to the “Proxy IDs”
5. crypto map with the transform-set, peer, pfs group, and access-list
6. crypto map applied to the outside interface
7. (Note: No route entry is needed since this VPN is a policy-based VPN which makes its routing decision based on the access-list.)

Here is the bunch of my configuration commands:

!
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5
 lifetime 28800
!
crypto isakmp key 3WU99OhGqpPRIhjNm2eBeBG6hQbLQ5 address 172.16.1.2
!
crypto ipsec transform-set aes256-sha esp-aes 256 esp-sha-hmac
!
crypto map map01 1 ipsec-isakmp
 set peer 172.16.1.2
 set transform-set aes256-sha
 set pfs group5
 match address acl-vpn-PA
!
interface FastEthernet0/0
 crypto map map01
!
ip access-list extended acl-vpn-PA
 permit ip 192.168.141.0 0.0.0.255 192.168.121.0 0.0.0.255
!

Monitoring

After a successful establishment of the tunnel, the PA shows green bubbles in its IPSec Tunnels overview. The Session Browser reveals active sessions for ike or ciscovpn and ipsec-esp. However, I noticed that after these sessions are gone, only the ike sessions are in my traffic log, while the ipsec sessions are not correct according to the listed traffic bytes. Hm. Has anyone else recognized a similar behaviour?

The Cisco router can be queried with the subsequent commands:

• show crypto isakmp sa detail
• show crypto ipsec sa
• show crypto map

fd-wv-ro02#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption

C-id  Local           Remote          I-VRF    Encr Hash Auth DH Lifetime Cap.
509   172.16.1.4      172.16.1.2               aes  sha  psk  5  01:48:09

-------------------------------------------------------------------------------

fd-wv-ro02#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: map01, local addr. 172.16.1.4

   protected vrf:
   local  ident (addr/mask/prot/port): (192.168.141.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.121.0/255.255.255.0/0/0)
   current_peer: 172.16.1.2:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 42122, #pkts encrypt: 42122, #pkts digest 42122
    #pkts decaps: 47189, #pkts decrypt: 47189, #pkts verify 47189
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 2, #recv errors 0

     local crypto endpt.: 172.16.1.4, remote crypto endpt.: 172.16.1.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: C0F1609E

     inbound esp sas:
      spi: 0x81DF870F(2178909967)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2080, flow_id: 81, crypto map: map01
        sa timing: remaining key lifetime (k/sec): (4516253/1975)
        IV size: 16 bytes
        replay detection support: Y

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xC0F1609E(3237044382)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2081, flow_id: 82, crypto map: map01
        sa timing: remaining key lifetime (k/sec): (4516252/1973)
        IV size: 16 bytes
        replay detection support: Y

     outbound ah sas:

     outbound pcp sas:

-------------------------------------------------------------------------------

fd-wv-ro02#show crypto map
Crypto Map "map01" 1 ipsec-isakmp
        Peer = 172.16.1.2
        Extended IP access list acl-vpn-PA
            access-list acl-vpn-PA permit ip 192.168.141.0 0.0.0.255 192.168.121.0 0.0.0.255
        Current peer: 172.16.1.2
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): Y
        DH group:  group5
        Transform sets={
                aes256-sha,
        }

        Interfaces using crypto map map01:
                FastEthernet0/0

And one more time: Since the Cisco Router decides its forwarding decisions for VPNs on the policy (ACL) and NOT on route entries, the routing table does NOT show any of my site-to-site remote networks, but only the connected and static configured routes:

fd-wv-ro02#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.16.1.1 to network 0.0.0.0

S    192.168.120.0/24 [1/0] via 172.16.1.2
S    192.168.125.0/24 [1/0] via 172.16.1.2
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
C    192.168.140.0/24 is directly connected, FastEthernet0/1.140
C    192.168.141.0/24 is directly connected, FastEthernet0/1.141
S*   0.0.0.0/0 [1/0] via 172.16.1.1

Links

Similar information about this tunnel can be found here:

• Creating a Site to Site IPSec VPN with a Palo Alto Networks Application Firewall and a Cisco Router
• [Video] Cisco to Palo Alto IPsec Tunnel: The perfect couple?

Similar to all my other site-to-site VPN articles, here are the configurations for a VPN tunnel between a Juniper ScreenOS SSG firewall and a Cisco IOS router. Due to the VPN Monitor of the SSG firewall, the tunnel is established directly after the configuration and stays active all the time without the need of “real” traffic.

I am using the policy-based VPN solution on the Cisco router and not the virtual tunnel interface (VTI) approach. That is: No route is needed on the router while the Proxy IDs must be set on the Juniper firewall. (However, I also documented the route-based VPN solution between a ScreenOS firewall and a Cisco router here.)

Laboratory

This figure shows my lab:

My Juniper SSG 5 firewall ran at version 6.3.0r17.0. The (old) Cisco router 2621 had IOS 12.3(26) installed (c2600-ik9o3s3-mz.123-26.bin).

Juniper ScreenOS SSG

The configuration steps on the SSG are the following:

1. P1 and P2 Proposals, e.g., PFS group 5, AES256, SHA1, 28800/3600 sec.
2. Gateway with Preshared Key and P1 Proposal.
3. Unnumbered Tunnel Interface.
4. AutoKey IKE profile which points to the just created gateway, P2 proposal and tunnel interface. The checkmark “Proxy-ID Check” is mandatory here. Furthermore, the VPN Monitor can be set to automatically build the tunnel.
5. Proxy ID(s) corresponding to the tunneled networks.
6. Specific route through the tunnel interface.

Here are my configuration screenshots:

Cisco Router

The listing below shows all relevant commands for the VPN tunnel. Of course, the isakmp policy and the ipsec transform-set is identical to the ones I configured on the Juniper firewall. Note that I also configured the “hash sha” command inside the “crypto isakmp policy 10″ submenu. However, this is not shown since it seems to be the default value. Same on the “set security-association lifetime seconds 3600″ command inside the “crypto map map01 2 ipsec-isakmp” submenu.

!
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5
 lifetime 28800
!
crypto isakmp key 5aSZlgNGDwHfhcYmnTWxmLM53YXjE6 address 172.16.1.1
!
crypto ipsec transform-set aes256-sha esp-aes 256 esp-sha-hmac
!
crypto map map01 2 ipsec-isakmp
 set peer 172.16.1.1
 set transform-set aes256-sha
 set pfs group5
 match address acl-vpn-SSG
!
interface FastEthernet0/0
 crypto map map01
!
ip access-list extended acl-vpn-SSG
 permit ip 192.168.141.0 0.0.0.255 192.168.111.0 0.0.0.255
!

It’s running

As the Monitor Status of the Juniper reveals:

The Cisco router can be queried with the following commands:

fd-wv-ro02#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption

C-id  Local           Remote          I-VRF    Encr Hash Auth DH Lifetime Cap.
512   172.16.1.4      172.16.1.1               aes  sha  psk  5  03:05:51

-------------------------------------------------------------------------------

fd-wv-ro02#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: map01, local addr. 172.16.1.4

   protected vrf:
   local  ident (addr/mask/prot/port): (192.168.141.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.111.0/255.255.255.0/0/0)
   current_peer: 172.16.1.1:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4937, #pkts encrypt: 4937, #pkts digest 4937
    #pkts decaps: 4937, #pkts decrypt: 4937, #pkts verify 4937
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 172.16.1.4, remote crypto endpt.: 172.16.1.1
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 38F5083A

     inbound esp sas:
      spi: 0xA0608BB1(2690681777)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2088, flow_id: 89, crypto map: map01
        sa timing: remaining key lifetime (k/sec): (4418894/3383)
        IV size: 16 bytes
        replay detection support: Y

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x38F5083A(955582522)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2089, flow_id: 90, crypto map: map01
        sa timing: remaining key lifetime (k/sec): (4418894/3383)
        IV size: 16 bytes
        replay detection support: Y

     outbound ah sas:

     outbound pcp sas:

-------------------------------------------------------------------------------

fd-wv-ro02#show crypto map
Crypto Map "map01" 2 ipsec-isakmp
        Peer = 172.16.1.1
        Extended IP access list acl-vpn-SSG
            access-list acl-vpn-SSG permit ip 192.168.141.0 0.0.0.255 192.168.111.0 0.0.0.255
        Current peer: 172.16.1.1
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): Y
        DH group:  group5
        Transform sets={
                aes256-sha,
        }

        Interfaces using crypto map map01:
                FastEthernet0/0

Der Titel sagt eigentlich schon alles: Es geht um das Herstellen eines S2S-Tunnels zwischen einem Cisco Router (statische IPv4) und einer FRITZ!Box (dynamische IP). Ich liste nachfolgend alle Befehle für den IOS Router sowie die Konfigurationsdatei für die FRITZ!Box auf. Für eine etwas detaillierte Beschreibung des VPNs für die FRITZ!Box verweise ich auf diesen Artikel von mir, bei dem ich zwar ein VPN zu einem anderen Produkt hergestellt habe, aber etwas mehr auf die Schritte der Konfiguration eingegangen bin.

Labor

Getestet habe ich die Schose mit einer FRITZ!Box 7270 (FRITZ!OS 05.54) und einem Cisco Router 2621 (12.3(26)). Der Laboraufbau sah dabei folgendermaßen aus:

Cisco Router

Der Cisco Router wird mit nachfolgenden Befehlen konfiguriert. Man achte auf die “crypto dynamic-map dynmap01 …” auf welche in der “crypto map map01 …” referenziert wird. Dem outside Interface wird letztendlich die “crypto map map01″ zugewiesen.

Außerdem scheint es mehrere funktionierende Lösungen für dieses VPN zur FRITZ!Box zu geben. Im Internet findet man Konfigurationen, die zum Beispiel beim “crypto isakmp key …” mit “address 0.0.0.0 0.0.0.0″ anstatt des von mir vorgeschlagenen “hostname xyz” arbeiten. Auch verwende ich kein “isakmp profile”. Sprich: Meine Methode hier funktioniert, aber es gibt auch andere.

!
crypto isakmp policy 20
 encr aes 256
 authentication pre-share
 group 2
 lifetime 28800
!
crypto isakmp key Pz5rvYqyU9IzleJSAqnwTTV4yHV95b hostname fdorf.webernetz.net
!
crypto ipsec transform-set 3des-sha esp-3des esp-sha-hmac
!
crypto dynamic-map dynmap01 1
 set transform-set 3des-sha
 set pfs group2
 match address acl-vpn-fdorf
!
crypto map map01 3 ipsec-isakmp dynamic dynmap01
!
interface FastEthernet0/0
 crypto map map01
!
ip access-list extended acl-vpn-fdorf
 permit ip 192.168.141.0 0.0.0.255 192.168.86.0 0.0.0.255
!

FRITZ!Box

Die anzupassenden FRITZ!Box VPN-Einstellungen sehen so aus:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "fd-wv-ro02";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 80.154.108.235;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "fdorf.webernetz.net";
                }
                remoteid {
                        ipaddr = "80.154.108.235";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "alt/aes/sha";
                keytype = connkeytype_pre_shared;
                key = "Pz5rvYqyU9IzleJSAqnwTTV4yHV95b";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.86.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.141.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-3des-sha/ah-no/comp-no/pfs";
                accesslist = "permit ip any 192.168.141.0 255.255.255.0";
        }  ike_forward_rules =	"udp 0.0.0.0:500 0.0.0.0:500", 
								"udp 0.0.0.0:4500 0.0.0.0:4500";
	}

Läuft

Wie man in der FRITZ!Box schön am grünen Bubble erkennen kann:

Beim Cisco Router gibt es die folgenden Befehle, um die Status der einzelnen Security Associations herauszufinden:

fd-wv-ro02#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption

C-id  Local           Remote          I-VRF    Encr Hash Auth DH Lifetime Cap.
518   172.16.1.4      77.1.23.14               aes  sha  psk  2  00:50:51

-------------------------------------------------------------------------------

fd-wv-ro02#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: map01, local addr. 172.16.1.4

   protected vrf:
   local  ident (addr/mask/prot/port): (192.168.141.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.86.0/255.255.255.0/0/0)
   current_peer: 77.1.23.14:500
     PERMIT, flags={}
    #pkts encaps: 4011, #pkts encrypt: 4011, #pkts digest 4011
    #pkts decaps: 4021, #pkts decrypt: 4021, #pkts verify 4021
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: 172.16.1.4, remote crypto endpt.: 77.1.23.14
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: C6D78600

     inbound esp sas:
      spi: 0xBAB770F6(3132584182)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2090, flow_id: 91, crypto map: map01
        sa timing: remaining key lifetime (k/sec): (4602733/3026)
        IV size: 8 bytes
        replay detection support: Y

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xC6D78600(3336013312)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2091, flow_id: 92, crypto map: map01
        sa timing: remaining key lifetime (k/sec): (4602733/3026)
        IV size: 8 bytes
        replay detection support: Y

     outbound ah sas:

     outbound pcp sas:

-------------------------------------------------------------------------------

fd-wv-ro02#show crypto map
Crypto Map "map01" 3 ipsec-isakmp
        Dynamic map template tag: dynmap01

Crypto Map "map01" 65536 ipsec-isakmp
        Peer = 77.1.23.14
        Extended IP access list
            access-list  permit ip 192.168.141.0 0.0.0.255 192.168.86.0 0.0.0.255
            dynamic (created from dynamic map dynmap01/1)
        Current peer: 77.1.23.14
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): Y
        DH group:  group2
        Transform sets={
                3des-sha,
        }
        Interfaces using crypto map map01:
                FastEthernet0/0

Viel Erfolg!

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.

My lab units are a Palo Alto PA-200 with PAN-OS 6.0.3 and a Cisco router 2811 with IOS 12.4(24)T8 (c2800nm-advipservicesk9-mz.124-24.T8.bin).

Laboratory

Palo Alto

These are the configuration steps on the Palo Alto firewall:

1. IKE and IPSec Crypto profiles, e.g., aes256, sha1, pfs group 14 (!), lifetime 8h/1h.
2. IKE Gateway with the pre-shared key and the corresponding IKE Crypto Profile. The “Identification” fields are not needed.
3. Tunnel Interface with an IPv4 address within a virtual router (e.g., “default”) and a security zone (e.g., “vpn-s2s”).
4. IPSec Tunnel: Tying all together: tunnel interface, IKE gateway, IPSec crypto profile. The Tunnel Monitor can be used to ping the other side of the tunnel. And since this is a route-based VPN, the Proxy IDs are not needed here!
5. Static route to the destination network through the tunnel interface with a next-hop address of the tunnel interface IP address of the other side.
6. Policy from untrust to untrust with the applications “ike”, “ipsec”, and “ciscovpn” allowed.
7. Policies from trust zones to the zone in which the tunnel interface resides, and vice versa.

Here are my test lab screenshots:

Cisco Router

The Cisco router, configured through the CLI, needs the following lines:

1. crypto isakmp policy appropriate to the “IKE Crypto” on the PA
2. crypto isakmp key with the pre-shared key
3. crypto ipsec transform-set appropriate to the “IPSec Crypto” on the PA
4. crypto ipsec profile that points to the transform-set and has pfs group14 set
5. interface Tunnel with an IPv4 address, tunnel source and destination addresses (outside addresses of the router and the Palo Alto), tunnel mode of ipsec and a reference to the crypto profile
6. Finally, a static ip route through the tunnel interface to the tunnel IPv4 address of the Palo Alto side
7. (Note, there is no “crypto map” used here, the real outside interface is not touched, and no access-list is configured!)

Here is the bunch of my configuration commands:

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 14
 lifetime 28800
!
crypto isakmp key 5Tc56Q5A4HcLB72AUQqhzAFcXY0Lm8 address 172.16.1.2
!
crypto ipsec transform-set aes256-sha esp-aes 256 esp-sha-hmac
!
crypto ipsec profile PA
 set transform-set aes256-sha
 set pfs group14
!
interface Tunnel121
 ip address 10.0.0.6 255.255.255.252
 tunnel source 172.16.1.5
 tunnel destination 172.16.1.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PA
!
ip route 192.168.121.0 255.255.255.0 Tunnel121 10.0.0.5

Don’t forget the Route

During the first test in my lab, the VPN was up but the traffic flew through the network even without the route through the tunnel! This was because the normal routing could reach the network from the Cisco router to the Palo Alto directly. So, one more time: Check the routing through the correct VPN tunnel! (This becomes even more serious when IPv6 with global unicast addresses will be used, in which situation every address could reach every other address on the Internet even without VPNs.)

The following screenshot shows two traceroute commands on a Linux test machine. During the first command, the route entry on the Cisco router was not added (though the VPN tunnel was already established), while the second traceroute went over the correct VPN tunnel:

Monitoring

Green bubbles in the Palo Alto tunnel pane and system log entries corresponding to the IKE gateway and IPsec tunnel objects. (Note the hourly refresh of the key due to the IPsec lifetime of 3600 sec):

Show commands on the Cisco router:

fd-wv-ro03#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

1135  172.16.1.5      172.16.1.2               ACTIVE aes  sha  psk  14 05:25:04
       Engine-id:Conn-id =  SW:135

IPv6 Crypto ISAKMP SA

---------------------------------------

fd-wv-ro03#show crypto ipsec sa

interface: Tunnel121
    Crypto map tag: Tunnel121-head-0, local addr 172.16.1.5

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.16.1.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 679743, #pkts encrypt: 679743, #pkts digest: 679743
    #pkts decaps: 680929, #pkts decrypt: 680929, #pkts verify: 680929
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 66, #recv errors 0

     local crypto endpt.: 172.16.1.5, remote crypto endpt.: 172.16.1.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xFF5F2879(4284426361)
     PFS (Y/N): Y, DH group: group14

     inbound esp sas:
      spi: 0xFA8A1BF5(4203355125)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 4161, flow_id: NETGX:2161, sibling_flags 80000046, crypto map: Tunnel121-head-0
        sa timing: remaining key lifetime (k/sec): (4436876/1194)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xFF5F2879(4284426361)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 4162, flow_id: NETGX:2162, sibling_flags 80000046, crypto map: Tunnel121-head-0
        sa timing: remaining key lifetime (k/sec): (4436876/1194)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

---------------------------------------

fd-wv-ro03#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.16.1.1 to network 0.0.0.0

S    192.168.121.0/24 [1/0] via 10.0.0.5, Tunnel121
C    192.168.151.0/24 is directly connected, FastEthernet0/1.151
S    192.168.120.0/24 [1/0] via 172.16.1.2
C    192.168.150.0/24 is directly connected, FastEthernet0/1.150
S    192.168.111.0/24 [1/0] via 10.0.0.9, Tunnel111
S    192.168.125.0/24 [1/0] via 172.16.1.2
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
C       10.0.0.8 is directly connected, Tunnel111
C       10.0.0.4 is directly connected, Tunnel121
S*   0.0.0.0/0 [1/0] via 172.16.1.1

Done

Links

• Cisco: Configuring a Virtual Tunnel Interface with IP Security
• Cisco: IPSec Virtual Tunnel Interface
• Palo Alto Networks: Site-to-Site IPSec VPN Between Palo Alto Networks Firewall and Cisco Router using VTI Not Passing Traffic

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

My lab with a SSG5 (6.3.0r17.0) and a Cisco 2811 (12.4(24)T8):

Laboratory

Juniper ScreenOS SSG

The configuration steps on the SSG are the following:

1. P1 and P2 Proposals, e.g., PFS group 14 (!), AES256, SHA1, 28800/3600 sec
2. Gateway with the IPv4 address of the other side (Cisco router), Preshared Key and user defined P1 Proposal
3. Numbered (Fixed IP) Tunnel Interface
4. AutoKey IKE profile which points to the just created gateway, P2 proposal and tunnel interface. The VPN Monitor can be set to automatically build the tunnel
5. Route through the tunnel interface with a gateway IP address of the tunnel interface of the other side

Here are my configuration screenshots:

Cisco Router

These are the commands for the Cisco CLI. The crypto isakmp policy and crypto ipsec transform-set values are exactly the same as the P1 and P2 proposals on the SSG. The crypto ipsec profile references the transform-set and is configured with a perfect-forward secrecy group of 14. The interface Tunnel has an IPv4 address, a source and destination (outside/untrust IP addresses from the router and the firewall), a mode of ipsec and a reference to the ipsec profile. Finally, the route to the remote network flows through the tunnel. (Note that this VPN does not use the “crypto map” commands.)

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 14
 lifetime 28800
!
crypto isakmp key aXedLr6oO4P83QIM2HlQPQnHy3aO9f address 172.16.1.1
!
crypto ipsec transform-set aes256-sha esp-aes 256 esp-sha-hmac
!
crypto ipsec profile SSG
 set transform-set aes256-sha
 set pfs group14
!
interface Tunnel111
 ip address 10.0.0.10 255.255.255.252
 tunnel source 172.16.1.5
 tunnel destination 172.16.1.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile SSG
!
ip route 192.168.111.0 255.255.255.0 Tunnel111 10.0.0.9

Stats

After the tunnel establishment, the monitor status on the SSG is Up:

And the Cisco router can be queried with the following commands:

fd-wv-ro03#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

1134  172.16.1.5      172.16.1.1               ACTIVE aes  sha  psk  14 00:58:33
       Engine-id:Conn-id =  SW:134

IPv6 Crypto ISAKMP SA

---------------------------------------

fd-wv-ro03#show crypto ipsec sa

interface: Tunnel111
    Crypto map tag: Tunnel111-head-0, local addr 172.16.1.5

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.16.1.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 279508, #pkts encrypt: 279508, #pkts digest: 279508
    #pkts decaps: 279547, #pkts decrypt: 279547, #pkts verify: 279547
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 172.16.1.5, remote crypto endpt.: 172.16.1.1
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xBFC4F0CA(3217354954)
     PFS (Y/N): Y, DH group: group14

     inbound esp sas:
      spi: 0x665D5E6E(1717395054)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 4171, flow_id: NETGX:2171, sibling_flags 80000046, crypto map: Tunnel111-head-0
        sa timing: remaining key lifetime (k/sec): (4493506/2655)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xBFC4F0CA(3217354954)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 4172, flow_id: NETGX:2172, sibling_flags 80000046, crypto map: Tunnel111-head-0
        sa timing: remaining key lifetime (k/sec): (4493506/2655)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

---------------------------------------

fd-wv-ro03#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.16.1.1 to network 0.0.0.0

S    192.168.121.0/24 [1/0] via 10.0.0.5, Tunnel121
C    192.168.151.0/24 is directly connected, FastEthernet0/1.151
S    192.168.120.0/24 [1/0] via 172.16.1.2
C    192.168.150.0/24 is directly connected, FastEthernet0/1.150
S    192.168.111.0/24 [1/0] via 10.0.0.9, Tunnel111
S    192.168.125.0/24 [1/0] via 172.16.1.2
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
C       10.0.0.8 is directly connected, Tunnel111
C       10.0.0.4 is directly connected, Tunnel121
S*   0.0.0.0/0 [1/0] via 172.16.1.1

The end.

I tested OSPF for IPv4 in my lab: I configured OSPF inside a single broadcast domain with five devices: 2x Cisco Router, Cisco ASA, Juniper SSG, and Palo Alto PA. It works perfectly though these are a few different vendors.

I will show my lab and will list all the configuration commands/screenshots I used on the devices. I won’t go into detail but maybe these listings help for a basic understanding of the OSPF processes on these devices.

I don’t want to say much about OSPF. Whoever reaches this post might already know about it. (Or read the articles about OSPF on Wikipedia or Cisco.)

Lab

This figure shows my lab and the basic OSPF values:

Note that I have a few more networks and Site-to-Site VPNs between these devices. So this figure is not complete at all but shows all relevant OSPF objects.

Some information

• Everything is in area 0.0.0.0, type broadcast
• Juniper SSG should be the DR: interface priority set to 100.
• Palo Alto PA should be the BDR: interface priority set to 50.
• Router-ID is always set manually to the IPv4 address of the interface (172.16.1.x).
• Cost for the interfaces as seen in the figure. For the Cisco routers I used the 

  auto-cost reference-bandwidth 10000

   command, while for all the other devices I configured them manually.
• Passive-interface on all user/access interfaces.
• Static routes are redistributed on a few devices for Remote Access VPN (Cisco ASA, Palo Alto) and Site-to-Site VPNs (Juniper).
• The default route to the Internet via the Juniper SSG is also redistributed. It has a cost of 42 because it is the answer of everything.
• No changes in the administrative distance / route preference, though it is different on all devices (Cisco: 110, Juniper: 60, Palo Alto: 30). However, since I am only using one dynamic routing protocol, this does not matter since it is only for local relevance on each firewall.

Of course, these are only the basic configurations for OSPF. I have not worked with authentication between the neighbors, nor have I fine-tuned other parameters such as graceful restart (non-stop forwarding), etc.

Cisco Router

I have two Cisco routers in my lab: One 2621 with IOS version 12.3(26) and one 2811 with IOS 12.4(24)T8.

This is the configuration for one of the Cisco routers. The config of the other router looks exactly the same:

router ospf 1
 router-id 172.16.1.5
 log-adjacency-changes
 auto-cost reference-bandwidth 10000
 passive-interface default
 no passive-interface FastEthernet0/0
 network 172.16.1.0 0.0.0.255 area 0.0.0.0
 network 192.168.150.0 0.0.0.255 area 0.0.0.0
 network 192.168.151.0 0.0.0.255 area 0.0.0.0

And here are two show commands:

fd-wv-ro03#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.1.1      100   FULL/DROTHER    00:00:33    172.16.1.1      FastEthernet0/0
172.16.1.2       50   FULL/BDR        00:00:37    172.16.1.2      FastEthernet0/0
172.16.1.3        1   FULL/DROTHER    00:00:36    172.16.1.3      FastEthernet0/0
172.16.1.4        1   FULL/DROTHER    00:00:32    172.16.1.4      FastEthernet0/0

fd-wv-ro03#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.16.1.1 to network 0.0.0.0

O E1 192.168.29.0/24 [110/10100] via 172.16.1.1, 07:27:01, FastEthernet0/0
O    192.168.122.0/24 [110/110] via 172.16.1.2, 2d19h, FastEthernet0/0
     192.168.133.0/32 is subnetted, 1 subnets
O E1    192.168.133.10 [110/1100] via 172.16.1.1, 00:41:33, FastEthernet0/0
S    192.168.121.0/24 [1/0] via 10.0.0.5, Tunnel121
C    192.168.151.0/24 is directly connected, FastEthernet0/1.151
O    192.168.120.0/24 [110/110] via 172.16.1.2, 2d19h, FastEthernet0/0
C    192.168.150.0/24 is directly connected, FastEthernet0/1.150
O    192.168.110.0/24 [110/200] via 172.16.1.1, 2d19h, FastEthernet0/0
O E1 192.168.9.0/24 [110/10100] via 172.16.1.1, 05:31:48, FastEthernet0/0
     192.168.126.0/25 is subnetted, 1 subnets
O E1    192.168.126.0 [110/1100] via 172.16.1.2, 2d19h, FastEthernet0/0
S    192.168.111.0/24 [1/0] via 10.0.0.9, Tunnel111
O    192.168.125.0/24 [110/110] via 172.16.1.2, 2d19h, FastEthernet0/0
O    192.168.130.0/24 [110/200] via 172.16.1.3, 2d21h, FastEthernet0/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
O    192.168.124.0/24 [110/110] via 172.16.1.2, 2d19h, FastEthernet0/0
O    192.168.131.0/24 [110/200] via 172.16.1.3, 2d21h, FastEthernet0/0
O    192.168.140.0/24 [110/200] via 172.16.1.4, 2d20h, FastEthernet0/0
O    192.168.141.0/24 [110/200] via 172.16.1.4, 2d20h, FastEthernet0/0
O E1 192.168.5.0/24 [110/10100] via 172.16.1.1, 06:12:23, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
C       10.0.0.8 is directly connected, Tunnel111
C       10.0.0.4 is directly connected, Tunnel121
O    192.168.113.0/24 [110/200] via 172.16.1.1, 2d19h, FastEthernet0/0
O E1 192.168.188.0/24 [110/10100] via 172.16.1.1, 1d00h, FastEthernet0/0
O    192.168.112.0/24 [110/200] via 172.16.1.1, 2d19h, FastEthernet0/0
O E1 192.168.86.0/24 [110/10100] via 172.16.1.1, 06:10:03, FastEthernet0/0
O*E1 0.0.0.0/0 [110/142] via 172.16.1.1, 01:45:39, FastEthernet0/0

Cisco ASA

The Cisco ASA 5505 in my lab runs at version 9.1(4).

I configured the ASA through the ASDM GUI. In the following configuration screenshots, the redistribution of the static routes to the AnyConnect RA VPN are also shown:

And these are some monitoring screenshots:

Juniper SSG

In my lab, it’s an SSG 5 with software version 6.3.0r17.0.

Here with the redistribution of static routes for the Site-to-Site VPNs (complicated: access list, route map, OSPF redistributable rules) and the default route:

And here are a few listings from the CLI. (For some reasons, the host route to the AnyConnect VPN Client on the Cisco ASA, 192.168.133.10/32,  is missing in the routing table. I do not know why. On the Cisco routers as well as on the Palo Alto it is present.)

fd-wv-fw01-> get vrouter trust-vr protocol ospf neighbor
VR: trust-vr RouterId: 172.16.1.1
----------------------------------
                Neighbor(s) on interface ethernet0/5.1 (Area 0.0.0.0)

                Neighbor(s) on interface ethernet0/5.10 (Area 0.0.0.0)

                Neighbor(s) on interface ethernet0/5.2 (Area 0.0.0.0)

                Neighbor(s) on interface ethernet0/5.3 (Area 0.0.0.0)

                Neighbor(s) on interface ethernet0/6 (Area 0.0.0.0)
IpAddr/IfIndex  RouterId        Pri State    Opt  Up           StateChg
------------------------------------------------------------------------------
172.16.1.5      172.16.1.5        1 Full     E    2d;20:30:14  (+7 -0)
172.16.1.3      172.16.1.3        1 2Way     E    2d;20:30:18  (+3 -0)
172.16.1.2      172.16.1.2       50 Full     E    2d;20:30:19  (+7 -0)
172.16.1.4      172.16.1.4        1 2Way     E    2d;20:30:23  (+3 -0)

fd-wv-fw01-> get route v4 protocol ospf


IPv4 Dest-Routes for  (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP/RIPng P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF/OSPFv3 E1: OSPF external type 1
E2: OSPF/OSPFv3 external type 2 trailing B: backup route


IPv4 Dest-Routes for  (40 entries)
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
         98   192.168.151.0/24         eth0/6      172.16.1.5   O   60    200     Root
*        97   192.168.150.0/24         eth0/6      172.16.1.5   O   60    200     Root
         96   192.168.131.0/24         eth0/6      172.16.1.3   O   60    200     Root
*       102   192.168.130.0/24         eth0/6      172.16.1.3   O   60    200     Root
         94   192.168.141.0/24         eth0/6      172.16.1.4   O   60    200     Root
*        93   192.168.140.0/24         eth0/6      172.16.1.4   O   60    200     Root
*        99   192.168.126.0/25         eth0/6      172.16.1.2  E1   60   1100     Root
*        92   192.168.125.0/24         eth0/6      172.16.1.2   O   60    110     Root
*        91   192.168.124.0/24         eth0/6      172.16.1.2   O   60    110     Root
*        90   192.168.122.0/24         eth0/6      172.16.1.2   O   60    110     Root
         89   192.168.121.0/24         eth0/6      172.16.1.2   O   60    110     Root
*        88   192.168.120.0/24         eth0/6      172.16.1.2   O   60    110     Root

Total number of ospf routes: 12

fd-wv-fw01-> get vrouter trust-vr protocol ospf config
VR: trust-vr RouterId: 172.16.1.1
----------------------------------
set protocol ospf
set enable
set advertise-def-route metric 42 metric-type 1
exit
set protocol ospf
set redistribute route-map "map_redist-vpns" protocol static
exit
set interface ethernet0/5.1 protocol ospf area 0.0.0.0
set interface ethernet0/5.1 protocol ospf passive
set interface ethernet0/5.1 protocol ospf enable
set interface ethernet0/5.1 protocol ospf cost 100
set interface ethernet0/5.10 protocol ospf area 0.0.0.0
set interface ethernet0/5.10 protocol ospf passive
set interface ethernet0/5.10 protocol ospf enable
set interface ethernet0/5.10 protocol ospf cost 100
set interface ethernet0/5.2 protocol ospf area 0.0.0.0
set interface ethernet0/5.2 protocol ospf passive
set interface ethernet0/5.2 protocol ospf enable
set interface ethernet0/5.2 protocol ospf cost 100
set interface ethernet0/5.3 protocol ospf area 0.0.0.0
set interface ethernet0/5.3 protocol ospf passive
set interface ethernet0/5.3 protocol ospf enable
set interface ethernet0/5.3 protocol ospf cost 100
set interface ethernet0/6 protocol ospf area 0.0.0.0
set interface ethernet0/6 protocol ospf enable
set interface ethernet0/6 protocol ospf priority 100
set interface ethernet0/6 protocol ospf cost 100

Palo Alto

Finally, the Palo Alto PA-200 in my lab runs at PAN-OS version 6.0.3.

Before we start, remember to add a security policy rule to allow OSPF on the specific zone. I have forgotten it and was searching a while in all OSPF configurations before I saw the denied packets in the traffic log.

Here are the configuration steps for the OSPF routing. I also configured a redistribution profile which is referenced in the export rules of the OSPF process:

The “More Runtime Stats” look like that:

And for the friends of the CLI, take one of these commands:

show routing protocol ospf neighbor
show routing protocol ospf interface
show routing protocol ospf summary
show routing route type ospf

Links

• Cisco: Configuring OSPF (IOS)
• Cisco: Configuring OSPF (ASA)
• Juniper: Configuring OSPF on firewall
• Corelan Team: Using OSPF on Juniper Netscreen Firewalls
• Palo Alto: Understanding Route Redistribution and Filtering

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.

Auf das neue AVM FRITZ!Box Update bin ich erst durch die Diskussion in meinem Blogpost über das VPN von der FRITZ!Box zur Juniper SSG gekommen. Dort haben sich einige Leser über Probleme mit der VPN-Verbindung seit dem Update auf FRITZ!OS 06.20 beklagt.

Probleme

(Alle folgenden Aussagen beziehen sich auf VPNs zwischen der FRITZ!Box und anderen Firewalls. Verbindungen zwischen zwei FRITZ!Boxen dürften super funktionieren.)

Auch ich habe folgende Probleme beim Experimentieren festgestellt:

• Das manuelle Anlegen eines Site-to-Site VPNs über die GUI (ebenfalls neues Feature seit 06.20) hat mangels notwendiger Optionen nicht geklappt.
• Das Importieren einer vpncfg Datei funktionierte nicht immer. Manchmal wurde nur ein Fehler angezeigt. Ich konnte es aber nicht richtig reproduzieren.
• Die FRITZ!Box ändert die Optionen für Phase 1 und Phase 2 in ihrer Konfiguration ab. Beispiel: Ich hatte

  phase2ss = "esp-3des-sha/ah-no/comp-no/pfs";

  in der importierten vpncfg Datei stehen, aber die FRITZ!Box (“Sicherung” einfach im Notepad++ öffnen und nach “vpncfg” suchen) hat folgendes hinterlegt:

  phase2ss = "esp-all-all/ah-none/comp-all/pfs";

  .
• Obwohl das VPN funktioniert, tauchen teilweise folgende Fehlermeldungen in der FRITZ!Box auf:

  VPN-Fehler: fd-wv-fw01, IKE-Error 0x2027

  . Ich kann nicht genau sagen, warum. In Summe sieht das denn in etwa so aus:
  
• Das größte Problem jedoch scheint zu sein, dass die FRITZ!Box keine Verbindungen zu den gängigen VPN-Firewalls mehr herstellen kann. Ich habe es ebenfalls nicht hingekommen, dass die FRITZ!Box ein VPN initiiert. Dies könnte etwas mit der Kompression der Phase 2 zu tun haben, die man nicht mehr explizit deaktivieren kann, da es im Proposal (wie oben bereits erwähnt) immer zu “comp-all” geändert wird. Wenn das VPN allerdings von einer Firewall zur FRITZ!Box aufgebaut wird, dann klappt es weiterhin ohne Probleme. Das Problem ist viel mehr, dass das kaum eine Firewall unterstützt. Schließlich müsste sie dazu ein statisches VPN (Main Mode) zu einer dynamischen IP-Adresse (Dyn DNS) aufbauen. Die Juniper SSG kann es, die Cisco ASA oder Palo Alto aber nicht.

Immerhin: DH-14 funktioniert

Nunja, bei meinem Test zwischen der Juniper ScreenOS Firewall (SSG 5 mit 6.3.0r17) und der FRITZ!Box 7390 mit FRITZ!OS 06.20 hat es ohne Probleme geklappt, da die Juniper zu einem dynamischen DNS Namen ein VPN im Main Mode aufbauen kann (siehe hier).

Folgende Proposals für Phase 1 (IKE) und Phase 2 (IPsec mit PFS) haben bei meinem VPN mit DH-14, AES-256 und SHA-1 zum Ziel geführt:

• phase1ss = "dh14/aes/sha";

• phase2ss = "esp-all-all/ah-none/comp-all/pfs";

(Vorher konnte die FRITZ!Box bei Phase 2 nur 3DES. Jetzt klappt dort auch AES-256. Das ist also ein weiterer Sicherheitsgewinn.) Alle anderen Einstellungen bleiben wie gewohnt.

Natürlich müssen die Proposals auf der Firewall ebenfalls angepasst werden. Steht das VPN erst mal, haben bei mir folgende CLI Befehle auf der Juniper offenbart, dass wirklich Diffie-Hellman Gruppe 14 für Phase 1 und Phase 2 (PFS) verwendet wurden:

Phase 1:

fd-wv-fw01-> get ike cookies

IKEv1 SA -- Active: 9, Dead: 0, Total 9

80182f/0003, 77.0.182.119:500->172.16.0.2:500, PRESHR/grp14/AES256/SHA, xchg(2) (fdorf-foobar.webernetz.net/grp-1/usr-1)
resent-tmr 322 lifetime 28800 lt-recv 3600 nxt_rekey 27749 cert-expire 0
responder, err cnt 0, send dir 1, cond 0x0
nat-traversal map not available
ike heartbeat              : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
DPD seq local 0, peer 0

Phase 2:

fd-wv-fw01-> get sa id 6
index 4, name fdorf-foobar.webernetz.net, peer gateway ip 77.0.182.119. vsys
auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1> vpngrp:<-1>. sa_list_nxt:<-1>.
tunnel id 6, peer id 4, NSRP Local.     site-to-site. Local interface is ethernet0/0 <172.16.0.2>.
  esp, group 14, a256 encryption, sha1 authentication
  autokey, IN active, OUT active
  monitor<1>, latency: 37, availability: 100
  DF bit: clear
  app_sa_flags: 0x24001a7
  proxy id: local 192.168.96.0/255.255.224.0, remote 192.168.29.0/255.255.255.0, proto 0, port 0/0
  ike activity timestamp: 2057872643
  DSCP-mark : enabled, value : 0
nat-traversal map not available
incoming: SPI bfc5493a, flag 00004000, tunnel info 40000006, pipeline
  life 3600 sec, 2755 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x95, window 0xffffffff, idle timeout value <0>, idled 7 seconds
  next pak sequence number: 0x0
  bytes/paks:204451860/1715993; sw bytes/paks:204451816/1715992
outgoing: SPI dc4a29c6, flag 00000000, tunnel info 40000006, pipeline
  life 3600 sec, 2755 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 7 seconds
  next pak sequence number: 0xa7
  bytes/paks:159531891/1916381; sw bytes/paks:159531891/1916381

Phase 1 Lifetime 3600

In diesem Zuge habe ich noch festgestellt, dass die FRITZ!Box auch für Phase 1 eine Lifetime von 3600 s vorgibt. Ich kenne standardmäßig eigentlich eine Lifetime von 8 h für Phase 1 und dann 1 h für Phase 2. Aber gut, sei’s drum. Diese Einstellung habe ich Firewallseitig bei mir jetzt noch korrigiert, so dass es jetzt so aussieht:

fd-wv-fw01-> get ike cookies

IKEv1 SA -- Active: 9, Dead: 0, Total 9

80182f/0003, 95.116.51.255:500->172.16.0.2:500, PRESHR/grp14/AES256/SHA, xchg(2) (fdorf-foobar.webernetz.net/grp-1/usr-1)
resent-tmr 322 lifetime 3600 lt-recv 3600 nxt_rekey 3429 cert-expire 0
responder, err cnt 0, send dir 1, cond 0x0
nat-traversal map not available
ike heartbeat              : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
DPD seq local 0, peer 0

Soll ich mich jetzt freuen?

So ganz weiß ich ja noch nicht, ob das Update auf 06.20 jetzt gut ist oder nicht. Das Mehr an Sicherheit durch Diffie-Hellman Gruppe 14 ist zwar super, bringt aber nichts, wenn gefühlte 90 % der VPNs nicht mehr funktionieren dürften. Immerhin baut der Otto-Normalverbraucher sein VPN ja von der FRITZ!Box zur Firewall in der Firma auf. Hm. Mal schauen, ob AVM da etwas tut.

[Update] AVM hat geantwortet

@webernetz in den aktuellen Labor-/Beta-Versionen für 7390 und 7490 wurden wieder Phase2-Strategien aufgenommen ohne Kompressionsproposal.

— FRITZ!Box (@AVM_DE) November 26, 2014

Sehr cool. Dann warten wir mal auf das nächste finale Update…

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.

Pre-Shared Keys in IPsec

The following section is related to site-to-site VPNs only and NOT to remote access VPNs.

1. The pre-shared key is merely used for authentication, not for encryption! IPsec tunnels rely on the ISAKMP/IKE protocols to exchange the keys for encryption, etc. But before IKE can work, both peers need to authenticate each other (mutual authentication). This is the only part in which the PSKs are used (RFC 2409).
2. If static IP addresses are used on both sides (= main mode can be used), an attacker who has the PSK must also spoof/redirect these public addresses over himself in order to establish a VPN connection. That is: Even if an attacker has a PSK, he must spoof a public IP address to use it to authenticate against the other side. This is quite unrealistic for normal persons with common ISP connections. Even skilled hackers must be able to inject falsified BGP routes or to sit nearby the customers default gateway/router.
3. But: If one remote side has only a dynamic IP address, IKE must use the aggressive mode for its authentication. In this scenario, a hash from the PSK traverses the Internet. An attacker can do an offline brute-force attack against this hash. That is: If the PSK is not complex enough, the attacker could succeed and would be able to establish a VPN connection to the network (if he furthermore knows the IDs of the site-to-site VPN peers which is no problem since they traverse through the Internet in plaintext, too).

Best Practice for PSKs

Since the PSKs must be configured on each side only once, it should be no problem to write 20-40 letters on the firewall. Thereby, a really complex key can be generated and used for the authentication of the VPN peer. Here are my tips:

1. Generate a new PSK for every VPN tunnel.
2. Use a password/passphrase generator for the creation of the PSK.
3. Generate a long PSK with at least 30 chars, to resist a brute-force attack. (See my article about password complexity.) To avoid problems, use only alphanumeric chars. Since the PSK with 30 chars is really long, the “small” character set of only 62 alphabets and numerals is no problem. The security level in this example would be round about 178 bit (since ).
   
4. Do NOT send the PSK to your peer over the Internet, but via phone, fax, or SMS.
5. There is no need to store the PSK anywhere else. If it is configured on both sides, you can discard it. In the worst case, you need to generate and transfer a new one.

Further Reading

• RFC 2409: The Internet Key Exchange (IKE)
• RFC 4301: Security Architecture for the Internet Protocol
• Michael Thumann, Enno Rey: PSK Cracking using IKE Aggressive Mode [PDF]
• eTutorials: Attacking IPsec VPNs

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.

Lab

This is my basic laboratory for this VPN connection. I am using a Palo Alto PA-200 with PAN-OS 6.1.1 while the FortiWiFi 90D has v5.2.2 installed.

Palo Alto

The Palo Alto is configured in the following way. Please refer to the descriptions under the images for detailed information.

(And do not forget the “untrust-untrust” policy that allows ipsec!)

FortiGate

And this is the way for the FortiGate firewall:

Monitoring

Following are a few screenshots and listings from both firewalls concerning the VPN:

Palo Alto CLI:

weberjoh@fd-wv-fw02> show vpn ike-sa gateway fd-wv-fw04

phase-1 SAs
GwID/client IP  Peer-Address           Gateway Name           Role Mode Algorithm          Established     Expiration      V  ST Xt Phase2
--------------- ------------           ------------           ---- ---- ---------          -----------     ----------      -  -- -- ------
             10 172.16.1.6             fd-wv-fw04             Resp Main PSK/DH14/A256/SHA256 Jan.20 11:12:57 Jan.20 19:12:57 v1 12  2      1

Show IKEv1 IKE SA: Total 1 gateways found. 1 ike sa found.

phase-2 SAs
GwID/client IP  Peer-Address           Gateway Name           Role Algorithm               SPI(in)  SPI(out) MsgID    ST Xt
--------------- ------------           ------------           ---- ---------               -------  -------- -----    -- --
             10 172.16.1.6             fd-wv-fw04             Resp DH14/tunl/ESP/A256/SHA256 A3D05151 C97B0AB3 C5572823  9  1

Show IKEv1 phase2 SA: Total 1 gateways found. 1 ike sa found.

FortiGate CLI:

fd-wv-fw04 # get vpn ike gateway fd-wv-fw02

vd: root/0
name: fd-wv-fw02
version: 1
interface: wan1 6
addr: 172.16.1.6:500 -> 172.16.1.2:500
created: 572s ago
IKE SA  created: 1/1  established: 1/1  time: 70/70/70 ms
IPsec SA  created: 1/1  established: 1/1  time: 90/90/90 ms

  id/spi: 20057 2b5ce64a51119571/defa8a4a3a5f0573
  direction: initiator
  status: established 572-572s ago = 70ms
  proposal: aes-256-sha256
  key: ed29b2dc34c59b46-c587e9daee5d91fb-d83448f2f91bcbae-60505b8efc09fb72
  lifetime/rekey: 28800/27927
  DPD sent/recv: 0000006e/00000000

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # get vpn ipsec tunnel name fd-wv-fw02

gateway
  name: 'fd-wv-fw02'
  type: route-based
  local-gateway: 172.16.1.6:0 (static)
  remote-gateway: 172.16.1.2:0 (static)
  mode: ike-v1
  interface: 'wan1' (6)
  rx  packets: 641  bytes: 65776  errors: 0
  tx  packets: 642  bytes: 168  errors: 1
  dpd: enabled/negotiated  idle: 5000ms  retry: 3  count: 0
  selectors
    name: 'fd-wv-fw02'
    auto-negotiate: disable
    mode: tunnel
    src: 0:0.0.0.0/0.0.0.0:0
    dst: 0:0.0.0.0/0.0.0.0:0
    SA
      lifetime/rekey: 3600/2907
      mtu: 1438
      tx-esp-seq: 280
      replay: enabled
      inbound
        spi: c97b0ab3
        enc:     aes  51128eb018d1ba7bc1e701f2c98689895df63dd1ca0c0252a07b178c5b867652
        auth: sha256  66b3dee1523d2aefd008e3d350a140133b76ebcb768974d6142c4d2f118c0862
      outbound
        spi: a3d05151
        enc:     aes  f168c4dc08b795dc978a4def5979acdc4aa7fbf0bedc1a1c4271bd2cbfe76f40
        auth: sha256  353c678f8ff1e782b3c59eed1628e80a574f2162f4ac5d38cbffe58e538dd064
      NPU acceleration: encryption(outbound) decryption(inbound)

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.

The VPN tunnel shown here is a route-based tunnel. That is, I do NOT use proxy-ids in phase 2 for the routing decision (which would be policy-based), but tunnel-interfaces and static routes. This applies to both devices.

The FortiGate firewall in my lab is a FortiWiFi 90D (v5.2.2), the Cisco router an 2811 with software version 12.4(24)T8.

Lab

The following figure shows the lab for this VPN:

FortiGate

These are the steps for the FortiGate firewall. Refer to the descriptions under the screenshots for further details:

Cisco Router

The Cisco router ist configured with the following commands:

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 14
 lifetime 28800
crypto isakmp key ZByLKnMxmohpNLBPAgwckJhY address 172.16.1.6
crypto isakmp keepalive 10 5
!
crypto ipsec transform-set aes256-sha esp-aes 256 esp-sha-hmac
!
crypto ipsec profile FG
 set transform-set aes256-sha
 set pfs group14
!
interface Tunnel161
 ip unnumbered FastEthernet0/1.151
 tunnel source 172.16.1.5
 tunnel destination 172.16.1.6
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile FG
!
ip route 192.168.161.0 255.255.255.0 Tunnel161

Monitoring

The FortiGate has an IPsec Monitor status of “Up”,

and can be queried via the CLI, too:

fd-wv-fw04 # get vpn ike gateway fd-wv-ro03

vd: root/0
name: fd-wv-ro03
version: 1
interface: wan1 6
addr: 172.16.1.6:500 -> 172.16.1.5:500
created: 1789239s ago
IKE SA  created: 1/63  established: 1/63  time: 380/461/2480 ms
IPsec SA  created: 1/514  established: 1/514  time: 360/382/590 ms

  id/spi: 20213 7369fa8ea50b4193/15f1b4d8a7818977
  direction: initiator
  status: established 22210-22210s ago = 380ms
  proposal: aes-256-sha1
  key: 2a0a6784e29fbe70-ade0d6d6a368bdca-5e81890d77f7ca7a-db7e9f75c746aa94
  lifetime/rekey: 28800/6289
  DPD sent/recv: 000d1c3e/4f447f71

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # get vpn ipsec tunnel name fd-wv-ro03

gateway
  name: 'fd-wv-ro03'
  type: route-based
  local-gateway: 172.16.1.6:0 (static)
  remote-gateway: 172.16.1.5:0 (static)
  mode: ike-v1
  interface: 'wan1' (6)
  rx  packets: 1584  bytes: 199840  errors: 0
  tx  packets: 1595  bytes: 135078  errors: 0
  dpd: enabled/negotiated  idle: 5000ms  retry: 3  count: 0
  selectors
    name: 'fd-wv-ro03'
    auto-negotiate: disable
    mode: tunnel
    src: 0:0.0.0.0/0.0.0.0:0
    dst: 0:0.0.0.0/0.0.0.0:0
    SA
      lifetime/rekey: 3600/923
      mtu: 1438
      tx-esp-seq: 600
      replay: enabled
      inbound
        spi: c97b0d54
        enc:     aes  43821ea396d91c75a865fa39ceb11dbae01761965f5c259c8ff08288034a2951
        auth:   sha1  e3b74f75ee315f3a6bb6c08f820fd7326e6efa1e
      outbound
        spi: 5ffae69c
        enc:     aes  8b4721951aa7878a50c865f1853fd55944dfc514e7f12fee8288d458f3aa8b64
        auth:   sha1  f8905c11627d73bd643bda374f8a6214dbc12281
      NPU acceleration: encryption(outbound) decryption(inbound)

The Cisco router show commands are the following:

fd-wv-ro03#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

1195  172.16.1.5      172.16.1.6               ACTIVE aes  sha  psk  14 01:46:56 D
       Engine-id:Conn-id =  SW:195

IPv6 Crypto ISAKMP SA

fd-wv-ro03#
fd-wv-ro03#
fd-wv-ro03#show crypto ipsec sa peer 172.16.1.6

interface: Tunnel161
    Crypto map tag: Tunnel161-head-0, local addr 172.16.1.5

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.16.1.6 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 1856, #pkts encrypt: 1856, #pkts digest: 1856
    #pkts decaps: 1855, #pkts decrypt: 1855, #pkts verify: 1855
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 1

     local crypto endpt.: 172.16.1.5, remote crypto endpt.: 172.16.1.6
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xC97B0D54(3380284756)
     PFS (Y/N): Y, DH group: group14

     inbound esp sas:
      spi: 0x5FFAE69C(1610278556)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2737, flow_id: NETGX:737, sibling_flags 80000046, crypto map: Tunnel161-head-0
        sa timing: remaining key lifetime (k/sec): (4506750/791)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xC97B0D54(3380284756)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2738, flow_id: NETGX:738, sibling_flags 80000046, crypto map: Tunnel161-head-0
        sa timing: remaining key lifetime (k/sec): (4506750/791)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
fd-wv-ro03#
fd-wv-ro03#
fd-wv-ro03#show ip route static
S    192.168.161.0/24 is directly connected, Tunnel161

Ciao.

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.

Since the Cisco ASA only supports policy-based VPNs, the proxy-IDs (phase 2 selectors) must be used on the FortiGate, too. Furthermore, the ASA only supports Diffie-Hellman group 5 (and not 14), as well as SHA-1 (and not SHA-256) for IKEv1.

I am running a FortiWiFi 90D (v5.2.2) and a Cisco ASA 5505 (9.2(3)) in my lab.

Lab

This is the lab for the tutorial:

FortiGate

Here are the screenshots from the Forti GUI. Refer to the descriptions for more details:

Cisco ASA

Similar for the ASA:

Monitoring

Both firewalls can be monitored via the GUI:

Or via some CLI commands. FortiGate:

fd-wv-fw04 # get vpn ike gateway fd-wv-fw03

vd: root/0
name: fd-wv-fw03
version: 1
interface: wan1 6
addr: 172.16.1.6:500 -> 172.16.1.3:500
created: 21574s ago
IKE SA  created: 1/1  established: 1/1  time: 210/210/210 ms
IPsec SA  created: 1/8  established: 1/8  time: 120/133/190 ms

  id/spi: 20345 e919d31b2152aa69/3c4f946f1067a8a0
  direction: initiator
  status: established 21574-21574s ago = 210ms
  proposal: aes-256-sha1
  key: 700a865e7d5dac74-38265025aadbea84-4e6578f76e8a94c0-55010a6860ca55d6
  lifetime/rekey: 28800/6925
  DPD sent/recv: 000ec23b/00000000

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # get vpn ipsec tunnel name fd-wv-fw03

gateway
  name: 'fd-wv-fw03'
  type: route-based
  local-gateway: 172.16.1.6:0 (static)
  remote-gateway: 172.16.1.3:0 (static)
  mode: ike-v1
  interface: 'wan1' (6)
  rx  packets: 23438  bytes: 3672312  errors: 0
  tx  packets: 42395  bytes: 4131302  errors: 2
  dpd: enabled/negotiated  idle: 5000ms  retry: 3  count: 0
  selectors
    name: 'johndoe'
    auto-negotiate: disable
    mode: tunnel
    src: 0:192.168.161.0/255.255.255.0:0
    dst: 0:192.168.131.0/255.255.255.0:0
    SA
      lifetime/rekey: 3600/3411
      mtu: 1438
      tx-esp-seq: 100
      replay: enabled
      inbound
        spi: c97b0f02
        enc:     aes  2ab3758cc346a6fc0390c3c445ab0d5023946e0de74004980b9848c6ad1022b4
        auth:   sha1  877bd440e77d72b21bd39b6bfbd1c5f9aba81e72
      outbound
        spi: b48f2846
        enc:     aes  537cf0f0d75c887efa35057a668126fbeab8874b8127a060802bd27e85d43dfb
        auth:   sha1  9099b7a9edfa18b6882fb15594356e26d5712361
      NPU acceleration: encryption(outbound) decryption(inbound)

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # get router info routing-table static
S*      0.0.0.0/0 [10/0] via 172.16.1.1, wan1
S       192.168.111.0/24 [10/0] is directly connected, fd-wv-fw01
S       192.168.121.0/24 [10/0] is directly connected, fd-wv-fw02
S       192.168.131.0/24 [10/0] is directly connected, fd-wv-fw03
S       192.168.151.0/24 [10/0] is directly connected, fd-wv-ro03

Cisco ASA:

fd-wv-fw03# show crypto ikev1 sa detail

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 172.16.1.6
    Type    : L2L             Role    : responder
    Rekey   : no              State   : MM_ACTIVE
    Encrypt : aes-256         Hash    : SHA
    Auth    : preshared       Lifetime: 28800
    Lifetime Remaining: 7274
fd-wv-fw03#
fd-wv-fw03#
fd-wv-fw03# show crypto ipsec sa peer 172.16.1.6 detail
peer address: 172.16.1.6
    Crypto map tag: outside_map, seq num: 4, local addr: 172.16.1.3

      access-list outside_cryptomap_3 extended permit ip 192.168.131.0 255.255.255.0 192.168.161.0 255.255.255.0
      local ident (addr/mask/prot/port): (192.168.131.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.161.0/255.255.255.0/0/0)
      current_peer: 172.16.1.6


      #pkts encaps: 24140, #pkts encrypt: 24140, #pkts digest: 24140
      #pkts decaps: 42925, #pkts decrypt: 42925, #pkts verify: 42925
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 24140, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #pkts no sa (send): 0, #pkts invalid sa (rcv): 0
      #pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
      #pkts invalid prot (rcv): 0, #pkts verify failed: 0
      #pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
      #pkts invalid pad (rcv): 0,
      #pkts invalid ip version (rcv): 0,
      #pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
      #pkts replay failed (rcv): 8
      #pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
      #pkts internal err (send): 0, #pkts internal err (rcv): 0

      local crypto endpt.: 172.16.1.3/0, remote crypto endpt.: 172.16.1.6/0
      path mtu 1500, ipsec overhead 74(44), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: C97B0F02
      current inbound spi : B48F2846

    inbound esp sas:
      spi: 0xB48F2846 (3029280838)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 5, IKEv1, }
         slot: 0, conn_id: 4096, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3914981/3485)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0xC97B0F02 (3380285186)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 5, IKEv1, }
         slot: 0, conn_id: 4096, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3914990/3484)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

And one more time, note that the ASA only implements policy-based VPNs. That is, the route in the routing table is NOT correct!! In my lab, the remote network behind the FortiGate (192.168.161.0/24) is also propagated via OSPF, while traffic passing to that network leaves via the VPN tunnel and not via this misleading routing entry:

fd-wv-fw03# show route 192.168.161.0

Routing entry for 192.168.161.0 255.255.255.0
  Known via "ospf 1", distance 110, metric 110, type intra area
  Last update from 172.16.1.6 on outside, 5:22:43 ago
  Routing Descriptor Blocks:
  * 172.16.1.6, from 172.16.1.6, 5:22:43 ago, via outside
      Route metric is 110, traffic share count is 1

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

The numbers for the groups are specified in RFC 5114: Additional Diffie-Hellman Groups for Use with IETF Standards. And according to this document on p. 30, the bits of security for the elliptic curve groups are the following:

• Group 19 = 256-bit EC = 128 bits of security
• Group 20 = 384-bit EC = 192 bits of security

That is, both groups offer a higher security level than the Diffie-Hellman groups 14 (103 bits) or 5 (89 bits). When using group 20 in IPsec phase 2 (PFS) with AES-256, the security level of the whole VPN connection is really 192 bit!

Test Group 19

The config changes for my test VPN between the SSG and the FortiGate were trivial. These are the proposals I am using now:

The site-to-site IPsec tunnel came up without any problems. The SSG reveals the correct crypto algorithms used for this VPN with the following CLI commands:

fd-wv-fw01-> get ike cookies

IKEv1 SA -- Active: 9, Dead: 0, Total 9

80102f/0003, 172.16.1.6:500->172.16.1.1:500, PRESHR/grp19/AES256/SHA2-256, xchg(5) (fd-wv-fw04/grp-1/usr-1)
resent-tmr 322 lifetime 28800 lt-recv 28800 nxt_rekey 28119 cert-expire 0
responder, err cnt 0, send dir 1, cond 0xc0
nat-traversal map not available
ike heartbeat              : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
DPD seq local 0, peer 548098

fd-wv-fw01->
fd-wv-fw01->
fd-wv-fw01-> get sa id 0x000000e
index 7, name fd-wv-fw04, peer gateway ip 172.16.1.6. vsys
auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1> vpngrp:<-1>. sa_list_nxt:<-1>.
tunnel id 14, peer id 7, NSRP Local.     site-to-site. Local interface is ethernet0/6 <172.16.1.1>.
  esp, group 19, a256 encryption, s256 authentication
  autokey, IN active, OUT active
  monitor<1>, latency: -1, availability: 100
  DF bit: clear
  app_sa_flags: 0x24001a7
  proxy id: local 0.0.0.0/0.0.0.0, remote 0.0.0.0/0.0.0.0, proto 0, port 0/0
  ike activity timestamp: -1118626869
  DSCP-mark : disabled
nat-traversal map not available
incoming: SPI f41f7e9f, flag 00004000, tunnel info 4000000e, pipeline
  life 3600 sec, 2847 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x5e0, window 0xffffffff, idle timeout value <0>, idled 0 seconds
  next pak sequence number: 0x0
  bytes/paks:14333168/321762; sw bytes/paks:14333168/321762
outgoing: SPI c97b1226, flag 00000000, tunnel info 4000000e, pipeline
  life 3600 sec, 2847 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 0 seconds
  next pak sequence number: 0x5e0
  bytes/paks:14141960/319910; sw bytes/paks:14141960/319910

However, I have not found a command on the FortiGate to display the Diffie-Hellman group that is used for a certain VPN. Does anyone know?!?

fd-wv-fw04 # get vpn ike gateway fd-wv-fw01

vd: root/0
name: fd-wv-fw01
version: 1
interface: wan1 6
addr: 172.16.1.6:500 -> 172.16.1.1:500
created: 1869s ago
IKE SA  created: 1/2  established: 1/2  time: 220/9230/18240 ms
IPsec SA  created: 1/14  established: 1/1  time: 200/200/200 ms

  id/spi: 20472 3441a7d55dce8550/73e8df93e0546c26
  direction: initiator
  status: established 1869-1851s ago = 18240ms
  proposal: aes-256-sha256
  key: 24f1972f370db1aa-83d5bfccd6c8332f-86d89c6ad33dd4ef-c1b3a19711119192
  lifetime/rekey: 28800/26648
  DPD sent/recv: 00085ddd/00000000

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # get vpn ipsec tunnel name fd-wv-fw01

gateway
  name: 'fd-wv-fw01'
  type: route-based
  local-gateway: 172.16.1.6:0 (static)
  remote-gateway: 172.16.1.1:0 (static)
  mode: ike-v1
  interface: 'wan1' (6)
  rx  packets: 3588  bytes: 590220  errors: 0
  tx  packets: 3589  bytes: 328150  errors: 12
  dpd: enabled/negotiated  idle: 5000ms  retry: 3  count: 0
  selectors
    name: 'blubb'
    auto-negotiate: disable
    mode: tunnel
    src: 0:0.0.0.0/0.0.0.0:0
    dst: 0:0.0.0.0/0.0.0.0:0
    SA
      lifetime/rekey: 3600/1721
      mtu: 1438
      tx-esp-seq: e00
      replay: enabled
      inbound
        spi: c97b1226
        enc:     aes  57ea27c4a01879ffe650c020cf32b7d4ad27fe92bb55522784880afa20e6c57c
        auth: sha256  88301accbbb19a968174a943d8ab8deec844ed1f97a2db8bef0204e94c213d08
      outbound
        spi: f41f7e9f
        enc:     aes  3d4e8405915d14f953b2fd943d7e4eb2411b5ff92fe5ce089c420b04bc65f5a6
        auth: sha256  1644e58d3e736b922bbce2a28368cf452f7ee7097a21607c70952a435fd67ebc
      NPU acceleration: encryption(outbound) decryption(inbound)

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # diagnose vpn tunnel list name fd-wv-fw01
list ipsec tunnel by names in vd 0
------------------------------------------------------
name=fd-wv-fw01 ver=1 serial=2 172.16.1.6:0->172.16.1.1:0 lgwy=static tun=intf mode=auto bound_if=6
proxyid_num=1 child_num=0 refcnt=9 ilast=0 olast=0
stat: rxp=4100 txp=4101 rxb=655840 txb=393614
dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=548360
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=blubb proto=0 sa=1 ref=2 serial=3
  src: 0:0.0.0.0/0.0.0.0:0
  dst: 0:0.0.0.0/0.0.0.0:0
  SA: ref=7 options=0000000e type=00 soft=0 mtu=1438 expire=1499/0B replaywin=1024 seqno=1000
  life: type=01 bytes=0/0 timeout=3572/3600
  dec: spi=c97b1226 esp=aes key=32 57ea27c4a01879ffe650c020cf32b7d4ad27fe92bb55522784880afa20e6c57c
       ah=sha256 key=32 88301accbbb19a968174a943d8ab8deec844ed1f97a2db8bef0204e94c213d08
  enc: spi=f41f7e9f esp=aes key=32 3d4e8405915d14f953b2fd943d7e4eb2411b5ff92fe5ce089c420b04bc65f5a6
       ah=sha256 key=32 1644e58d3e736b922bbce2a28368cf452f7ee7097a21607c70952a435fd67ebc
  dec:pkts/bytes=4097/655556, enc:pkts/bytes=4101/393966
  npu_flag=03 npu_rgwy=172.16.1.1 npu_lgwy=172.16.1.6 npu_selid=9

Test Group 20

And, of course, very similar for group 20 (while still only the SSG shows the active DH groups in its command line output):

fd-wv-fw01-> get ike cookies

IKEv1 SA -- Active: 9, Dead: 0, Total 9

80102f/0003, 172.16.1.6:500->172.16.1.1:500, PRESHR/grp20/AES256/SHA2-256, xchg(5) (fd-wv-fw04/grp-1/usr-1)
resent-tmr 322 lifetime 28800 lt-recv 28800 nxt_rekey 28743 cert-expire 0
responder, err cnt 0, send dir 1, cond 0xc0
nat-traversal map not available
ike heartbeat              : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
DPD seq local 0, peer 551543

fd-wv-fw01->
fd-wv-fw01->
fd-wv-fw01-> get sa id 0x000000e
index 7, name fd-wv-fw04, peer gateway ip 172.16.1.6. vsys
auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1> vpngrp:<-1>. sa_list_nxt:<-1>.
tunnel id 14, peer id 7, NSRP Local.     site-to-site. Local interface is ethernet0/6 <172.16.1.1>.
  esp, group 20, a256 encryption, s256 authentication
  autokey, IN active, OUT active
  monitor<1>, latency: -1, availability: 100
  DF bit: clear
  app_sa_flags: 0x24001a7
  proxy id: local 0.0.0.0/0.0.0.0, remote 0.0.0.0/0.0.0.0, proto 0, port 0/0
  ike activity timestamp: -1099508533
  DSCP-mark : disabled
nat-traversal map not available
incoming: SPI f41f7ed6, flag 00004000, tunnel info 4000000e, pipeline
  life 3600 sec, 3491 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0xd9, window 0xffffffff, idle timeout value <0>, idled 0 seconds
  next pak sequence number: 0x0
  bytes/paks:17442652/358913; sw bytes/paks:17442484/358911
outgoing: SPI c97b1237, flag 00000000, tunnel info 4000000e, pipeline
  life 3600 sec, 3491 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 0 seconds
  next pak sequence number: 0xd9
  bytes/paks:17251740/357065; sw bytes/paks:17251740/357065

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.

IPsec Proposals

Auf Anfrage hat mir AVM die “Strategien” für IPsec in der Version 06.23 zur Verfügung gestellt. Diese sind wie folgt:

Phase 1:

• dh5/aes/sha
• dh14/aes/sha
• dh15/aes/sha
• def/all/all
• alt/all/all
• all/all/all
• LT8h/all/all/all

Phase 2:

• esp-aes-sha/ah-all/comp-lzjh-no/pfs
• esp-all-all/ah-all/comp-all/pfs
• esp-all-all/ah-all/comp-all/no-pfs
• esp-all-all/ah-none/comp-all/pfs
• esp-3des-sha/ah-no/comp-no/no-pfs
• esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs
• esp-all-all/ah-none/comp-all/no-pfs
• LT8h/esp-all-all/ah-none/comp-all/pfs
• LT8h/esp-all-all/ah-none/comp-all/no-pfs

Mein Ziel war es also, in beiden Phase möglichst DH-14 und AES-256 einzusetzen, wobei Phase 1 gerne eine Lifetime von 8 Stunden haben darf, während Phase 2 nur eine Stunde laufen soll. (Hintergrund: Da es ständig zu Verbindungsabbrüchen beim Rekeying kommt, sind längere Lifetimes hier wohl besser.) Leider hat das nicht exakt so geklappt…

Tests

Die folgenden Tests habe ich extra alle im Aggressive Mode laufen lassen, so dass stets die FRITZ!Box (hinter einer dynamischen IP) die VPN-Verbindung initiiert. Bei einigen Kunden scheint das Voraussetzung zu sein. Als Gegenstelle hatte ich eine Juniper ScreenOS SSG 5 mit Version 6.3.0r18.0 im Labor (siehe hier). Die FRITZ!Box ist eine 7390 und wie gesagt mit FRITZ!OS Version 06.23.

Folgende Tabelle zeigt immer zweizeilig die Einstellungen für Phase 1 und 2:

Sehr komisch ist also zum Beispiel, dass bei Tests 1 und 3 für Phase 2 jeweils das gleiche Proposal seitens der FRITZ!Box verwendet wurde, es aber in Test 1 mit DH-14 funktioniert hat, in Test 3 aber nicht. Hm.

Bei Variante 1 sah es auf der Juniper SSG also so aus:

fd-wv-fw01-> get ike cookies

IKEv1 SA -- Active: 9, Dead: 0, Total 9

80182f/0006, 95.116.94.50:500->172.16.0.2:500, PRESHR/grp14/AES256/SHA, xchg(4) (fdorf-foobar.webernetz.net/grp-1/usr-1)
resent-tmr 322 lifetime 3600 lt-recv 3600 nxt_rekey 3040 cert-expire 0
responder, err cnt 0, send dir 1, cond 0xc0
nat-traversal map not available
ike heartbeat              : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
DPD seq local 0, peer 0

fd-wv-fw01->
fd-wv-fw01->
fd-wv-fw01-> get sa id 6
index 4, name fdorf-foobar.webernetz.net, peer gateway ip 95.116.94.50. vsys
auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1> vpngrp:<-1>. sa_list_nxt:<-1>.
tunnel id 6, peer id 4, NSRP Local.     site-to-site. Local interface is ethernet0/0 <172.16.0.2>.
  esp, group 14, a256 encryption, sha1 authentication
  autokey, IN active, OUT active
  monitor<1>, latency: 37, availability: 100
  DF bit: clear
  app_sa_flags: 0x24001a7
  proxy id: local 192.168.96.0/255.255.224.0, remote 192.168.29.0/255.255.255.0, proto 0, port 0/0
  ike activity timestamp: -1633079230
  DSCP-mark : enabled, value : 0
nat-traversal map not available
incoming: SPI f41f788e, flag 00004000, tunnel info 40000006, pipeline
  life 3600 sec, 3001 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x263, window 0xffffffff, idle timeout value <0>, idled 1 seconds
  next pak sequence number: 0x0
  bytes/paks:105778793/531384; sw bytes/paks:105772872/531377
outgoing: SPI d8c63b56, flag 00000000, tunnel info 40000006, pipeline
  life 3600 sec, 3001 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 0 seconds
  next pak sequence number: 0x271
  bytes/paks:48706409/564603; sw bytes/paks:48706409/564603

Variante 4 entsprechend so:

fd-wv-fw01-> get ike cookies

IKEv1 SA -- Active: 9, Dead: 0, Total 9

80182f/0006, 95.116.94.50:500->172.16.0.2:500, PRESHR/grp2/AES256/SHA, xchg(4) (fdorf-foobar.webernetz.net/grp-1/usr-1)
resent-tmr 322 lifetime 28800 lt-recv 28800 nxt_rekey 28762 cert-expire 0
responder, err cnt 0, send dir 1, cond 0x0
nat-traversal map not available
ike heartbeat              : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
DPD seq local 0, peer 0

fd-wv-fw01->
fd-wv-fw01->
fd-wv-fw01-> get sa id 6
index 4, name fdorf-foobar.webernetz.net, peer gateway ip 95.116.94.50. vsys
auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1> vpngrp:<-1>. sa_list_nxt:<-1>.
tunnel id 6, peer id 4, NSRP Local.     site-to-site. Local interface is ethernet0/0 <172.16.0.2>.
  esp, group 2, a256 encryption, sha1 authentication
  autokey, IN active, OUT active
  monitor<0>, latency: -1, availability: 0
  DF bit: clear
  app_sa_flags: 0x2400027
  proxy id: local 192.168.96.0/255.255.224.0, remote 192.168.29.0/255.255.255.0, proto 0, port 0/0
  ike activity timestamp: -1630958802
  DSCP-mark : enabled, value : 0
nat-traversal map not available
incoming: SPI f41f789d, flag 00004000, tunnel info 40000006, pipeline
  life 3600 sec, 3518 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x56, window 0xffffffff, idle timeout value <0>, idled 0 seconds
  next pak sequence number: 0x0
  bytes/paks:105813717/531796; sw bytes/paks:105807796/531789
outgoing: SPI 6381d8bc, flag 00000000, tunnel info 40000006, pipeline
  life 3600 sec, 3518 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 0 seconds
  next pak sequence number: 0x58
  bytes/paks:48741197/565019; sw bytes/paks:48741197/565019

Und hier noch ein Screenshot von einem Test zur Cisco ASA Version 8.4(7). Hier wurde ebenfalls die Variante mit einer IKE Lifetime von 8 h verwendet. Die Gegenstelle hatte sogar bereits FRITZ!OS 06.24 installiert:

Fazit

So ganz eindeutig scheint es noch nicht zu sein. Die “all/all/all” Varianten decken doch nicht alles ab und die anderen klappen manchmal und manchmal aber auch nicht. Man hat aktuell die Wahl, ob man DH-14 in beiden Phasen verwenden möchte (was aus sicherheitstechnischer Sicht Sinn macht) oder lieber auf eine Lifetime von 8 h in Phase 1 zurückgreift, dann aber nur DH-2 zum Laufen bekommt.

Templates

Hier noch mal zwei komplette Templates, so wie ich sie aktuell verwende. Bei beiden wird davon ausgegangen, dass die FRITZ!Box eine dynamische IP Adresse hat, also der Aggressive Mode verwendet wird.

DH-14 mit Lifetime 1 h

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "NAME-OF-THE-VPN";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 192.0.2.86;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "foobar.webernetz.net";
                }
                remoteid {
                        ipaddr = "192.0.2.86";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "dh14/aes/sha";
                keytype = connkeytype_pre_shared;
                key = "ThisIsThePSKAndShouldBeGeneratedRandomly";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
                accesslist = "permit ip any 192.168.0.0 255.255.255.0";
        }  ike_forward_rules =	"udp 0.0.0.0:500 0.0.0.0:500", 
								"udp 0.0.0.0:4500 0.0.0.0:4500";
	}

Lifetime 8 h aber nur DH-2

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "NAME-OF-THE-VPN";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 192.0.2.86;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "foobar.webernetz.net";
                }
                remoteid {
                        ipaddr = "192.0.2.86";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "LT8h/all/all/all";
                keytype = connkeytype_pre_shared;
                key = "ThisIsThePSKAndShouldBeGeneratedRandomly";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
                accesslist = "permit ip any 192.168.0.0 255.255.255.0";
        }  ike_forward_rules =	"udp 0.0.0.0:500 0.0.0.0:500", 
								"udp 0.0.0.0:4500 0.0.0.0:4500";
	}

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:

I assume that there is already a VPN connection between two Juniper ScreenOS firewalls in place. If so, the steps to tunnel IPv6 through this VPN tunnel are quite easy. (Note that this is NOT a 6in4 tunnel! It is simply a forwarding of IPv6 packets through a common IPsec site-to-site tunnel.)

Tunneling

The following configuration steps are required:

1. Enable IPv6 in the “host” mode on the tunnel interfaces
2. Configure static IPv6 routes through these tunnel interfaces
3. Do regular IPv6 stuff: Enable IPv6 with Router Advertisements at the remote site and configure the appropriate security policies

This is how my networks look like, followed by the configuration screenshots:

(For further information: Read the descriptions under the screenshots.)

Done.

Latency & Hop Count

One side note about the latency: Yes, since the IPv6 connection must travel through the IPv4 tunnel (with its hops to the main site) as well as through the native IPv6 Internet to the final destination, the total hop count (i.e., latency) is approximately doubled. However, I made an interesting observation: My main site has a quite good ISP connection with almost the same ping times of IPv4 and IPv6 (latency of 3-4 ms). My home site has a normal German DSL connection and I am surfing via WLAN –> IPv4 latency of about 23 ms. And now, my new IPv6 connection has an added latency of about 29 ms, which is compared to the native IPv4 connectivity not that bad.

weberjoh@jw-nb09:~$ ping heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=247 time=23.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=2 ttl=247 time=22.6 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3 ttl=247 time=23.1 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=4 ttl=247 time=23.8 ms
^C
--- heise.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 22.644/23.251/23.888/0.486 ms
weberjoh@jw-nb09:~$
weberjoh@jw-nb09:~$
weberjoh@jw-nb09:~$ ping6 heise.de
PING heise.de(redirector.heise.de) 56 data bytes
64 bytes from redirector.heise.de: icmp_seq=1 ttl=54 time=29.4 ms
64 bytes from redirector.heise.de: icmp_seq=2 ttl=54 time=29.8 ms
64 bytes from redirector.heise.de: icmp_seq=3 ttl=54 time=30.4 ms
64 bytes from redirector.heise.de: icmp_seq=4 ttl=54 time=29.9 ms
^C
--- heise.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 29.427/29.930/30.421/0.374 ms

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.

Labor

Mein Labor sah wie folgt aus:

Die FRITZ!Box ist eine 7390 mit FRITZ!OS 06.30, während die Fortinet Firewall eine FortiWiFi 90D mit Version 5.2.2 ist. Wie im Internet üblich ist die FortiGate mit einer statischen IP-Adresse versehen (obgleich 1 zu 1 geNATet), während sich die FRITZ!Box hinter einer dynamischen IP verbirgt. Mit einem dynamischen DNS Dienst ist immerhin ein FQDN für die FRITZ!Box verfügbar.

Sehr praktisch bei FortiOS ist ja, dass bei IKE auch dann der Main Mode verwendet werden kann, wenn die Gegenstelle lediglich über eine dynamische IP (mit einem DynDNS Namen) verfügt. Sprich: Es ist nicht der Aggressive Mode nötig, um ein VPN zu bauen, und vorallem kann der Tunnelaufbau auch von der FortiGate selbst initiiert werden. (Exakt vergleichbar mit der Juniper SSG, die das genau so kann, siehe hier.)

FortiGate

Folgende Schritte sind seitens der FortiGate nötig. In den Beschriftungen unterhalb der Screenshots stehen weitere Details:

FRITZ!Box

Für die FRITZ!Box muss folgendes Template angepasst werden. Gelb markiert sind all die Zeilen, die zwingend angepasst werden müssen. Die Proposals für Phase 1 und 2 können natürlich auch anders gewählt werden, solange das Pendant bei der FortiGate stimmt (siehe hier für mehr Details bezüglich der Proposals der FRITZ!Box).

Hinweis: Dieses Template unterscheidet sich in einer Kleinigkeit von quasi allen anderen Templates, die hier auf meinem Blog sind: Es ist sowohl die localid als auch die remoteid vom Typ “fqdn”. In vielen anderen Beispielen habe ich hier bei der remoteid den Typ “ipaddr” gehabt. Dieser lässt sich auf der FortiGate leider nicht einstellen, da dort unter Verwendung einer IP-Adresse trotzdem ein String versendet wird. Daher ist hier bei der FRITZ!Box zwingend der fqdn nötig.

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "fortigate-vpn";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 80.154.108.233;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "fritzbox.webernetz.net";
                }
                remoteid {
                        fqdn = "blubb";
                }
                mode = phase1_mode_idp;
                phase1ss = "dh14/aes/sha";
                keytype = connkeytype_pre_shared;
                key = "RX-2RUz2UKpFiPXi6B6DJss5TWbW-DzvTMwc";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.29.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.161.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
                accesslist = "permit ip any 192.168.161.0 255.255.255.0";
        }  ike_forward_rules =	"udp 0.0.0.0:500 0.0.0.0:500", 
								"udp 0.0.0.0:4500 0.0.0.0:4500";
	}

Es läuft …

wenn es grün leuchtet.

Wer mehr Infos zur VPN-Verbindung möchte, kann auf der FortiGate zum Beispiel mit den folgenden Befehlen Details herausfinden:

fd-wv-fw04 # get vpn ike gateway fritzbox

vd: root/0
name: fritzbox
version: 1
interface: wan1 6
addr: 172.16.1.6:500 -> 77.1.138.66:500
created: 1484s ago
peer-id: fritzbox.webernetz.net
peer-auth: no
IKE SA  created: 1/1  established: 1/1  time: 2260/2260/2260 ms
IPsec SA  created: 1/1  established: 1/1  time: 2190/2190/2190 ms

  id/spi: 27873 c0946dbb7e367bbf/98f5902234833225
  direction: initiator
  status: established 1484-1482s ago = 2260ms
  proposal: aes-256-sha1
  key: c24d006dcddd88db-561bdd168fb5ece9-fd87c497587cb16c-b0ccbb1302b38310
  lifetime/rekey: 3600/1817
  DPD sent/recv: 00016e13/00000000

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # get vpn ipsec tunnel name fritzbox

gateway
  name: 'fritzbox'
  type: route-based
  local-gateway: 172.16.1.6:0 (static)
  remote-gateway: 77.1.138.66:0 (static)
  mode: ike-v1
  interface: 'wan1' (6)
  rx  packets: 2  bytes: 236  errors: 0
  tx  packets: 2  bytes: 168  errors: 3
  dpd: enabled/negotiated  idle: 5000ms  retry: 3  count: 0
  selectors
    name: 'fritzbox'
    auto-negotiate: disable
    mode: tunnel
    src: 0:192.168.161.0/255.255.255.0:0
    dst: 0:192.168.29.0/255.255.255.0:0
    SA
      lifetime/rekey: 3600/2121
      mtu: 1438
      tx-esp-seq: 3
      replay: enabled
      inbound
        spi: c97b3074
        enc:     aes  2cdc2d66d55ce60a9d0653e47045dc09495210ff01e4e164317407d19d8abd12
        auth:   sha1  a18c972688001670905a0de1d85e6383e79d4aad
      outbound
        spi: 4e200a54
        enc:     aes  d7a420011bf1b1e7408915e60a02e9eed4fdee6124bd9266d43a5e2f4e3f4ea2
        auth:   sha1  58f2788cf82545e5938a95fd421f5ab9828505b3
      NPU acceleration: encryption(outbound) decryption(inbound)

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # get router info routing-table static
S*      0.0.0.0/0 [10/0] via 172.16.1.1, wan1
S       192.168.29.0/24 [10/0] is directly connected, fritzbox
S       192.168.121.0/24 [10/0] is directly connected, fd-wv-fw02
S       192.168.131.0/24 [10/0] is directly connected, fd-wv-fw03

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

IPv6 Site-to-Site VPN Principles

On both sites of the VPN tunnel, the following steps must be accomplished:

1. Static and permanent (!) route to the other site through VPN: For route-based VPNs, the static route through the tunnel should be “permanent”, i.e., should remain in the routing table even if the VPN is not established. Otherwise, in case of a VPN error, new connections could take the default route directly to the Internet. This principle might be problematic with policy-based VPNs. In such cases (if the policy-vpn has precedence over the routing table), a static route to the remote site subnet into the Null0 interface can be set.
2. Unicast Reverse Path Forwarding (uRPF): If the static and permanent route is set and the remote site sends packets through the Internet, these IPv6 packets  come from the untrust interface and will be discarded because they should only come in from the VPN tunnel interface.
3. Explicit policy from “trust -> untrust” that denies traffic to the remote site: If someone accidentally deletes the static route, traffic would be routed directly through the Internet. With this deny policy, it would be blocked at the firewall before it leaves it. (Another option would be to “reject” the traffic, i.e., send an ICMP unreachable back to the sender. This would help troubleshooting the issue.) Note that a policy from “trust -> vpn” must be set to allow traffic through the VPN at all.
4. Explicit policy from “untrust -> trust” that denies traffic from the remote site: If not an explicit “deny any any” is already set, this rule helps to block incoming traffic if the remote site has not implemented the preceding steps correctly.

All four points at-a-glance:

Some notes:

• Of course, a policy from “trust -> vpn” that allows certain traffic must be in place, too. But this should be the case anyway, because otherwise the VPN would not work. Similarly, a policy from “vpn -> trust”, if needed.
• With static IPv6 addresses/prefixes at the remote site, certain allow policy from “untrust -> trust” with limitations of the source IPv6 addresses of the remote site would be ok, if ony secured protocols (such as https, ssh, ftps, …) are used. However, if it was decided to use a site-to-site VPN tunnel, this should not be the case anymore.
• It is necessary to have the deny policies in place to not only rely on proper routing. Security must be made at a security stage (policy) and not at the network layer (routing)! [Similar to: Why NAT has nothing to do with Security!]

Example

The following paragraphs show an example of these principles with two Juniper ScreenOS firewalls. I used a site-to-site VPN that is established over IPv4 but routes IPv6 traffic. This is the lab:

Before VPN

Before the site-to-site VPN tunnel was configured, the remote office could reach the headquarter directly via the Internet. The following traceroute output is made from a Windows PC in the remote office, pinging into the headquarter. Note that this IPv6 connection traverses directly through the Internet:

C:\Users\Johannes Weber>tracert -d lx.webernetz.net

Routenverfolgung zu jw-nb12.webernetz.net [2003:51:6012:110::9]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  2003:50:aa0a:3584::1
  2     3 ms     2 ms     2 ms  2003:0:1301:4205::1
  3     4 ms     6 ms     6 ms  2003:0:1301:4238::2
  4     6 ms     7 ms     7 ms  2003:0:1302:403::1
  5     4 ms     3 ms     4 ms  2003:0:1302:403::2
  6     5 ms     4 ms     4 ms  2003:51:6012::2
  7     5 ms     5 ms     5 ms  2003:51:6012:110::9

Ablaufverfolgung beendet.

A route lookup to the destination IPv6 address on the router/firewall looks like that: It uses the default route (in my case through interface eth0/0):

fd-we-fw01-> get vrouter trust-vr route ip 2003:51:6012:110::9
 Dest for 2003:51:6012:110::9
--------------------------------------------------------------------------------------
trust-vr       : => ::/0 (id=1) via fe80::462b:3ff:fe19:300 (vr: trust-vr)
                    Interface ethernet0/0 , metric 1

With VPN

Now, a site-to-site VPN between the two firewalls is established. The following screenshots document the static routes and policies on both Juniper SSG firewalls:

Now, the same traceroute command reveals the route through the encrypted VPN tunnel. (The second hop is not answering, because I am only using link-local IPv6 addresses on the tunnel interfaces):

C:\Users\Johannes Weber>tracert -d lx.webernetz.net

Routenverfolgung zu jw-nb12.webernetz.net [2003:51:6012:110::9]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  2003:50:aa0a:3584::1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     6 ms     6 ms     7 ms  2003:51:6012:110::9

Ablaufverfolgung beendet.

The routing table lookup on the firewall on the remote site now shows the usage of the tunnel interface:

fd-we-fw01-> get vrouter trust-vr route ip 2003:51:6012:110::9
 Dest for 2003:51:6012:110::9
--------------------------------------------------------------------------------------
trust-vr       : => 2003:51:6012:110::/64 (id=14) via :: (vr: trust-vr)
                    Interface tunnel.1 , metric 1

Broken VPN -> Still Permanent Route

In this example, the VPN could not establish a connection. But due to the permanent route, traffic is not exposed in the Internet since it is still routed to the tunnel interface. Of course, the connections did not work. (Tested from the remote site.)

C:\Users\Johannes Weber>tracert -d lx.webernetz.net

Routenverfolgung zu jw-nb12.webernetz.net [2003:51:6012:110::9]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  2003:50:aa0a:3584::1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8  ^C

Deleted Route -> Still Policy

In this example someone misconfigured the routing table and deleted the specific route through the VPN. No traffic traverses the Internet because of principle number three, which still has the “deny” policy from trust -> untrust. (Tested from the remote site.)

Deleted Remote Policy -> Still Headquarter Policy

In this example, the route and all policies on the remote site were deleted. Now the connection worked until the headquarter firewall through the Internet, but was blocked there due to principle 2 and 4:

C:\Users\Johannes Weber>tracert -d lx.webernetz.net

Routenverfolgung zu jw-nb12.webernetz.net [2003:51:6012:110::9]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  2003:50:aa0a:3584::1
  2     3 ms     3 ms     3 ms  2003:0:1301:4205::1
  3     7 ms     4 ms     5 ms  2003:0:1301:4238::2
  4     6 ms    18 ms    16 ms  2003:0:1302:403::1
  5     3 ms     3 ms     3 ms  2003:0:1302:403::2
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9     *        *        *     Zeitüberschreitung der Anforderung.
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11  ^C

Principle 2 (uRPF) on the headquarter worked, because it did not expect traffic from the remote site’s IPv6 subnet from the untrust interface, and therefore blocked it:

But even after I deleted the route on the headquarter firewall into the remote site (uRPF won’t block connections anymore), the connections were blocked due to principle number 4, which is the untrust -> trust DENY policy:

Conclusion

With this four principles/recommendations it is possible to ensure that IPv6 traffic which should only traverse through a secure VPN connection won’t ever traverse through the Internet, even in case of a VPN failure. They furthermore ensure, that security is not made only at the network layer (routing), but at a firewall stage (policy).