Configuring Third Party IPsec Devices

Any VPN device which supports standard IPsec may be connected to a device running pfSense. pfSense is used in production in combination with numerous vendors’ equipment, and will most likely work fine with any IPsec capable devices encountered in other networks. Connecting devices from two different vendors can be troublesome regardless of the vendors involved because of configuration differences between vendors, in some cases bugs in the implementations, and the fact that some of them use proprietary extensions. Some examples are provided at the end of this chapter for several common Cisco devices.

To configure an IPsec tunnel between pfSense and a device from another vendor, the primary concern is to ensure that the phase 1 and 2 parameters match on both sides. For the configuration options on pfSense, where it allows multiple options to be selected, only select one of those options and ensure the other side is set the same. The endpoints will attempt to negotiate a compatible option when multiple options are selected, however that is frequently a source of problems when connecting to third party devices. Configure both ends to what are believed to be matching settings, then save and apply the changes on both sides.

Once the settings match on both ends of the tunnel, attempt to pass traffic over the VPN to trigger its initiation then check the IPsec logs on both ends to review the negotiation. Depending on the situation, the logs from one end may be more useful than those from the opposite end, so it is good to check both and compare. The pfSense side typically provides better information in some scenarios, while on other occasions the other device provides more useful logging. If the negotiation fails, determine whether it was phase 1 or 2 that failed and thoroughly review the settings accordingly, as described in IPsec Troubleshooting. The side that is initiating often cannot see why, so check the logs on the responding side first.

Terminology Differences

Another frequent source of failures is differences in terminology between vendors. Here are a few common things to look out for:

Policy-Based VPN/IPsec:
 The type of IPsec used by pfSense. Policies are defined, such as Phase 2 entries, which control traffic entering the tunnel.
Route-Based VPN/IPsec:
 This style of IPsec is not supported by pfSense, but some vendors or equipment may require it. There is an IPsec interface which routes similar to other interfaces and obeys the routing table, rather than relying on policies.
S2S or L2L:Short for Site-to-Site or LAN-to-LAN, distinguished from a mobile client style VPN.
Perfect Forward Secrecy (PFS):
 Some vendors have different controls for PFS. It may only be a toggle which uses the same value as the Phase 1 DH Group, others label it with full text or the acronym, others label it DH Group.
Transform Set:On Cisco devices, a set of parameters that define Phase 2 handling such as encryption and hash algorithms.
ISAKMP Policy:On Cisco devices, a set of parameters that define Phase 1 handling such as authentication, encryption, and hash algorithms, and others.
Proposals:On Juniper and Fortigate, sets of options that define parameters for Phase 1 (IKE) or Phase 2 (IPsec) handling.
NAT Exemption or no-nat:
 On Juniper and Cisco, exceptions to NAT that must be made to ensure that traffic traversing a VPN does not have NAT applied.
Lifebytes or Traffic Lifetime:
 Limits on the amount of traffic sent over a VPN before it renegotiates. Not currently supported in the pfSense GUI, if present on a remote device it may need to be disabled.
Encryption Domain or Policy:
 A network definition used in Phase 2 to control which traffic will be handled by IPsec.

Third Party Firewall Examples

The following examples are for third-party Cisco devices running a hypothetical tunnel to a slightly different example from the one in this chapter. The address details are the same as Site-to-Site but there are some differences in these examples:

Phase 1 and Phase 2 Encryption:
 3DES
Phase 1 and Phase 2 Hash:
 SHA1
Phase 1 Lifetime:
 86400

Cisco PIX OS 6.x

The following configuration is for a Cisco PIX running on 6.x as Site B from the example site-to-site configuration earlier in the chapter.

sysopt connection permit-ipsec
isakmp enable outside

!--- Phase 1
isakmp identity address
isakmp policy 1 encryption 3des
isakmp policy 1 hash sha
isakmp policy 1 group 2
isakmp policy 1 lifetime 86400
isakmp policy 1 authentication pre-share
isakmp key aBc123%XyZ9$7qwErty99 address 198.51.100.3 netmask 255.255.255.255 no-xauth no-config-mode

!--- Phase 2
crypto ipsec transform-set 3dessha1 esp-3des esp-sha-hmac
access-list PFSVPN permit ip 10.5.0.0 255.255.255.0 10.3.0.0 255.255.255.0
crypto map dyn-map 10 ipsec-isakmp
crypto map dyn-map 10 match address PFSVPN
crypto map dyn-map 10 set peer 198.51.100.3
crypto map dyn-map 10 set transform-set 3dessha1
crypto map dyn-map 10 set security-association lifetime seconds 3600
crypto map dyn-map interface outside

!--- no-nat to ensure it routes via the tunnel
access-list nonat permit ip 10.5.0.0 255.255.255.0 10.3.0.0 255.255.255.0
nat (inside) 0 access-list nonat

Cisco PIX OS 7.x, 8.x, and ASA

Configuration on newer revisions of the PIX OS and for ASA devices is similar to that of the older ones, but has some significant differences. The following example would be for using a PIX running OS version 7.x or 8.x, or an ASA device, as Site B in the site-to-site example earlier in this chapter.

crypto isakmp enable outside

!--- Phase 1
crypto isakmp policy 10
  authentication pre-share
  encryption 3des
  hash sha
  group 2
  lifetime 86400

tunnel-group 198.51.100.3 type ipsec-l2l
tunnel-group 198.51.100.3 ipsec-attributes pre-shared-key aBc123%XyZ9$7qwErty99

!--- Phase 2
crypto ipsec transform-set 3dessha1 esp-3des esp-sha-hmac
access-list PFSVPN extended permit ip 10.5.0.0 255.255.255.0 10.3.0.0 255.255.255.0
crypto map outside_map 20 match address PFSVPN
crypto map outside_map 20 set peer 198.51.100.3
crypto map outside_map 20 set transform-set 3dessha1
crypto map outside_map interface outside

!--- no-nat to ensure it routes via the tunnel
access-list nonat extended permit ip 10.5.0.0 255.255.255.0 10.3.0.0 255.255.255.0
nat (inside) 0 access-list nonat

Cisco IOS Routers

This shows a Cisco IOS-based router as Site B from the example site- to-site configuration earlier in the chapter.

!--- Phase 1
crypto isakmp policy 10
  encr 3des
  authentication pre-share
  group 2
crypto isakmp key aBc123%XyZ9$7qwErty99 address 198.51.100.3 no-xauth

!--- Phase 2
access-list 100 permit ip 10.3.0.0 0.0.0.255 10.5.0.0 0.0.0.255
access-list 100 permit ip 10.5.0.0 0.0.0.255 10.3.0.0 0.0.0.255
crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac
crypto map PFSVPN 15 ipsec-isakmp
  set peer 198.51.100.3
  set transform-set 3DES-SHA
  match address 100

!--- Assign the crypto map to the WAN interface
interface FastEthernet0/0
  crypto map PFSVPN

!--- No-Nat so this traffic goes via the tunnel, not the WAN
ip nat inside source route-map NONAT interface FastEthernet0/0 overload
access-list 110 deny   ip 10.5.0.0 0.0.0.255 10.3.0.0 0.0.0.255
access-list 110 permit ip 10.5.0.0 0.0.0.255 any
route-map NONAT permit 10
  match ip address 110