Slides for the February 2017 pfSense Hangout video

1. Advanced OpenVPN Concepts
pfSense 2.4/2.3.3
February 2017 Hangout
Jim Pingle

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Multi-WAN Tactics
● Using multiple remote statements (built into
OpenVPN)
● Gateway group failover (Interface = GW Group)
● Policy Routing
● Dynamic Routing with OSPF

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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