Posts Tagged ipsec

Building a remote office VPN with FortiGate firewalls

A customer has its own PI range of public IP addresses, and they way to use part of this range in a remote office and place some servers there. The remote office is connected via some third-party ISP. So, the VPN tunnel should route the customer’s addresses and provide full Internet access to the remote office. Both sides should use Fortinet’s FortiGate firewalls.

It is quite natural to use a policy-based VPN for the remote side: the policy would match “all” destination addresses, and send all Internet traffic to the IPSec tunnel. But the central site is a firewall on a stick, so both Internet and IPSec traffic are going through the same wan1 interface.

Professional support at a local Fortinet partner gave an idea that I could not derive from any documentation: policy-based VPN and interface-based VPN can work together within the same IPSec tunnel.

So, the remote site is configured with policy-based VPN. The tunnel’s Phase 2 selector is 0.0.0.0/0.0.0.0 for both source and destination. The VPN policy matches all traffic from the local LAN addresses to “all”.

The central site is configured as interface-based VPN. The tunnel is pointing to a dynamic DNS endpoint, and the Phase 2 selector is also 0.0.0.0/0.0.0.0 (as it must match the selector on the other side of the tunnel). Then, it’s accomplished with in- and outbound policies that “ACCEPT” all traffic from and to the remote LAN, and a static route that sends all traffic toward remote LAN through the tunnel.

Leave a comment

IPSEC VPN connection between Racoon and Checkpoint

When connecting a Checkpoint firewall with a Linux or BSD server with Racoon software, the following error is quite typical in the very beginning of  Phase 1 negotiation:

2011-04-14 15:47:21: DEBUG: 40 bytes message received from 62.x.x.x[500] to 2
13.x.x.x[500]
2011-04-14 15:47:21: DEBUG:
30652081 6d92a9ee 00000000 00000000 0b100500 4bd389ff 00000028 0000000c
00000000 0100000e
2011-04-14 15:47:21: DEBUG: malformed cookie received or the initiator's cookies collide.

The ting is, racoon uses AES key length of 128 bit by default, and Checkpoint firewalls use AES-256 (for Phase 1 only 256-bit keys are supported).

The following configuration should fix the problem. Also “sainfo” line shows how to set AES-256 for  Phase 2:

remote 62.x.x.x {
        exchange_mode main;
        proposal {
                encryption_algorithm aes 256;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
                lifetime time 1440 minutes;
        }
        generate_policy off;
        nat_traversal force;
}

sainfo address 213.x.x.x[any] any address 62.y.y.y/24[any] any {
        encryption_algorithm aes 256;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

, , ,

4 Comments