Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Advanced OpenVPN Concepts
pfSense 2.4/2.3.3
February 2017 Hangout
Jim Pingle
About this Hangout
● Primarily a presentation and discussion, not a complete demonstration for each topic
● Many of these ...
Project Notes
●
pfSense 2.3.3 Released - https://blog.pfsense.org/?p=2325
– Primarily security patches and bug fixes
– May...
Improvements in
OpenVPN 2.4/pfSense 2.4
● Added AEAD ciphers (AES-GCM)
– Can be accelerated by AES-NI
– Usable in SSL/TLS ...
Improvements in
OpenVPN 2.4/pfSense 2.4
● New compression option syntax, old syntax deprecated but not removed
– Added LZ4...
Improvements in OpenVPN
● Some changes are new, but made it into 2.3.3
● RADIUS Auth now sends proper NAS-Port-Type, NAS-P...
OpenVPN Device Mode
● Tun device
– OSI Layer 3, IPv4 and IPv6
● Example: Lowest level available is IP address to IP addres...
OpenVPN Tunnel Networks
● Shared Key
● SSL/TLS - /30 Tunnel Network
● SSL/TLS in tun mode, /24 or similar, topology
net30
...
Shared Key Tunnel Networks
● Shared Key always uses two IP addresses, regardless
of the specified subnet size
● Creates a ...
SSL/TLS in tun net30 Mode
● Old default setting, not default behavior now
● Can handle multiple clients
● Can push setting...
SSL/TLS Subnet Style
● Tun with subnet topology is the current default
● SSL/TLS in tap mode and tun with topology subnet ...
VPN Routing
● Three different types:
– Static Routing – What most people are used to
– Policy Routing – Handled via firewa...
VPN Routing - Static
●
Most common kind, used by nearly everyone
●
Routes are present in the system routing table
●
Routes...
VPN Routing – Policy Routing
● Requires assigning the OpenVPN interface,
which creates a dynamic gateway
● Routes are not ...
VPN Routing - Dynamic
● Routes are present in the routing table but they
are NOT configured in OpenVPN directly
● Routes a...
Assigning OpenVPN Interfaces
● Enables additional configuration possibilities for handling
traffic to/from the VPN
● Assig...
Assigning OpenVPN Interfaces
● Gateway added by the assignment action can:
– Be used for policy routing, for example:
● Se...
Assigning OpenVPN Interfaces
● Firewall tab added by assignment allows more fine-grained control of
traffic and the use of...
Assigning OpenVPN Interfaces
● Perform the assignment action from LAN or WAN, not over
this VPN
● Interfaces > Assignments...
Multi-WAN Tactics
● Using multiple remote statements (built into
OpenVPN)
● Gateway group failover (Interface = GW Group)
...
Multi-WAN Tactics
Multiple Remote Statements
●
Useful if the server has multiple WANs
●
Can work with static key or SSL/TL...
Multi-WAN Tactics
Gateway Group Failover
●
Use a failover Gateway Group as the Interface for the client or server
●
Only a...
Multi-WAN Tactics
Policy Routing
● Useful for Multi-WAN clients and servers, depending on scenario
● Can only be used with...
Multi-WAN Tactics
Dynamic Routing
●
Routing protocol daemon (e.g. Quagga) must run on all nodes
●
Useful for Multi-WAN ser...
OSPF / Dynamic Routed VPN
● Can be used for failover or to link multiple sites together
● Requires Multicast
● Static key ...
OSPF (cont'd)
● Client side: Setup two clients, one for each server, each on
a separate WAN. (A1-B1, A2-B2)
● May be overk...
OSPF - Quagga
● Install and configure the Quagga package on both sides
– Assigning interfaces is optional
● Interfaces tab...
Single server, multiple WANs
Server
WAN1 x.x.x.x - Port 1194 to Localhost:1194
WAN2 y.y.y.y - Port 1194 to Localhost:1194
...
Single server, multiple WANs
●
Option 1 (2.3.x or 2.4)
– Choose Localhost as the OpenVPN server Interface
– Port forward f...
Multiple Servers, Multiple WANs
Server
WAN1 x.x.x.x
OpenVPN Server #1 Port 1194
Tunnel Network: 10.0.8.0/30
Client
WAN2 y....
Multiple Servers, Multiple WANs
● Remote access, routing protocol or policy routed style only
● Cannot be used for traditi...
Client-Specific Overrides
● Server list – Select server(s) this override will be active for (None=All)
– Static address as...
Servers Can Be Clients
● Servers can also be clients, similar to IPsec
● Static Key or SSL/TLS /30 only
● Set the local po...
Share LAN Subnet
●
While not bridged, tun can use a portion of LAN subnet
●
We don’t typically recommend this, but it can ...
RA TAP Bridge VPN
● We do not recommend bridging to LAN, but some rare cases benefit from it
– e.g. devices that are unabl...
Random Tips
● Share port between OpenVPN and a web server
– “port-share x.x.x.x 443”
– VPN traffic handled by OpenVPN, all...
Conclusion
● Additional References:
– Oct 2016 Hangout on OpenVPN as a WAN (VPN
Providers)
– September/October 2015 Hangou...
Upcoming SlideShare
Loading in …5
×
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

2

Share

Download to read offline

Advanced OpenVPN Concepts on pfSense 2.4 & 2.3.3 - pfSense Hangout February 2017

Download to read offline

Slides for the February 2017 pfSense Hangout video

Related Books

Free with a 30 day trial from Scribd

See all

Advanced OpenVPN Concepts on pfSense 2.4 & 2.3.3 - pfSense Hangout February 2017

  1. 1. Advanced OpenVPN Concepts pfSense 2.4/2.3.3 February 2017 Hangout Jim Pingle
  2. 2. About this Hangout ● Primarily a presentation and discussion, not a complete demonstration for each topic ● Many of these concepts are useful with Multi-WAN, but also in Remote Access setups or with VPN providers for Internet access ● Project Notes ● OpenVPN Improvements in both pfSense 2.4 and OpenVPN 2.4 ● OpenVPN Device Modes ● Tunnel Network Behavior ● Routing Methods ● Assigning OpenVPN Interfaces ● Multi-WAN/Redundancy tactics ● Using Client-Specific Overrides ● Sharing the LAN Subnet ● Remote Access Tap Bridge ● Tips and Tricks
  3. 3. Project Notes ● pfSense 2.3.3 Released - https://blog.pfsense.org/?p=2325 – Primarily security patches and bug fixes – May be the last pfSense 2.3.x point release, future 2.3.x releases will be smaller errata updates ● pfSense 2.3.x will be maintained for quite some time after pfSense 2.4-RELEASE since NanoBSD and i386 are not available on pfSense 2.4. Current plan is for 1yr of 2.3 updates/support after 2.4-RELEASE ● Translations on 2.4 are really taking off! - https://blog.pfsense.org/?p=2275 – Now using Zanata – Several languages nearly complete or being worked on heavily ● Chinese (Simplified, China), Chinese (Taiwan), Spanish, German (Germany), Portuguese (Brazil), Russian, Turkish ● Clock Signal Component Issue – All of the info we have is on the blog, will be updated: https://blog.pfsense.org/?p=2297 ● Public Slack channel available – https://www.reddit.com/r/PFSENSE/comments/5sp70b/join_netgate_pfsense_on_slack/ ● Let’s Encrypt (ACME) package now available on pfSense 2.4, 2.3.3, and 2.3.2_1 – Many different methods of updating including nsupdate, ftp webroot, many DNS providers, standalone – Can be used by the GUI itself or for packages such as HAProxy for hosted sites ● @pfsense passed 10,000 followers on Twitter ● GET to POST conversion on 2.4 – https://blog.pfsense.org/?p=2308 – For security, preventing CSRF, protecting against accidental changes
  4. 4. Improvements in OpenVPN 2.4/pfSense 2.4 ● Added AEAD ciphers (AES-GCM) – Can be accelerated by AES-NI – Usable in SSL/TLS modes (not shared key) – Faster because AES-GCM also does auth, no need for separate auth algo ● Control Channel / TLS Encryption as optional Key Usage Type – Protects the contents of the control channel – Provides protocol obfuscation – May be able to bypass sites/locations that filter OpenVPN or SSL traffic ● Data Channel Ciphers via Negotiable Crypto Parameters (NCP) – Clients and servers can negotiate and agree on a crypto algorithm from a defined list – Backward compatible for older clients and servers to use one set value from the list ● ECDH options to use in place of DH parameters during Key Exchange – Also contains an option for the curve used
  5. 5. Improvements in OpenVPN 2.4/pfSense 2.4 ● New compression option syntax, old syntax deprecated but not removed – Added LZ4 – Faster decompression, but does not compress as much – Compression can be pushed from server ● New binding options for IPv4+6 in a single instance – Has to bind to all interfaces when using this mode – “multihome” keyword that checks original destination address & replies from same – Hostnames used in client instances for the server address (or remote statements) will try all addresses returned for the hostname (A and AAAA) ● Server can push IPv6 DNS ● IPv6 support in status output and widget (finally!) ● “tun-ipv6” deprecated, IPv6 now always enabled ● CRL verification is handled via OpenSSL now and NOT internally, may result in different behavior ● Improved help text on Client-Specific Overrides ● Fixed issues with OpenVPN on dynamic and tunneling interfaces
  6. 6. Improvements in OpenVPN ● Some changes are new, but made it into 2.3.3 ● RADIUS Auth now sends proper NAS-Port-Type, NAS-Port, and NAS-Identifier values ● “No Preference and Adaptive Compression Disabled” option for handling clients compiled without LZO ● Added a workaround to push a setting that blocks non-VPN DNS on Windows 10 to prevent DNS Leaks ● Improved handling of chained/intermediate CA entries – If you had older bundled CA entries w/Root+Intermediate, re-import them separately ● OpenVPN widget now updates dynamically ● Server list now displays more information about each instance ● Now properly authenticates for servers with special characters like “&” in their name on pfSense ● Added IPv6 tunnel network field to OpenVPN Client-Specific Overrides ● OpenVPN 2.4 Windows Client no longer needs Administrator privileges – Available on pfSense 2.4, 2.3.3, and 2.3.2_1 via the export package
  7. 7. OpenVPN Device Mode ● Tun device – OSI Layer 3, IPv4 and IPv6 ● Example: Lowest level available is IP address to IP address – Most common and compatible across multiple platforms ● Ex: iOS and Android clients generally only support tun mode – Less per-packet overhead than tap – Treated as a point-to-point interface ● Tap device – OSI Layer 2 (802.3) ● Example: Lowest level available is MAC address to MAC address – Can be bridged to another interface – Will carry broadcast, multicast, and related protocols (e.g. ARP, DHCP) – More per-packet overhead because of the need to carry extra L2 info
  8. 8. OpenVPN Tunnel Networks ● Shared Key ● SSL/TLS - /30 Tunnel Network ● SSL/TLS in tun mode, /24 or similar, topology net30 ● SSL/TLS in tun with topology subnet or tap mode
  9. 9. Shared Key Tunnel Networks ● Shared Key always uses two IP addresses, regardless of the specified subnet size ● Creates a point-to-point interface in the OS ● Both client and server use the same interface and IP addresses to reach each other ● Only one client per server can connect ● Cannot push settings to connecting clients ● SSL/TLS with a /30 tunnel network behaves the same as Shared Key
  10. 10. SSL/TLS in tun net30 Mode ● Old default setting, not default behavior now ● Can handle multiple clients ● Can push settings to clients ● SSL/TLS w/tun setup and a larger subnet (/24) ● Each client is assigned a /30 slice of the whole tunnel network – Each client consumes four IP addresses (null route, server, client, broadcast) – 63 clients in /24 ● Client-specific overrides can set static addresses using /30 notation ● IPv6 still uses subnet topology even when set this way ● Client /30 subnets handled inside OpenVPN and not exposed to the OS – Prevents broadcast and multicast from working between server and all clients or between two different clients ● For clients to reach each other, need to push route for tunnnel net + client-to-client
  11. 11. SSL/TLS Subnet Style ● Tun with subnet topology is the current default ● SSL/TLS in tap mode and tun with topology subnet behave similarly. ● Can handle multiple clients ● Can push settings to clients ● Groups clients into one large actual subnet rather than sets of separate networks. ● Assigns one IP address per client out of the tunnel network – Less waste (253 clients in /24) ● Client-specific overrides can set static addresses using same bitmask as server ● Broadcast and Multicast can be used between clients and server – Primarily for tap, some tasks will fail w/tun because it is a point-to-point interface ● Can have quirks with some older clients
  12. 12. VPN Routing ● Three different types: – Static Routing – What most people are used to – Policy Routing – Handled via firewall rules – Dynamic – Handled by a routing Daemon
  13. 13. VPN Routing - Static ● Most common kind, used by nearly everyone ● Routes are present in the system routing table ● Routes are managed by individual OpenVPN instances – NEVER manually add static routes under System > Routing for OpenVPN instances ● Routes are added to the firewall routing table for networks specified in Remote IPv4 Networks, Remote IPv6 Networks – This tells the operating system to send traffic for these networks to a specific OpenVPN instance ● For SSL/TLS in tun mode for multiple sites, iroute is used in Client-Specific Overrides to route back to the proper client – This tells OpenVPN which certificate identifies a specific route destination ● If using an SSL/TLS multi-site network, routes can be pushed to clients via the Local Network boxes – This instructs clients to send traffic for these networks across OpenVPN
  14. 14. VPN Routing – Policy Routing ● Requires assigning the OpenVPN interface, which creates a dynamic gateway ● Routes are not present in the routing table ● Routes managed by pf in firewall rules similar to Multi-WAN ● Can use gateway groups across multiple VPNs or between VPNs and WANs ● Inbound/return traffic handled via reply-to
  15. 15. VPN Routing - Dynamic ● Routes are present in the routing table but they are NOT configured in OpenVPN directly ● Routes are managed by an add-on package daemon such as Quagga for OSPF ● Routing daemon can change routes quickly depending on configuration & conditions
  16. 16. Assigning OpenVPN Interfaces ● Enables additional configuration possibilities for handling traffic to/from the VPN ● Assignment automatically adds gateways for IPv4 and IPv6 ● Adds firewall rule tab for rules specific to only this VPN ● Allows the interface to be selected for use elsewhere in the GUI ● Outbound NAT, port forwards (VPN providers) can be set for only this VPN, rather than all OpenVPN instances collectively
  17. 17. Assigning OpenVPN Interfaces ● Gateway added by the assignment action can: – Be used for policy routing, for example: ● Send client X over VPN, but not others ● Send all HTTP traffic over VPN, but nothing else – Be used in gateway groups ● Failover between multiple VPNs or between VPN and WAN, or a mix. – Automatically add reply-to on interface tab rules – Do NOT use for static routes!
  18. 18. Assigning OpenVPN Interfaces ● Firewall tab added by assignment allows more fine-grained control of traffic and the use of reply-to ● reply-to in pf specifies a gateway for return routing: Return traffic for connections entering an interface exits the same interface ● With reply-to in place you can route public subnets, use Port forwards, or use 1:1 NAT across VPN when the traffic source is ‘any’ ● For assigned OpenVPN interface tab to work, traffic must NOT match OpenVPN tab rules! – Traffic must only match rules on the assigned interface tab, no others – Do not block, alter sources so they do not match – Alternately, assign all OpenVPN instances and remove all OpenVPN tab rules – Rules are processed Floating -> Groups (OpenVPN tab) -> Interface tab rules
  19. 19. Assigning OpenVPN Interfaces ● Perform the assignment action from LAN or WAN, not over this VPN ● Interfaces > Assignments ● Select VPN from drop-down, click Add – Creates a new OPTx interface – This disrupts the VPN, you must restart the VPN after the next step! ● Interfaces > OPTx – Enable, change name, IP type of None! Save/Apply – Edit/save VPN after applying these settings
  20. 20. Multi-WAN Tactics ● Using multiple remote statements (built into OpenVPN) ● Gateway group failover (Interface = GW Group) ● Policy Routing ● Dynamic Routing with OSPF
  21. 21. Multi-WAN Tactics Multiple Remote Statements ● Useful if the server has multiple WANs ● Can work with static key or SSL/TLS ● Using multiple remote statements is built into OpenVPN ● Additional remote statements are added into advanced options – Ex: remote x.x.x.x YYYY udp (x.x.x.x = add’l server, YYYY = port) ● VPN is down for 60+ seconds before switch – OpenVPN’s ping timeout settings default to 60s and it must notice that the server is dead before it will switch ● Any VPN disconnect will try the next remote ● Will not fail back automatically, will keep using the same server until it is disrupted ● If the client side is also Multi-WAN, add manual static route to send one remote out an alternate WAN, or default gateway switching ● Good option if: – Server has multiple WANs – Failover time is not critical – There is no server preference – There is no need for fail-back – Disaster Recovery without BGP (could fail to DR site)
  22. 22. Multi-WAN Tactics Gateway Group Failover ● Use a failover Gateway Group as the Interface for the client or server ● Only active on one WAN at a time ● Useful for Clients with Multi-WAN ● Can work with static key or SSL/TLS ● Can be used with Multi-WAN servers, but we do not recommend this as it can be slow/troublesome – Better to bind to Localhost and use port forwards or bind to all w/multihome on 2.4 – Covered later ● Time to change depends on gateway monitoring settings, could be 10-60+ seconds ● Will fail back, but VPN will be disrupted ● Server use requires one of: – Dynamic DNS on pfSense set to use the same gateway group, client connects to that host – Multiple remote statements on the client so the client will attempt the other WAN, but only one will work at a time. ● Good option if: – Failover time is not critical – State killing on gateway failure is enabled – The VPN must fail back to the preferred WAN when it recovers – Other options are too complex or are not viable
  23. 23. Multi-WAN Tactics Policy Routing ● Useful for Multi-WAN clients and servers, depending on scenario ● Can only be used with Point-to-Point VPNs (Static Key or SSL/TLS with /30) ● Can do connection-based Load Balancing or Failover (not aggregation) using Gateway Groups ● Tunnels up at all times on all WANs – One server and client per WAN ● Routes should not be added to all of the clients and servers – If the firewall itself must reach across the VPN, add route to ONE instance since it will not balance ● Needs only keys, encryption/auth, compression settings, and unique tunnel networks ● Assign all VPN interfaces on server and client sides ● Failover time depends on gateway settings ● When the first WAN recovers, new connections will use it, but existing connections left alone ● Firewall rules – OpenVPN tab rules MUST NOT MATCH this traffic (needs reply-to) ● Outbound NAT may also help, but could introduce other problems. Reply-to is best – Place rules to pass traffic on each assigned interface tab – Add LAN rules to top to match destination with gateway group chosen ● Good option if: – Failover time is not critical – Small number of sites (2-6) due to number of required steps – Load balancing is required for additional bandwidth – Partial fail-back is OK
  24. 24. Multi-WAN Tactics Dynamic Routing ● Routing protocol daemon (e.g. Quagga) must run on all nodes ● Useful for Multi-WAN servers and clients ● Requires point-to-point VPNs (SK or /30), or tap mode SSL/TLS ● One instance per WAN, SK/30 need one server per WAN & per client ● Very low time to change, could be only a few seconds ● Fails back automatically with little or no loss of connectivity ● Requires more complicated setup of routing protocols ● Tunnels up at all times on all WANs ● Good option if: – Failover time is critical – The added management burden is not overly cumbersome
  25. 25. OSPF / Dynamic Routed VPN ● Can be used for failover or to link multiple sites together ● Requires Multicast ● Static key or /30 SSL/TLS preferred, but works with SSL/TLS tap mode – Does not work w/topology subnet because Quagga reads that tun is point-to- point and will not allow more than one neighbor ● Server side: Use two unique server instances (per client site for SK or /30), each on separate ports/WANs – If using P2P SSL/TLS tap, add “client-to-client” to server advanced options or remotes cannot reach each other ● Use distinct, non-overlapping tunnel networks (e.g. 10.0.8.0/30 and 10.0.9.0/30) ● Do NOT put routes in remote network boxes! OSPF will handle routes
  26. 26. OSPF (cont'd) ● Client side: Setup two clients, one for each server, each on a separate WAN. (A1-B1, A2-B2) ● May be overkill but for complete WAN and path redundancy, you could use four connections (A1-B1, A1-B2, A2-B1, A2- B2), or mix this with a multiple remote statement method ● Ensure OpenVPN tab firewall rules pass OSPF traffic, allow each side to ping the remote end's tunnel network address – Do not filter OSPF on destination as it uses multicast ● Check that the VPNs come online and can ping in both directions to/from the tunnel network IPs – NOT a LAN-to-LAN test yet
  27. 27. OSPF - Quagga ● Install and configure the Quagga package on both sides – Assigning interfaces is optional ● Interfaces tab in Quagga – Add VPN interfaces to quagga, give one lower metric (e.g. preferred WAN metric 10, second WAN 20) – Add local/LAN interfaces to quagga as passive ● Global settings tab in Quagga – Create a random master password – Set the area (typically 0.0.0.0 or 0.0.0.1) – Set the router ID (typically this firewall's LAN IP) ● After configuring both sides in this way, check the status tab, it should show a full peering/neighboring between the nodes ● Test a LAN to LAN ping
  28. 28. Single server, multiple WANs Server WAN1 x.x.x.x - Port 1194 to Localhost:1194 WAN2 y.y.y.y - Port 1194 to Localhost:1194 OpenVPN Server #1 Localhost:1194 Tunnel Network: 10.0.8.0/24 Remote Network: 192.168.2.0/24 Client OpenVPN Client #1 Server IP x.x.x.x:1194 Tunnel Network: 10.0.8.0/24 Remote Network: 192.168.1.0/24 Advanced: remote y.y.y.y 1194;
  29. 29. Single server, multiple WANs ● Option 1 (2.3.x or 2.4) – Choose Localhost as the OpenVPN server Interface – Port forward from WANs to Localhost ● Option 2 (2.4+) – Choose any as the OpenVPN server Interface – Select UDP IPv4 and IPv6 on all Interfaces (multihome) for the Protocol ● Remote access VPNs – OpenVPN client export package supports port forward method automatically – Select one of the automatic options in the “Host Name Resolution” drop-down – Can be used for Multi-WAN or multiple ports on the same WAN ● Site to Site VPN – Static Key or SSL/TLS (Site-to-Multisite) uses a second remote statement in advanced options – Static route one IP on each WAN if desired ● Alternate tactic: DNS trickery – Dynamic DNS + Multi-WAN, or round-robin DNS – Quite slow, due to DNS TTLs and propagation time
  30. 30. Multiple Servers, Multiple WANs Server WAN1 x.x.x.x OpenVPN Server #1 Port 1194 Tunnel Network: 10.0.8.0/30 Client WAN2 y.y.y.y OpenVPN Server #2 Port 1195 Tunnel Network: 10.0.8.4/30 OpenVPN Client #1 Server IP: x.x.x.x:1194 Tunnel Network: 10.0.8.0/30 OpenVPN Client #2 Server IP: y.y.y.y:1195 Tunnel Network: 10.0.8.4/30
  31. 31. Multiple Servers, Multiple WANs ● Remote access, routing protocol or policy routed style only ● Cannot be used for traditional site-to-site (routes conflict) ● Assumes server and client have the same number of WANs ● One instance per WAN ● Bind directly to each WAN ● Must use different tunnel networks ● Other settings can be the same (including CA/Certs, TLS key, auth settings, etc) ● If the client has only one WAN: – Use multiple remote statements OR – Pin up both tunnels if an alternate routing setup is used
  32. 32. Client-Specific Overrides ● Server list – Select server(s) this override will be active for (None=All) – Static address assignments don’t make sense in this case ● Matched by name (CN or username) – Certs only: Use common name – User Auth or Cert+User: Use username – Use “DEFAULT” for default override settings if needed ● Set static address via Tunnel Network setting – Tun subnet or tap specify address and use mask from server – Tun net30 specify /30 – On 2.4, if the VPN has IPv4 and IPv6 enabled, to set static address you MUST define static for both IPv4 and IPv6 ● IPv4/6 “Local” Networks – Server-side networks for which routes will be pushed to this client ● IPv4/6 “Remote” Networks – Client-side networks that OpenVPN can reach via this client connection (iroute) – These networks should also be listed in remote networks on the server itself ● Put “ccd-exclusive” in server advanced opts to deny access to clients that do not match an override – This can help prevent unworkable clients from connecting (e.g. Multi-Site SSL/TLS that would not function w/o override+iroutes)
  33. 33. Servers Can Be Clients ● Servers can also be clients, similar to IPsec ● Static Key or SSL/TLS /30 only ● Set the local port on the client to a static port (e.g. 1194) ● Allow traffic on client WAN firewall rules to that port ● Add a remote statement to the server's advanced options so it will initiate ● Or setup both sites as servers + add remote statements
  34. 34. Share LAN Subnet ● While not bridged, tun can use a portion of LAN subnet ● We don’t typically recommend this, but it can work around some subnet-related issues ● Broadcast/multicast cannot work, it is not a bridge ● Pick an unused CIDR-aligned part of the LAN subnet (outside DHCP pool) ● Add a Proxy ARP VIP for that section of LAN so traffic will come to the firewall ● Use that CIDR block as the tunnel network for the VPN ● Ex: 10.6.0.0/24 LAN, 10.6.0.100-200 DHCP, 10.6.0.224/28 for OpenVPN & Proxy ARP VIP
  35. 35. RA TAP Bridge VPN ● We do not recommend bridging to LAN, but some rare cases benefit from it – e.g. devices that are unable to route or require broadcast or multicast to function ● To make a tap bridge – Make VPN w/o tunnel network ● Set to tap ● Set Bridge DHCP & select LAN (if it should pull DHCP from LAN) – Assign VPN interface – Create bridge under Interfaces > Assignments, Bridges tab – Restart VPN ● In tap bridge w/o tunnel network, pushing routes will not work automatically – Manually add routes in advanced options using: ● push “route x.x.x.0 255.255.255.0 y.y.y.y”; – Adjust target/mask – y.y.y.y = gateway addr on LAN
  36. 36. Random Tips ● Share port between OpenVPN and a web server – “port-share x.x.x.x 443” – VPN traffic handled by OpenVPN, all other traffic passed to server behind – Acts as a proxy, so source address is lost – Requires TCP, reduces performance ● On pfSense 2.3.3 and 2.4, OpenVPN will drop packets destined for the server itself that arrive over OpenVPN. To allow this, add “allow-recursive-routing” to client config/options ● “reneg-sec” option will force client to reconnect after a specified period of time
  37. 37. Conclusion ● Additional References: – Oct 2016 Hangout on OpenVPN as a WAN (VPN Providers) – September/October 2015 Hangouts on Remote Access VPNs ● Questions? ● Ideas for hangout topics? Post on forum, comment on the blog posts, Reddit, etc
  • IanLi1

    Jun. 27, 2020
  • shock143

    Sep. 8, 2019

Slides for the February 2017 pfSense Hangout video

Views

Total views

9,463

On Slideshare

0

From embeds

0

Number of embeds

3

Actions

Downloads

121

Shares

0

Comments

0

Likes

2

×