OPNsense
This assumes you have already installed OPNsense (or pfSense or are using equipment that was provided pre-installed.
Remember
Security is a compromise between usability and actual security
And when it comes to firewalls, least compromise rules. Related: note the default LAN rule on a OPNsense install is quite liberal and a higher level of security will be achieved by replacing it with specific rules for the ports that the users actually need to use.
Unban after too many login failures
Login via SSH on opensense firewall and run command:
sudo pfctl -t sshlockout -T flush
Initial configuration
needs updating Note that the firewall on first startup does have an active DHCP server, so suitable steps should be taken to avoid this disrupting an in-use LAN. A development or test network could be used, or a cross-over cable used to connect directly to the "LAN" port. If using a pre-installed device, the accompanying documentation should indicate which port this is.
Having connected a computer to the firewall (which would normally have a default IP of 192.168.1.1), use a browser to visit the firewall's IP (it would normally have a default IP of 192.168.1.1), accepting the security warning about the self-signed certificate. This should bring you to the OPNsense setup Wizard. You will need to login with the default (install) user and password.
Enter a hostname that will help you identify this firewall in future e.g. a site name. Use a domain name that is appropriate to your setup; generally the main domain name of the organisation is ok, or you can use an <organisation>.local internal-only address. Once configured this name will show in your browser's window title & tab name, making admin of multiple firewalls easier.
Enter DNS servers as needed. In some setups it may make sense for these to be internal DNS servers. Alternatively the OpenDNS servers will do
208.67.222.222 208.67.220.220
Leave the Override DNS enabled. Click Next.
Leave the NTP server as default unless you have a reason or preference for another. Set the timezone to suit. Click Next.
Leave the WAN interface configs as default unless you know that the IP should be static, or that other settings should be changed, and have the information available to configure it at hand. It can all be easily changed later. Click Next.
Set a good strong, long & unique password for the main admin account - this is a perimeter security solution. Store the password somewhere safe; later you will create individual accounts for accessing the firewalls and once that is done the main admin account will only be used in specific situations. Click Next.
Agree to reload the firewall. Note the admin IP/subnet is now whatever you set during the initial configuration so the machine you are using to access the web interface will also need to change.
Creating user accounts
For audit trail purposes it is best practice to create individual user accounts for administration, leaving the built-in admin account for use only when there is no alternative.
To create a user account, go to System -> User Manager. Click Add. Fill in as a minimum the Username, Password & Full name fields, then select the "admins" group in the Group Membership section and click Move to 'Member of' list. Use a strong password. Add SSH key if relevant and available.
Create your own account first, then log out and log back in as yourself before continuing.
Enabling wifi
If your OPNsense box has wifi hardware, and you want to enable it as an access point, go Interfaces -> (assign) -> Wireless. If the wifi hardware is recognised it should be in the "Parent Interface" drop down list, recognisable by MAC address or chipset/driver reference e.g. "ath0"; select it. Set Mode to "Access Point". Giving a memorable description such as "Firewall wifi" will make future configuration easier.
Next go Interfaces -> (assign), select the wifi interface from the drop down list for "Available network ports" and click Add. If this is the first additional interface you've configured, it will create the interface entry as OPT1; you can then configure this by clicking its name on the Interfaces Assignments page, or from the Interfaces menu.
Change the description to something more meaningful e.g. "wifi" and choose Static IPv4 from IPv4 Configuration Type dropdown list. Then in tbe Static IPv4 Configuration section assign an IP address and subnet to suit. For routing purposes the subnet has to be different to others already in use by the firewall. It depends on your policy what subnet you would choose, but something consistent generally helps later. Choose the correct subnet from the related list e.g. /24.
In Common Wireless Configuration choose a channel to suit (you can scan your environment for channels already in use to help make this choice). Setting the likely distance of clients may also be useful if this is going to be predictable.
Scroll down to Regulatory Settings and choose your country from the drop down list. Move on to Network-Specific Wireless Configuration and make sure Mode is set to Access Point, then set the SSID to suit and if you want 802.11N support, click to Enable WME. Unless this wifi is to be used as a guest-style network, or usage and security of it is being managed in another way, move on to the WPA section, click Enable and set the WPA Pre-Shared Key. The defaults in this section will generally suffice.
Now scroll to the bottom and click Save. This will check your config choices for inconsistency, but you should also review them before clicking Apply Changes. Next click to Enable the interface, scroll to the bottom and click Save again, then Apply Changes.
If you intend on using the wifi interface with typical usage patterns you will also need to enable DHCP for the wifi interface in Services -> DHCP Server -> WIFI (or whatever name you gave it). Click Enable and define a pool, leaving space for any current/future devices that need static addresses. In addition you will need rules to allow outgoing ports for whatever traffic types you want to allow for users. In general the web ports (80/443) and DNS (53) should suffice.
To enable the user ports outgoing, go to Firewall -> Rules -> WIFI, click Add and in Destination's From dropdown list select HTTP (80). Click Save. Repeat for HTTPS (443) and DNS (53). For DNS ensure you have selected TCP/UDP from the Protocol drop down in the Edit Firewall Rule section. Once all the riles are saved, click Apply Changes.
Enabling admin access on other interfaces
Admin access is enabled on the LAN interface by default. This is controlled by an in-built firewall rule. To allow admin access on another interface (WAN, Wifi, SSN etc.) you have to add a rule manually that permits access to the admin port you have configured. NB if allowing WAN access it's best practice to change the admin port away from the default web ports, and be using HTTPS. See OPNsense#Enabling_admin_access_on_WAN_interface for more detail.
To add a rule go to Firewall -> Rules and choose the interface you want to allow it on. Click Add, scroll down to Destination and select the appropriate interface address option from the Destination drop down list. Then enter the port in use in the From Custom field. You can select HTTPS (443) from the drop down if you've not customised the port. Click Save, then Apply Changes.
Enabling admin access on WAN interface
Enabling access on WAN interfaces is sometimes required to allow support from other locations, your home office or from third party support providers. It does open up the attack surface on the firewall so it is best to:
- require HTTPS (SSL)
- customise the port the UI is available on
- if realistic have specific rules per external IP address that will be allowed to access the UI
HTTPS is enabled by default in System -> Advanced -> Admin Access, and it is here you can set a custom (high) port. Note that the rule created to allow access to this will need to match, and if you've previously added a rule to allow access from anything other than the LAN, you must change this rule first. If you find yourself locked out then in most cases you will still be able to access the admin UI from the LAN.
If you want to limit access to the UI by IP address, then when creating the rule you should add the IP in the Source field, having selected Single host or alias in the drop down box. You will need a rule for every IP you want to access the UI from, and remember that for inter-site work this will be the public IP of the other sites. Note that if you have a VPN between site LANs you should be able to reach the LAN IP of the remote firewall and will be able to access the config that way - though only when the VPN is up.
SIP phones
Generally SIP will just work (assuming appropriate outbound rule). However if you have an L3 network where the phones are on a subnet different to that of any interface on the firewall, you will need 3 things:
- create a static route to that subnet
- disable firewall rules for traffic on the same interface
- create a manual outbound NAT rule (using hybrid, the auto rules will work fine for normal LAN subnet traffic) for the phone subnet
Setting the WAN IP & other WAN settings
WAN IP is normally set by DHCP on DSL connections and manually set on higher end connection types.
Using PPPoE
If you are using a pure modem or DSL router configured for passthrough/bridge, you will normally need to configure PPPoE settings to authenticate to your ISP, and successful authentication should result in your public IP being assigned. To configure PPPoE go to Interfaces > WAN and in the IPv4 Configuration Type drop down box select PPPoE. With this selected you can scroll down the page and enter the PPPoE username and password, where the username is normally of the form
<user>@<isp_realm>
Because some ISP tech assigns a private (RFC1918) temporary IP before the authentication completes, you may need to untick Block private networks and loopback addresses from the section below.
Manual configuration
To set a static IP manually, go to Interfaces > WAN and in the IPv4 Configuration Type drop down box select Static IPv4, then scroll down to the Static IPv4 Configuration section and the desired IP and gateway.
VPNs
IPsec Point to Point (inter-site)
needs review for 20. editions of OPNsense
In VPN > IPSEC
Click Add P1
Set Key Exchange Version to IKEv2 (unless other end is unknown)
Set Remote Gateway as public IP of other site being connected
Add an informative description (imagine if this site had VPNs to many other locations)
Use IP addresses as identifiers
Set Pre-shared key to something long and complicated (it only gets used twice, once at each end, and can be easily reset if lost)
Set Encryption Algorithm to AES 256 bits or as suits your hardware (e.g. AMD Geode have built-in support for AES128 so will tend to perform better with this option)
Hash Algorithm can be left as SHA1
DH Group to 2
Rest can be left to defaults
The remote end must be configured to mirror these settings.
Now click Show Phase 2 and thenAdd P2
Presuming the VPN is being added to enable comms between 2 LANs, set Remote Network to the subnet (or supernet) the tunnel should enable access to.
Add a useful description.
In Phase 2 Proposal, set Encryption Algorithms to Blowfish (unless you need something else to be compatible with the other end).
Everything else can be left to defaults.
The remote end must be configured to mirror the settings.
NB Once the VPN has been created it is effectively an interface and as such needs rules adding to allow it to flow traffic (cf. Firewall > Rules > IPsec, an "allow all" may be sufficient, depending on security profile between sites)
OPNsense specific notes
When creating the phase 1, enable Install Policy if you are not using VTI or no route for the phase 2 tunnel will be created.
VPN drops
If something interrupts a VPN tunnel at one end, e.g. Internet outage for > 5 minutes, the initiator of the tunnel may not notice and fail to renegotiate the phase 2 tunnel so no traffic can route between the subnets. To force renegotiation, login to the initiator and stop start the tunnel via VPN > IPSEC > Status Overview and pressing the cross button by the tunnel. This should result in the icon set for that tunnel changing to just be an orange triangle; at this point if you reload the page by clicking on Status Overview again you should see it has renegotiated the tunnel (3 buttons including an i for info); click the i to confirm the tunnel is renegotiated: it should show the phase 2 tunnel(s) and a Time entry under stats that is a few seconds. Anything much higher suggests the tunnel has not reset - however if Time matches at the other end then the tunnel is probably functional and there is another (non-VPN) issue that needs resolving.
To Smoothwall
Smoothwall hides, somewhat unhelpfully, various aspects of its VPN implementation. This means it's best to more or less "let Smoothwall be Smoothwall" and adapt your OPNsense config to suit.
So in Smoothwall -> Network -> VPN -> IPsec subnets, create your new "subnet" Create new tunnel using IP identifiers and PSK as above, name and comment appropriately, then click Advanced. Turn off Perfect forward secrecy, set Phase 1 cryptographic algo to AES256, Phase 1 hash algo to SHA, Phase 2 cryptographic algo to 3DES, Phase 2 hash algo to MD5.
Leave the rest as default.
In OPNsense add your phase 1 normal with the same PSK etc., then select matching settings as above for the Encryption and Hash Algorithm, and choose a DH Group of 5 (1536 bit). Add your Phase 2 as normal, matching the Encryption and Hash Algorithm as above.
Either side should be able to initiate the connection.
NB Other settings might work, but a long period of trial and error got to us to these, so until more information emerges we're sticking to them
Traffic shaping
needs review OPNsense has a fairly comprehensive traffic shaper. If you are very familiar with traffic shaping and the various techniques, you can go directly into it through Firewall -> Traffic Shaper. Most people will be better off using the Wizards, and in normal LAN/WAN situations the Multiple Lan/Wan wizard works best. The simplest form of traffic shaping is to provide priority to traffic that needs it, and let the rest use whatever's left over - however if your prioritised traffic is capable of soaking up all available bandwidth, it will; in which case you should explore the more complex traffic shaping options. When working through the wizard, if a page doesn't seem to apply to you e.g. Online gaming then you can just skip past it. For most non-specific applications the Raise or lower other Applications page is a good bet. If you enable the tick box you can choose to raise or lower protocols as necessary; note if you use video conferencing based on webRTC this is just http.
Custom rules
Creating and applying custom rules (for traffic types not covered in the wizard) can be created by Firewall -> Rules -> Floating. Add new rule, generally bottom but for real time traffic higher might be better, then select Action: Match. Select interface and protocols as needed, then enter source/destination addresses and a port range as required, enter a useful description then click Display Advanced. In the advanced section set traffic shaping as required; depending on your particular scenario it's probable that the appropriate choices in Ackqueue/Queue will be sufficient.
FTP
If users have need to use or provide FTP, OPNsense is too hard to just let it through (FTP really assumes no firewall, it's from a more trusting time). Best to install the FTP proxy from System -> Firmware - Plugins, then configure FTP proxies and LAN/WAN redirect rules as required. The proxy listens on its own port(s) internally to the firewall, so the redirect rules are from the port forwards to the localhost (127.0.0.1 is default) with the proxy port as specified (8021 by default). The proxy (or reverse proxy) then handles the traffic.
The port forward(s) should create the appropriate rule. If not for some reason then you need a rule for the port the client will try to reach - the port forward handles the rest.
Troubleshooting
SMB replication/domain joining
If you experience issues with SMB communications, and in particular issues joining domains or with DC replication, this can be caused by SMB packet fragmentation and be eliminated by going to VPN -> IPsec -> Advanced, clicking Enable MSS Clamping and setting Maximum MSS to 1300.
Tips
Analysing firewall logs
The firewall log live view in OPNsense has a powerful filter built-in which uses regular expressions (like or light?) to narrow down what you see. This functionality ranges from the obvious
ip.ad.dr.ess
(or part thereof) to looking for words from the rule description e.g. entering
deny
will find all logged rules being applied that have the word deny in their description, including the default deny all rule. Or entering
WAN
will find all log entries impacting the WAN interface. You can also enter a port number etc..
However what is less obvious is you can server for multiple elements, e.g.
WAN.*deny
will find all log entries containing both WAN and deny (although in that order), or
:123|:137
will find all log entries referencing the port 123 or(|) the port 37
Using CLI via SSH
This is particularly useful for changing to new ISP or WAN IP. You have to enable SSH access in System -> Settings and enable firewall rules to match. Once logged in with root capabilities you will see the same numeric menu that's available via the local console. Changing WAN IP (for example) can then be done by choosing the "Set interface IP address" option.
GeoIP rules
If you enable GeoIP as per the instructions on [OPNsense docs|https://docs.opnsense.org/manual/how-tos/maxmind_geo_ip.html], you can create aliases with GeoIP settings in them. Worth bearing in mind which way round you create the alias impacts how you use it in a rule. To allow only one or two countries, add those to the alias and then use them in the source rule section in a "pass" rule.
