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.
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.
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
- Phase 1 and Phase 2 Hash
- Phase 1 Lifetime
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