Routed IPsec allows IPsec tunnels to be configured and used like interfaces, allowing routing and dynamic routing protocols to be used. It utilizes Virtual Tunnel Interfaces (VTI) in FreeBSD. Benefits include more natural traffic flow respecting routing, no need for extensive policy definitions, and integration with other routed IPsec implementations. It is available in pfSense snapshots and 2.4.4, with some limitations around reply-to and NAT. Configuration involves choosing a transit network, setting up Phase 1 and 2 with the VTI mode, assigning the ipsec interface, and setting routing or firewall rules. Examples of static routing, dynamic routing with FRR, and policy-based routing were provided.

1. Routed IPsec on pfSense 2.4.4
June 2018 Hangout
Jim Pingle

2. About this Hangout
● Netgate News
● What is routed IPsec?
● Why use routed IPsec?
● Limitations
● Availability
● Configuring Routed IPsec
● Static Routing Example
● Dynamic Routing Example

3. Netgate News
● TNSR is now available on AWS!
– https://www.netgate.com/blog/the-behemoth-router-is-here.html
● pfSense 2.4.3-p1 and 2.3.5-p2 released!
– https://www.netgate.com/blog/pfsense-2-4-3-release-p1-and-2-3-5-release-p2-now-available.html
– OpenSSL security updates and other security fixes, plus other misc bug fixes
● pfSense 2.4.4 is in development
– Latest variants of Meltdown/Spectre, plus Lazy FP State Restore are addressed in snapshots
●
https://www.netgate.com/blog/pfsense-software-and-cve-2018-8897.html
– FreeBSD 11.2 base, Routed IPsec, PHP 7.2, hybrid ISO/Memstick installer image
● New forum at https://forum.netgate.com
– https://www.netgate.com/blog/introducing-the-netgate-forum.html
– Uses NodeBB, GDPR compliant, Much better overall browser and mobile experience

4. Netgate News
● Documentation Wiki converted to Sphinx
– https://www.netgate.com/docs/pfsense/
– https://www.netgate.com/blog/moving-the-pfsense-documentation-to-github.html
– Easier to take contributions via Github PRs
– No worries about wiki spam
– Contributions can be reviewed before they are accepted rather than cleaned up after
●
pfSense now available on to QNAP Virtualization Station users
– https://www.netgate.com/blog/pfsense-now-available-to-all-qnap-virtualization-station-users.html
●
Updates to our Privacy Policy
– https://www.netgate.com/blog/updates-to-our-privacy-policy.html
● Netgate was at BSDCan earlier this month

5. What is routed IPsec?
● Route-based IPsec, which is different from a traditional tunnel (policy-based)
● Uses Virtual Tunnel Interfaces (VTI)
● In FreeBSD since 11.1 via if_ipsec(4)
● Works with both IKEv1 and IKEv2
● Sets up an ipsecX interface at the OS level, rather than using enc0
● This ipsecX interface can be assigned and used like other interfaces
– Works similar to an assigned OpenVPN interface
● An automatic gateway entry is created when assigned
● Usable for routing, NAT, etc
● Can be used for static routes, policy routes, dynamic routing
● Completely optional, traditional policy-based IPsec tunnels still work

6. Why use routed IPsec?
● Traffic flows in a more natural, logical way, respecting traditional routing practices
– Doesn’t rely on kernel magic to catch and direct packets into IPsec!
● No need to define P2s for every network crossing IPsec, only routes!
● Works with other routed IPsec implementations (e.g. TNSR, AWS VPC)
● Can utilize gateways and gateway groups
– Useful for selectively sending traffic across IPsec (e.g. certain Internet destinations)
– Can be used for failover between multiple tunnels
● Dynamic routing (e.g. BGP) for managing routes or failover between multiple IPsec connections
– Multi-WAN, AWS VPC
● IPsec with large numbers of subnets
– No need for numerous P2s, only routes
● Sending traffic to/from the firewall itself across IPsec
– e.g. RADIUS, LDAP, syslog, SNMP, DHCP relay

7. Limitations/Downsides
●
Only optimal if both sides support routed IPsec. Otherwise, it may take some fussing with P2s on the side that
doesn't, and many of the benefits are moot.
– If you have ever used AWS VPC with policy-based IPsec, you may be familiar with this frustration!
●
Instead of managing P2 entries in IPsec, now you have to manage routing in some way (static routes, etc)
– Since this can be dynamic with BGP or OSPF, this is not necessarily a hindrance
●
Traffic shows up on enc0 and the ipsecX interface, must be passed on IPsec tab rules
– Still undergoing testing, but likely means that reply-to will not function
– This also leads to some issues with NAT: Notably, NAT to the interface address works OK, but 1:1 NAT or NAT to an alternate
address does not work.
● Though it behaves similarly, this is not the same as transport mode + GRE
– If the far side requires GRE, you will still need to use transport+GRE
●
New feature, though internal testing has gone well, it still needs testing/feedback from outside users for a variety
of scenarios
– Example: Feedback on interoperability with other routed IPsec platforms such as Juniper

8. Availability
● In snapshots now, will be in pfSense 2.4.4-RELEASE
● Release will be happening soon, in Q3
● Still a work in progress but core functionality is there
● Documentation will be posted in the next week or two

9. Configuring Routed IPsec
● Pick a transit network, typically a /30 network in an unusued subnet
– Similar to choosing a tunnel network for a shared key OpenVPN instance. For this example, we will use
10.8.222.0/30
● Determine other IPsec settings, similar to most other tunnels except for P2 local/remote
– Local IPsec Endpoint: 198.51.100.8
– Remote IPsec Endpoint: 203.0.113.5
– IKE Version: 2
– Auth: PSK, 01234567890123456789012345678901
– P1 Encryption/Hash/DH/Lifetime: AES 256, SHA 256, DH 14, 28800
– Local P2 Endpoint: 10.8.222.1/30 (from transit network above!)
– Remote P2 Endpoint: 10.8.222.2
– P2 Encryption/Hash/PFS/Lifetime: AES 128, SHA 256, PFS 14, 3600

10. Configuring Routed IPsec
● Create an IPsec Phase 1 entry as usual
● Create a Phase 2 entry under this Phase 1, set with…
– Set Mode to Routed (VTI)
– Set Local Network to Network
– Enter 10.8.222.1/30 for the Local Network Address
– Enter 10.8.222.2 for the Remote Network Address
– Add a useful Description
– Set the Proposal settings as needed
● Click Save, then click Apply Changes

11. Configuring Routed IPsec
● Navigate to Interfaces > Assignments
● Pick the new ipsecX interface from the Available Network Ports list
– The IPsec interface will have a number such as ipsec1000 which corresponds to the internal connection ID in
strongSwan, such as con1000. This also lines up with a request id (reqid) of 1000. They are numbered this way
to avoid automatic conflicts/collisions which can happen with lower numbers.
● Click + Add
● Note the new interface name, e.g. OPT1
● Navigate to Interfaces > [New Interface Name]
● Check Enable
● Give the interface a more suitable name using the Description field (e.g. VTI_FOO)
● Leave the IPv4 Configuration Type and IPv6 Configuration Type set to None
● Click Save, then click Apply Changes

12. Configuring Routed IPsec
● Navigate to Firewall > Rules, IPsec tab, add rules to pass
traffic
● At this point the interface is available for use like any other
interface
● A gateway is created automatically and can be used for static
routing, policy routing, etc.
– Visit System > Routing to check it

13. Static Routing Example
● Navigate to System > Routing, Static Routes tab
● Click + Add
● Enter the Destination Network, which is the network on the far side of the tunnel, e.g. 10.7.0.0/24
● Pick the Gateway for the IPsec VTI interface
● Enter a Description
● Click Save
● Repeat for any additional networks to route across the tunnel
● Click Apply Changes when done
● Navigate to Diagnostics > Routes and make sure the route shows up
● Make sure the far side has a similar route for networks on this firewall!
● Alternately, you can setup policy routing rules, such as a rule on LAN to nudge traffic across the tunnel

14. Dynamic Routing Example
●
Install a dynamic routing package that supports the protocol you want
– FRR: Preferred, supports BGP and OSPF
●
Refer to the December 2017 hangout on Dynamic Routing with FRR for more info
– Quagga: supports OSPF, can do manual BGP
– openbgpd: Avoid if possible, but can do BGP
●
Brief FRR Example:
– Install package, Services > FRR Global/Zebra
– Enable, enter a Master Password, set Router ID to LAN IP address, Save
– [BGP] tab, Enable, enter a Local AS for this side (e.g. 65501)
– Enter a list of Networks to Distribute for this side (e.g. LAN subnet, DMZ subnet, etc), save
– Neighbors tab, Add new, enter far side IPsec VTI address (e.g. 10.6.106.2), Remote AS (e.g. 65502), set
Update Source to VTI interface
– Save, then do other side, but swap the local/remote info

15. Policy Routing Example
● Internet provider style example
● Firewall > NAT, Outbound tab
– Switch to Hybrid Outbound NAT
– Add a rule to the top, to NAT on the VTI interface
●
Source is whatever local network(s) you want, e.g. LAN
●
Translated to the Interface address
– Save, Apply
● Firewall > Rules, LAN tab
– Add rules to pass to whatever destination should cross IPsec
●
On these rules, choose the VTI interface gateway
● Alternately, NAT traffic as it exits the remote side
– With static routes, if far side is pfSense it will be included in automatic outbound NAT
– Otherwise, use hybrid outbound NAT and add rule(s) to NAT the routed subnet(s)

16. Conclusion
● Questions?
● Ideas for hangout topics? Post on forum, Reddit, etc
● Hangout format changing soon, Fuze is discontinuing this
service!