pfSense and OSPF

  • Home
  • pfSense and OSPF

Update October 23rd 2021: It’s come to my attention that with the pfsense firmware 2.5.2 (maybe before), Quagga_OSPF has been deprecated in favor of FRR. This write up is specific to 2.4.5_1 which is proabbly not advisable to run long term. I plan on writing a Quagga to FRR migration guide, will create a new post as time permits.

Related forum post: Click here

Hi everyone, I’ve just been through some lab scenarios involving the pfSense firewall with OSPF and thought I would share. I am really starting to like pfSense, the ability to install this firewall/router solution on 3rd party hardware or into a virtual machine has really helped in the lab. I’ve even purchased a physical appliance or two from them, just a great solution.

I haven’t had the opportunity to really dig into their deep packet inspection features as of yet, but depending on how robust they are, I can’t see a reason why small and medium business wouldn’t run these firewalls instead of a SonicWALL, Watchguard, etc…

The following is an OSPF example configuration using a Nexus 3548 layer3 switch pair and a pfSense (2.4.4_3) firewall running in a VMware VM (ESXi 6.5).

Step 1 is to install the OSPF module for pfSense, using the “System > Package Manager” menu. Select “Available Packages” and search for OSPF. You are looking for the Quagga_OSPF package. Once installed it will be listed under Installed Packages.

You can access the OSPF configuration using “Services > Quagga OSPFd”.

On the OSPF configuration screen you basically have “Global Settings” and “Interface Settings”. I noticed when setting up a fresh firewall that I couldn’t save my “Global Settings” changes until I added at least one interface to OSPF under Interface settings. I was impressed how easy it was to get OSPF going between this firewall and the Cisco Nexus device, the default hello and dead timers match, there are just a few things to set on each page.

Global settings I changed:
Master Password: I just set this to an 8 character password, doesn’t seem to matter in regard to OSPF peering. Description states the password is used to “access the Zebra and OSPF management daemons.

Router ID: Not required, but this makes things easier when reviewing neighbors. If not set the router picks it’s own from the highest configured IP address I believe.

Area: Generally this is area 0 represented as a 32bit number, so Area 0 is the first area in any OSPF environment and all other areas need to be connected to Area 0. For small networks, multi-area OSPF is generally not configured or required.

That is it for the Global Tab, there are a lot of other options, but for a basic setup they really aren’t needed. A lot of folks might think the “redistribute connected subnets” is needed, but this happens on a per interface basis as OSPF is enabled under the Interface settings tab. I tend to prefer that method rather than blasting out every network that might ever be configured on the device.

I also don’t typically use the default route distribution option. Typically routers only have one path to the internet out of a given network and that is a static “0” route set on the device. There are a lot of ways to skin this cat though.

Interface settings I changed:
Things get a little more interesting here. in my case I two interfaces that needed to bring up a peering relationship with other OSPF “neighbors”. I also have an OpenVPN interface on this pfSense firewall with a subnet I wanted injected into OSPF. So you select “Add” and end up configuring interface specific settings that should match on the peers in the same broadcast network.

Interface LAN:
Metric: This is interesting on the pfSense. I don’t see anywhere in the config where you can set a reference bandwidth for OSPF, so I just end up hard coding the metric so that it is compatible with the rest of my environment. For example, the Nexus devices I am running use a reference bandwidth of 40Gb. The LAN interface on this pfSense box is 10Gb. So reference bandwidth divided by actual, leaves me with a metric of 4. It’s important to get these right across the entire environment otherwise your OSPF implementation may make sub-optimal routing decisions.

Enable MD5 password for this Quagga OSFPd interface: This is a good idea, set a password and enable MD5 for all the peers in a given broadcast network which need to bring up a neighbor relationship. This prevents accidental neighbors from coming up and sharing bad routes.

Interface opt1:
This was pretty much setup the same way as the LAN interface.

Interface ovpns1:
Again this interface is configured similarly, with two caveats. The OpenVPN interface doesn’t need to bring up an OSPF neighbor relationship with any other device. We are simply enabling OSPF on the interface so that the VPN subnet gets injected into the routing tables of participating devices. For this reason we will select the option “Prevent transmission and reception of OSPF packets on this interface.” In Cisco land, this translates to passive-interface.

The other option that was treated a bit differently is the “Metric” for the VPN interface. This should be calculated based on the internet circuit speed rather than the actual throughput of the local interface. in my case the internet is a 1Gb synchronous connection, so the reference bandwidth of 40Gb devided by 1Gb, gives me a metric of 40.

The following is an example SVI configuration from one of the Nexus devices showing the OSPF config it is using to bring up the neighbor relationship with pfSense over the network.

interface Vlan199
description LAN-VLAN-199
no shutdown
bandwidth 40000000 <----reference bandwidth of 40Gb in kilobits
ip address
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5
ip router ospf 1 area

NX1# show ip route
IP Route Table for VRF "default", ubest/mbest: 2/0
*via, [1/0], 1d15h, static, ubest/mbest: 1/0 <---------------pfSense open VPN network!
*via, Vlan199, [110/41], 1d14h, ospf-1, intra, ubest/mbest: 1/0, attached
*via, Vlan199, [0/0], 1d15h, direct, ubest/mbest: 1/0, attached
*via, Vlan199, [0/0], 1d15h, local, ubest/mbest: 1/0
*via, Vlan199, [110/5], 1d14h, ospf-1, intra

NX1# show ip ospf neighbors vrf default
OSPF Process ID 1 VRF default
Total number of neighbors: 2
Neighbor ID Pri State Up Time Address Interface 1 FULL/DR 1d15h Vlan199 <------pfSense neighbor 1 FULL/DROTHER 1d14h Vlan199<-----second nexus neighbor

Leave a Reply