Netgate, pfsense, oss, opensource, router, firewal, hangout

1. Advanced OpenVPN Concepts
September 2014 Hangout
Jim Pingle

2. What will be covered?
● This is a shorter talk with Q&A, not a complete walkthrough
– 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 2.2
● Tunnel Network Behavior
● Routing Methods
● Assigning OpenVPN Interfaces
● Several Multi-WAN/Redundancy tactics

3. Project Notes
● Bash CVE aka “Shell Shock” - pfSense-SA-14_18.packages
– Base system not vulnerable
– FreeRADIUS2 and mailscanner packages are affected, fixes posted
– FreeSWITCH packages affected, removed as unmaintained
● 2.1.5 is out – Security release, OpenSSL and other fixes
– Menu issue on Linux, caused by CSS+Fonts, several workarounds posted on
forum already.
● 2.2 Moved to BETA, already getting lots of useful feedback
– Help test tickets in Feedback state for fast release!
● OpenVPN client export update coming soon with new -I60x installers
which include a new tap driver
● Hackathon next month, Oct 17-20 in Austin, TX

4. OpenVPN Improvements in 2.2
● Clients can now specify user/pass
– These clients can also opt to not use a cert
● Authentication Digest Algorithm can now be selected in GUI
– Default is SHA1 to match implied default on <=2.1.x
● Client-Specific Override screen has many new fields
– Local (pushed), and remote (iroute) networks, lots of others.
● Additional compression settings (unset, on, off, adaptive) in
<=2.1 it was unset or adaptive
● Byte counts on the status page are human readable
● Option to disable IPv6 on some instances if it is not used
● Verbosity level

5. OpenVPN Tunnel Networks
● Shared Key
● SSL/TLS - /30 Tunnel Network
● SSL/TLS in tun mode, /24 or similar
● SSL/TLS in tap mode or tun with topology subnet

6. 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
● SSL/TLS with a /30 tunnel network behaves the
same as Shared Key.

7. SSL/TLS in tun Mode
● SSL/TLS w/tun setup and a larger subnet (/24)
● Allows multiple clients
● P2P links to clients each get their own /30
network (four IP addresses used per client)
● Client subnets handled inside OpenVPN and
not exposed to the OS the same
– Prevents broadcast and multicast from working

8. SSL/TLS Subnet Style
● SSL/TLS in tap mode and tun with topology subnet
behave similarly.
– Tap mode also passes layer 2 info, tun does not
● Both group clients into one large actual subnet rather
than sets of separate networks.
● More efficient use of IP address space, one per client
● Broadcast and Multicast can cross the VPN
● Can have quirks with some clients

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

10. 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
● Networks specified in “Remote IPv4 Networks”,
“Remote IPv6 Networks” or if using an SSL/TLS multi-
site network, pushed via the Local network boxes
● For SSL/TLS in tun mode for multiple sites, iroute is
used in Client Specific Overrides to route back to the
proper client

11. VPN Routing – Policy Routing
● Routes are not present in the routing table
● Routes managed by pf in firewall rules
(outbound)
● Inbound/return traffic handled via reply-to

12. VPN Routing - Dynamic
● Routes are present in the routing table
● Routes are managed by an add-on package
daemon such as Quagga for OSPF

13. Assigning OpenVPN Interfaces
● Allows more configuration possibilities for
handling traffic to/from the VPN
● Assignment automatically adds gateway
● Adds firewall rule tab
● Allows the interface to be selected for use
elsewhere in the GUI
● Outbound NAT, port forwards (VPN providers)

14. Assigning OpenVPN Interfaces
● Perform the assignment action from LAN or WAN,
not over this VPN
● Assign from Interfaces > (assign), creating a new
OPTx interface
– This disrupts the VPN, must restart VPN after the next
step
● Interfaces > OPTx
– Enable, change name, IP type of None! Save/Apply
– Edit/save VPN after applying these settings

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

16. 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
● For reply-to 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
– Or assign all OpenVPN instances and use no rules on the OpenVPN tab
– Rules are processed Floating -> Groups (OpenVPN tab) -> Interface tab
rules

17. Multi-WAN Tactics
●
Using multiple remote statements (built into OpenVPN)
– VPN is down for 60+ seconds before switch
– Any VPN disconnect will try the next remote
– Will not fail back automatically
●
Gateway failover
– Time to change depends on gateway monitoring, could be 10-60+ seconds
– Will fail back, but VPN will be disrupted
● Policy Routing
– Can do connection-based Load Balancing or Failover (not aggregation)
– Time to change depends on gateway settings, as above
– When the first WAN recovers, new connections will go back that way, existing connections
left alone
● Dynamic Routing with OSPF
– Very low time to change, could be only a few seconds.
– Fails back automatically with little or no loss of connectivity

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

19. Single server, multiple WANs
● Bind VPN instance to Localhost
● Port forward from WANs to Localhost
● Remote access VPNs
– OpenVPN client export package supports it 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

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

21. Multiple Servers, Multiple WANs
● Remote access, routing protocol or policy routed style
(covered later) only, cannot use for traditional site-to-site
(routes conflict)
● 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

22. WAN Failover (GW Groups)
● Gateway group as bind interface for OpenVPN
● Only active on one WAN at a time
● Useful for servers in some cases, but other methods are
generally better
● Useful for clients with Multi-WAN but relies on gateway
monitoring for changes so it can be slow to react
● 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.

23. Policy Routed Multi-WAN setup
● Load Balanced (connection-based) or Failover
● One server and client per WAN
● Needs only keys, compression settings, and unique tunnel networks
● Routes should not be added to all of the clients and servers
– May be added to one for firewall-to-firewall traffic since it will not balance.
● Assign VPN interfaces on both sides
● Create gateway groups for desired behavior (load balancing or
failover)
● 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

24. OSPF / Dynamic Routed VPN
● Can also be used to link multiple sites together
● Requires Multicast
● Static key or /30 SSL/TLS preferred, but works with
tap mode and/or tun mode with topology subnet
● Server side: Use two unique server instances, each on
separate ports/WANs
● 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

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

26. 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)
– Add the VPN tunnel network IPs with /32 masks to the list of subnets with "Accept Filter" set
●
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

27. Random OpenVPN Bits
● 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
● For remote access, if clients get disconnected
periodically, check/set reneg-sec timeouts in
advanced options for server and client

28. Q&A
Any Questions?