Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Routed IPsec on pfSense 2.4.4 - pfSense Hangout June 2018

Slides for the June 2018 pfSense Hangout video

  • Identifiez-vous pour voir les commentaires

Routed IPsec on pfSense 2.4.4 - pfSense Hangout June 2018

  1. 1. Routed IPsec on pfSense 2.4.4 June 2018 Hangout Jim Pingle
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Conclusion ● Questions? ● Ideas for hangout topics? Post on forum, Reddit, etc ● Hangout format changing soon, Fuze is discontinuing this service!

×