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.

OpenVPN as a WAN - pfSense Hangout October 2016


Published on

Slides for the October 2016 pfSense Hangout video

Published in: Technology
  • My friend sent me a link to to tis site. This awesome company. They wrote my entire research paper for me, and it turned out brilliantly. I highly recommend this service to anyone in my shoes. ⇒ ⇐.
    Are you sure you want to  Yes  No
    Your message goes here
  • Have u ever tried external professional writing services like ⇒ ⇐ ? I did and I am more than satisfied.
    Are you sure you want to  Yes  No
    Your message goes here
  • It's so easy that you can find it with your eyes shut. For example, as for me the best and the most responsibly working service is this one - - you'll find there everything you need. And the prices are reasonable.
    Are you sure you want to  Yes  No
    Your message goes here

OpenVPN as a WAN - pfSense Hangout October 2016

  1. 1. OpenVPN as a WAN October 2016 Hangout Jim Pingle
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 and 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. 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. 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. 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. 19. Conclusion ● Questions? ● Ideas for hangout topics? Post on forum, comment on the blog posts, Reddit, etc