SG-5100 21.02-Release unable to use IPS due to NETMAP

MBMountain

Following the upgrade of the SG-5100 to the 21.02 release, and re-installing Suricata, I'm unable to use the latter in Inline-mode. It keeps giving the error as follows:

The 'wan' interface does not support Inline IPS Mode with native netmap.

This although the Hardware Checksum Offloading, Hardware TCP Segmentation Offloading and Hardware Large Receive Offloading are all disabled as per requirements.

What could be the issue?

bmeeks

That should not be happening. Is your WAN the igb0 interface? If so, that is a supported interface type.

A couple of package updates back (I don't recall precisely when), one of the Netgate developers added a section of code to the INTERFACE SETTINGS tab in both Snort and Suricata that checks the physical interface against a list of "known to be netmap compatible" NIC drivers. If the NIC chosen for the current interface is not compatible, an error message is displayed when saving.

MBMountain

@bmeeks
Yes, the WAN is in the igb0 port. No hardware-changes were made and it's a standard Netgate SG-5100. It worked perfectly fine on the old PFSense, and worked well in the 21.02 until I needed to reload the config file due to issues with the ISP. The latter had the packages re-installed and since then it's unable to use inline mode.

Is there a way to stop the netmap from acting on that port?

bmeeks

For a quick fix, if you wish, you can make an edit to the PHP GUI code for Snort that will remove the check and thus allow you to save the configuration.

I recommend doing the following via tools such as SSH and WinSCP. My favorite SSH client is PuTTY.

Open a session to the firewall shell and make a copy of this existing file just in case you need to put it back.

cp /usr/local/www/snort/snort_interfaces_edit.php /root/snort_interfaces_edit.php

That will put a backup copy in the /root directory for safekeeping.

Now use either WinSCP (it has a nice built-in editor on Windows) or vi from the command line in pfSense and open /usr/local/www/snort/snort_interfaces_edit.php for editing.

Within that file, find the following sequence of code starting at line 253.

if ($_POST['ips_mode'] == 'ips_mode_inline') {
		$is_netmap = false;
		$realint = get_real_interface($_POST['interface']);
		foreach ($netmapifs as $if) {
			if (substr($realint, 0, strlen($if)) == $if) {
				$is_netmap = true;
				break;
			}
		}
		if (!$is_netmap) {
			$input_errors[] = gettext("The '{$_POST['interface']}' interface do not support Inline Mode.");
		}
}

Comment out that entire section so that it looks like this (put double forward slashes in front of every line):

//if ($_POST['ips_mode'] == 'ips_mode_inline') {
//	$is_netmap = false;
//	$realint = get_real_interface($_POST['interface']);
//	foreach ($netmapifs as $if) {
//		if (substr($realint, 0, strlen($if)) == $if) {
//			$is_netmap = true;
//			break;
//		}
//	}
//	if (!$is_netmap) {
//		$input_errors[] = gettext("The '{$_POST['interface']}' interface do not support Inline Mode.");
//	}
//}

Save the changed file and that should do it. If you upgrade the package again, these changes will be overwritten. I will investigate further using my own SG-5100 when I upgrade it.

MBMountain

@bmeeks I would indeed go for the quick fix first, but I want to check first if this is also applicable to Suricata? As that's the package I use (sorry for not mentioning that earlier and more clearly)

viktor_g

@mbmountain unable to reproduce your issue,
igb is already in the netmap-compatible list:
https://github.com/pfsense/FreeBSD-ports/blob/595ba090bfdae6b08a54f71d09f2df36c6a11f08/security/pfSense-pkg-suricata/files/usr/local/www/suricata/suricata_interfaces_edit.php#L35

Please show the <interfaces> part from the /cf/conf/config.xml

bmeeks

@mbmountain said in SG-5100 21.02-Release unable to use IPS due to NETMAP:

@bmeeks I would indeed go for the quick fix first, but I want to check first if this is also applicable to Suricata? As that's the package I use (sorry for not mentioning that earlier and more clearly)

Oops! Your're correct. I had Snort on my brain. The code is the same in both packages, but the line numbers (and obviously the filename) are different.

I see @viktor_g has replied as well, and he is correct that the proper checks are in the code. Perhaps something weird has occurred in your configuration. Provide him the info he asked for and that will help.

MBMountain

@viktor_g I've taken the first section describing the WAN and LAN. The igb0 interface is in use for WAN, igb1 is connected to a L3 Switch.

bmeeks

@mbmountain said in SG-5100 21.02-Release unable to use IPS due to NETMAP:

@viktor_g I've taken the first section describing the WAN and LAN. The igb0 interface is in use for WAN, igb1 is connected to a L3 Switch.

Your WAN interface is shown as pppoe0. PPPoE interfaces are not actually netmap-compatible, so the code is correct to exclude it as netmap is not natively-supported there. That means it will use the emulated netmap device and be much slower than a natively supported interface would be. And the emulated netmap device can sometimes do funky things with some setups. User problems caused by using Inline IPS (netmap) on unsupported interfaces is why we added the validation code to the package a few revisions back.

For the PPPoE interface, I would strongly recommend you use the Legacy Blocking Mode instead of Inline IPS Mode.

To be honest, you really are better off running an IDS/IPS on your LAN anyway. The firewall is going to default-drop a lot noise, and there is no need to burden your IDS/IPS analyzing stuff the firewall is dropping anyway. Your LAN interface will configure in netmap and Inline IPS Mode just fine.

The only route to your internal hosts is through the internal interface they hang off of, so putting the IDS/IPS on the internal interfaces is the better approach. It eliminates useless work for the package (analyzing packets the firewall's rule are dropping anyway), and it means all local IP addresses will be shown with their actual values instead of post-NAT on the WAN side where all local IPs will show up as the firewall's public external IP.

MBMountain

@bmeeks Not the answer I had hoped for, but fair enough It makes sense, although I'm not quite sure why it worked before. Nevertheless, many thanks for the quick reply.
Instead I will need to dig into how to make suricata not block my needed sites. Which is more laborious than I had hoped, but as laborious as I had expected.

bmeeks

@mbmountain said in SG-5100 21.02-Release unable to use IPS due to NETMAP:

@bmeeks Not the answer I had hoped for, but fair enough It makes sense, although I'm not quite sure why it worked before. Nevertheless, many thanks for the quick reply.
Instead I will need to dig into how to make suricata not block my needed sites. Which is more laborious than I had hoped, but as laborious as I had expected.

Put Suricata on your LAN like I said. That's where I run my IDS/IPS. It is really the best place. On your LAN, you can use Inline IPS Mode just fine, since that physical NIC is fully supported.

MBMountain

@bmeeks
I need to get more up to speed with this (relatively new), but I was always on the presumption that I needed to put the IDS/IPS on the outside connection (speak WAN) instead of on the internal faced section, in this case LAN. I will work on it, again thanks for the info

bmeeks

@mbmountain said in SG-5100 21.02-Release unable to use IPS due to NETMAP:

@bmeeks
I need to get more up to speed with this (relatively new), but I was always on the presumption that I needed to put the IDS/IPS on the outside connection (speak WAN) instead of on the internal faced section, in this case LAN. I will work on it, again thanks for the info

That was the old way of thinking, but because the IDS sits immediately after the NIC, it sees inbound traffic before the firewall. So the IDS will alert and respond to all the Internet crap your default drop rule on the firewall is going to block anyway. So why bog down the IDS analyzing all that noise?

Here is a digram that shows how the IDS/IPS fits into the network path for Inline IPS Mode and Legacy Mode.

So notice in either case the IDS is "in front" of the firewall with respect to inbound traffic on an interface. So let the firewall filter the noise on the WAN. pfSense is plenty secure itself, so you aren't protecting the firewall with your IDS/IPS, you are protecting your local networks. They are behind the firewall, so you can put the IDS/IPS there and still protect them just fine. No Internet host can reach a local network host without going through the IDS/IPS on the LAN interface (or any other internal interface you may define).