Slides for the June 2018 pfSense Hangout video

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!