Slides for the October 2016 pfSense Hangout video

1. OpenVPN as a WAN
October 2016 Hangout
Jim Pingle

2. About this Hangout
●
Project News
●
Why use OpenVPN as a WAN?
●
VPN Providers (General Info)
● Obtaining Connection Requirements
●
Creating an OpenVPN Client
●
Assigning an OpenVPN instance as an Interface
●
Outbound NAT
●
Firewall Rule Concerns
●
Failover Scenarios
●
Policy Routing and Selective Use
●
Controlling Routing / Firewall-Sourced Traffic in VPN
●
Preventing DNS Leaks
● Inbound Traffic / Port Forwards
●
Server Setup for Host-Your-Own

3. Project News
● 10 Years of production pfSense!
– 1.0-RELEASE was on Oct 13, 2006
– 1.0.1-RELEASE on Oct 29, 2006
● 2.3.2_1 Security/Errata release out now
– OpenSSL patches for recent issues
– Package updates for PHP, libxml, others
– Fixes for misc other bugs
● 2.4 ALPHA snapshots available
● SG-1000 preorders still open
● 24x7 Enterprise-level support is coming soon!

4. Why use OpenVPN as a WAN?
●
Depends on what’s on the other side
– Internet vs Site-to-Site
●
Focusing on Internet in this Hangout, but many aspects apply to both
– You have to trust the other end of the VPN
●
Privacy & Anonymity
– Potentially – Some providers log data, especially free providers / free trials
●
Security
– WAN could be untrusted/weak/compromised
– Traffic from exit node to Internet is still unencrypted (unless the protocol in use is)
●
Bypassing government censorship / restrictions / logging
– Careful not to break the law, however...
●
Alternate region for traffic origination
– Region-locked video streams
– Netflix has cut off many VPNs, is actively cutting off more
●
Researching without revealing true traffic source

5. VPN Providers (General Info)
● Lots of options for VPN Providers, some more trustworthy
than others
● We do not recommend or endorse any particular provider
● Research the company before paying!
– Make sure they offer an OpenVPN option
– Look for logging and data retention policies
– Check exit node locations
– Check feedback/reviews
● Search the pfSense forum for info from other users
● Host your own in a data center / cloud provider / main office

6. Obtaining Connection Requirements
● Each provider is different
● Ideally will have a secure means to download
● Some providers have pfSense guides/info on their site
● Download/copy all required info, such as:
– CA Certificate
– User Certificate & Key (May be omitted if there is a user/pass)
– Credentials (Username/Password, optional if there is a user cert)
– TLS Key (optional, adds extra security)
– Sample Config / Server info
● Hostname/IP address, protocol, port number, encryption, compression

7. Creating an OpenVPN Client
● Import CA Cert
– System > Cert Manager, CAs tab
– Click Add, pick import, give it a name
– Copy/paste Certificate data field from CA cert contents
● Import User Cert (optional if there is a user/pass)
– System > Cert Manager, Certificates tab
– Click Add, pick import, give it a name
– Copy/paste Certificate data and Private Key Data from
user cert/key files given by the VPN provider

8. Creating an OpenVPN Client
● VPN > OpenVPN, Clients tab
● Click Add, pick Peer to Peer (SSL/TLS), pick Interface (e.g. WAN)
● Align options to match server config:
– Protocol, server host/IP address, server port, encryption, hash, compression, etc
● Some options can be left blank in most cases
– Tunnel network is usually dynamically assigned by server
– Remote networks are not usually desirable
● Custom options can typically be omitted but some may be required
– Depends on the provider and options
– Some can be left out like verb, engine, persist, etc
– Some may be necessary if they are not supported in the GUI, like a tls-cipher list
● Save, check Status > OpenVPN
– If it is not connected, settings must not be right. Compare again & fix

9. Assigning OpenVPN as an Interface
● What it does:
– Adds a firewall tab under Firewall > Rules
– Adds reply-to to rules on the VPN interface tab for return
routing
– Adds a Gateway entry for the far side of the VPN for
policy routing
– Allows the interface to be selected elsewhere in the GUI
and packages
– Allows more fine-grained control of Port Forwards and
Outbound NAT for the VPN

10. Assigning OpenVPN as an Interface
● Interfaces > (assign)
● Pick OpenVPN client from list (e.g. ovpncX), click Add
● Check its name (e.g. OPT1)
● Visit the interface config page, e.g. Interfaces > OPT1
● Enable, give it a name like WANVPN or VPNCLIENT
● Leave IPv4/IPv6 Config Types set to None!
● Save the interface, then click Apply Changes
– Will disrupt the client!
● Go back to VPN > OpenVPN, Client tab, edit/save to reset VPN
● Now the VPN is active as an interface with a rules tab, gateways, etc.

11. Outbound NAT
● Optional if hosting your own, NAT could be done on the server side
● For VPN providers, NAT before it leaves your firewall or you won’t get
return traffic except for queries from the firewall itself
● Automatic Outbound NAT does not cover assigned OpenVPN interfaces
by default because it would be a hindrance to site-to-site VPNs
● Firewall > NAT, Outbound tab
● Use Hybrid mode (optimal) or if you are on Manual Outbound NAT that is
OK too
● Add rules using the assigned VPN interface to match a source of the LAN
and local networks going to any destination
– Similar to existing rules, but for the VPN
– Can use an RFC1918 alias to speed things up for multiple networks

12. Firewall Rule Concerns
● Firewall > Rules, assigned interface tab and OpenVPN tab
● OpenVPN tab rules can be dangerous!
– Allowing all inbound on OpenVPN could be akin to an allow all rule on WAN
– Ensure site-to-site rules do not allow too much
– If the VPN is for Internet access only, no OpenVPN rules should be required
– Even if the provider network is private that doesn’t mean you should allow their
traffic to reach your firewall!
● OpenVPN tab rules apply first, then interface tab rules
– Trick is to not match traffic on the tab rules, not to block it
– Use specific sources, not blanket block/allow from any rules
– Example: Blocking on the interface tab cannot override a pass on the
OpenVPN group tab.

13. Failover Scenarios
● Depending on tastes/requirements, failover may or may
not be desired.
● Some are OK with VPN failing back to WAN
– Create a gateway group for failover if needed
– System > Routing, Gateway Groups tab
● Others want traffic for VPN to never take WAN
– To make sure this happens, System > Advanced,
Miscellaneous: “Do not create rules when gateway is down”
– Make sure no other rule can match VPN user traffic, or block
after pass rule w/gw

14. Policy Routing and Selective Use
● On LAN rules, match traffic to send across VPN and set
VPN gateway or Failover group on rules
– Ex: Match phone traffic and send across VPN, other traffic out
WAN
– Ex: Match DVR traffic and send out WAN, match everything else
& send over VPN
● Pass local network/site-to-site traffic using rules w/o
gateway set above policy routing rules
● Remember to add a block or reject rule (or ensure no pass
rules) if clients should not be allowed to fall back to WAN

15. Routing / Firewall Traffic in VPN
● Traffic from the firewall won’t use VPN unless the default route or routing table
tells it to go that way
– DNS traffic (resolver, forwarder), firmware updates, Squid traffic, etc.
● Server might push you a default route, which may/may not be desirable
depending on what you want
● Use “Don’t Pull Routes” option on OpenVPN Client page to ignore routes from
the provider
● To manually use VPN as default gateway, use “redirect-gateway def1;” in
advanced options, don’t set under System > Routing
● OpenVPN will put 0.0.0.0/1 and 128.0.0.0/1 in routing table so it does not stomp
system default gateway, otherwise VPN traffic couldn’t exit
● To only route specific addresses across VPN from the firewall (e.g. VPN provider
DNS servers), use the Remote Networks box on the OpenVPN client page

16. Preventing DNS Leaks
●
A DNS “Leak” is when the real WAN address is revealed to DNS servers
– Can cause issues when trying to work around region locking
– Privacy concerns because your actual address could be discovered
●
Clients use remote DNS servers directly, DNS queries get policy routed
●
Use DNS Resolver in non-forwarding mode, allow VPN to set firewall’s
default gateway, then DNS resolver will send queries over VPN while
connected
● Forwarding mode/DNS Forwarder
– List VPN DNS servers only or at least first under System > General
– Pick VPN for DNS gateway, unless VPN provider connects using hostname then at
least one DNS server must not use VPN
– If using DNS Forwarder, check Query DNS servers sequentially to stop pfSense
from querying all servers at once

17. Inbound Traffic / Port Forwards
● Depends on provider/upstream, may not be an
option
– Some may require an API call/random port, not
currently supported
● Add port forward on assigned interface, same as
any other WAN port forward
● Check states/run a capture to test inbound traffic
● Works fine w/Host-Your-Own due to reply-to

18. Server Setup for Host-Your-Own
● Configure server like a standard Peer to Peer SSL/TLS server or even as
a remote access server if the clients do NAT
● Can be any non-PSK mode (SSL/TLS, SSL/TLS + User Auth, User Auth)
● Can even use the wizard to set it up if necessary
– May need adjustments depending on deployment style (e.g. where NAT is done)
● Add Outbound NAT rules to cover clients as needed
– Can do NAT on the server side, route to client LAN – or do NAT in both places,
easier config
– NAT on server, needs client override remote net / server remote net for client LAN
to setup route/iroute
● Allow to any destination in OpenVPN rules (block to RFC1918?)
● If clients will use DNS resolver on the server, add ACL to allow access

19. Conclusion
● Questions?
● Ideas for hangout topics? Post on forum,
comment on the blog posts, Reddit, etc