OSPF lab

The goal is to investigate OSPF and its core features in preparation for the CCNA exam. The topology I used is based on three L3 switches, connected to my home network (192.168.2.0/24) where the MGMT PC is located.

The cabling details are as follows:

[ ]

--

Once the L3 switches are fully adjacent neighbors, I want to connect via SSH to them from the MGMT PC. In order to do that, I had to make some tweaks on the pfSense router.

First of all, the network 192.168.2.0/24 is being advertised into the OSPF domain via S1, so S2 and S3 learn about it via S1. Also, S1 is advertising its default route which points towards pfSense (192.168.2.1).

MGMT PC has a default route pointing towards pfSense. And pfSense has static routes towards 172.16.0.0/22 which is a supernet for the 3 networks behind S1.

With this configuration there are asymmetric routing issues, which I detected when connecting via SSH from MGMT PC to any of the management interfaces on S2 and S3.

The following uncluttered topology helps on seeing the problem:

Traffic from MGMT PC to S3 will go through pfSense since it is the default gateway for MGMT PC, but traffic in the opposite direction will go directly from S1 to MGMT PC.

Since pfSense is a stateful firewall, it must see traffic for the entire connection to be able to filter traffic properly. With asymmetric routing such as in this example, any stateful firewall will drop legitimate traffic because it cannot properly keep state without seeing traffic in both directions.

Traceroute from 192.168.2.11 to 172.16.1.2:

Traceroute from 172.16.1.2 to 192.168.2.11

The traceroute flows as in the diagram above, which is clearly an issue of asymmetric routing. This means the traffic will follow a different path in one direction than the traffic flowing in the opposite direction.

As the pfSense router cannot do OSPF routing by default, the issue must be solved using static routes and enabling the following option:

System > Advanced > Firewall & NAT > Advanced Options > Static route filtering [Bypass firewall rules for traffic on the same interface]

How pfSense sees the connection without the tweak

Without enabling this option, a connection may appear to work for a short time and then stop. This can be from the firewall removing a state which doesn’t transition to a fully open state, or it may be from clients expiring an ICMP redirect. This is how I detected the problem using SSH; the connection would be interrupted randomly.

As seen on Diagnostics > States:

SYN_SENT: For TCP connections this indicates that the side showing this state sent a TCP SYN packet attempting to start a connection handshake.

CLOSED: For TCP connections the side with this status considers the connection closed, or the firewall has not received any traffic.

Enabling ICMP Redirect on Windows 10

Another problem that arises with the topology above, is when trying to ping S2 or S3 from MGMT PC. pfSense sends an ICMP Redirect message to Windows 10, but Windows 10 simply ignores it. As it turns out, ICMP Redirects are blocked by default on the host firewall (Windows Defender), so we need to explicitly allow them.

Here is a Wireshark capture on the MGMT PC (Windows 10), where we can see ICMP redirects sent from pfSense to MGMT PC:

The item highlighted item is the icmp.redir_gw which is the gateway address to which pfSense is redirecting the host. Also, note how there's not a single packet originating from MGMT PC (source 192.168.2.11), because as said before, Windows 10 is ignoring this ICMP redirect messages.

To allow ICMP redirects, the following rule must be enabled on Windows Defender Firewall:

The scope should allow any local IP addresses. For the remote addresses, the scope should include at least the ones from which the MGMT PC will be pinged.

---

Sources:

Viewing Firewall States in the GUI
https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-states-gui.html

Static Routes
https://docs.netgate.com/pfsense/en/latest/routing/static.html#bypass-firewall-rules-for-traffic-on-same-interface