Monday, November 23, 2020

pfBlockerNG: Internet Goes Out After Reboot

While using pfBlockerNG (including the "devel" version) on the SG-3100 and SG-1100 we ran into a problem where all internet traffic would stop after a power loss or a reboot. The only way to get traffic to flow again would be to get into the firewall and disable pfBlocker. The fix ended up being very simple, though, surprisingly we could not find it listed or mentioned anywhere on the Internet. There are just a few settings that I found needed to be changed:

1. Increase Firewall Maximum Table Entries on the System / Advanced / Firewall & NAT page from 400,000 to 600,000 (could be higher but 600,000 has worked very well for me).

2. Enable De-Duplication, CIDR Aggregation and Suppression pfBlockerNG options on the Firewall / pfBlockerNG / IP page.

After changing those settings I haven't been able to recreate the problem at all, even after adding multiple memory intensive packages to the firewall.

Monday, November 16, 2020

Netgate Or Not Netgate

 Personally,  we do use a lot of Netgate gear.  Is it the best thing out there?  Probably not.  But,  the pfsense updates are tested on Netgate gear,  and that does make it more valuable to our customers.  I have not had any complaints or of using Netgate gear,  but I have also put in many pfSense boxes that was something else without issue.  I just think the updates being tested on Netgate gear before you see the update is pretty important. 

Sunday, November 8, 2020

PBR (Policy Based Routing) And PFSense

Another post from sister blog on June 2, 2020.

I went to a customer site today (June 2nd) where they had a Toshiba IP phone system that would not route but to only one destination (the default gateway). But the need was to have certain traffic go out one internet connection (smtp) and the voice traffic out the other. So, I put a Netgate SG-1100 in to do the PBR and it worked great. Doing PBR on PFSense was easy and made sense for this customer. And yes, it's setup with only the LAN port. It's all they needed.

Thursday, October 29, 2020

PFSense: 1:1 NAT Configuration

Vendor documentation is really key to helping admins setup and configure, well, really anything.  You can say that about firewall vendors, network vendors, server vendors, etc.  One thing I always admired about Cisco was their documentation on how to configure different things.  I still believe they are one of the best at documentation.

PFSense has some decent documentation, but not always the most clear documentation.  1:1 NAT'ing is one of those things to me.  So I have outlined what you need to do for a 1:1 NAT'ing when you need access to an internal device from the Internet. 
Now first, I hate when people go into these long paragraphs of how things are supposed to work.  I just want the answer I'm looking for.  But, one thing needs to be clarified here.  1:1 NAT and Port Forwarding are two different things.  Port forwarding uses the IP address of the firewall interface to get to your internal traffic, via different ports you configure.  1:1 NAT uses an IP address on the same network as your WAN interface, but not the interface of the firewall itself.  Clear?
Ok, so in most firewalls, you generally need a couple of things to make getting to an internal device from the Internet happen.
1.  A NAT rule.
2.  A firewall rule.
In Palo Alto, Cisco, Check Point, SonicWall, etc, that's all you need.  However, in PFSense, there is one more thing you have to do to make this work.  Its called a virtual IP (under Firewall --> Virtual IP).  What you do with a virtual IP address is that you are telling the firewall that it needs to handle requests for an internal device you are trying to NAT to.  If you don't, the firewall wont respond to ARP requests made on the WAN side.  If you do add the virtual IP address that you want to use for the WAN IP address you want for your web server, etc, then it will respond to the ARP request and NAT your traffic through.  I verified this with a packet capture, so you can be sure you do need this.
So for a PFSense 1:1 NAT, you need the following:
1.  A NAT rule.
2.  A firewall rule.
AND 3. A virtual IP address that is the same as your WAN side NAT that you configured in #1.  (The subnet mask will be the same as your WAN interface subnet mask.)
Note that you can use this for port forwarding also. 

Wednesday, October 28, 2020

Pfsense: DHCP And What It Won't Do

From our sister blog . We will be moving those pfSense blog posts from there to good blog for ease of finding. 

I always like to talk about what a firewall will do. But sometimes I have to talk about what a firewall won't do. Today, it's PFSense's day to get this kind of talk.

I have a lot of customers that run DHCP on the firewall. Right, wrong, or indifferent doesn't matter for this conversation. What does matter is that Pfsense will do DHCP for any directly connected network. What it won't do is DHCP for a non directly connected network. Is that a need for some people? Yes. Is that the firewalls job to do? It doesn't matter if that's what the customer wants. I personally wouldn't do it there, but in reality, it doesn't really matter. If the firewall goes down, you have bigger problems than DHCP.
So why doesn't PFSense do DHCP for non connected networks? I don't know the answer. What I do know is that other vendors, like Palo Alto and Sonicwall will do DHCP for non directly connected networks. It's not the end of the world, but just something to note.

Saturday, October 24, 2020

How To Do A Password Reset For A pfSense Box

I thought we would start off with how to do a password reset in pfSense.  I have come across this several times when either taking over a firewall or I just plain forgot it.  Either way, you need a console cable to get into CLI to do this.  Below is how it looked.  Its pretty simple, you select "3", then "y", then you are done.  

FreeBSD/arm (FW.localdomain) (ttyu0)

Netgate SG-3100 - Serial: XXXXXXXX - Netgate Device ID: 

*** Welcome to pfSense 2.4.5-RELEASE-p1 (arm) on FW ***

 WAN (wan)       -> mvneta2    -> v4/DHCP4:
 LAN (lan)       -> mvneta1    -> v4:
 OPT1 (opt1)     -> mvneta0    -> 

 0) Logout (SSH only)                  9) pfTop
 1) Assign Interfaces                 10) Filter Logs
 2) Set interface(s) IP address       11) Restart webConfigurator
 3) Reset webConfigurator password    12) PHP shell + pfSense tools
 4) Reset to factory defaults         13) Update from console
 5) Reboot system                     14) Disable Secure Shell (sshd)
 6) Halt system                       15) Restore recent configuration
 7) Ping host                         16) Restart PHP-FPM
 8) Shell

Enter an option: 3

The webConfigurator admin password and privileges will be reset to the default (which is "pfsense").
Do you want to proceed [y|n]? y

The password for the webConfigurator has been reset and
the default username has been set to "admin".

Remember to set the password to something else than
the default as soon as you have logged into the webConfigurator.

Press ENTER to continue.

Friday, October 23, 2020

pfSense Blog Startup

 I'd like to introduce to you our new blog on the pfSense firewall, or anything related to pfSense.  The blog will be written by White Rhino Security engineers for the benefit of the general public, in the hopes that it will help with configurations, etc.  As we have not had a dedicated site for one single firewall at this point in time, we thought we would try this out and see how it goes.  Some of the content may be "article like", while others may be direct and to the point on how to configure a certain technology.  It will depend on who is writing the blog post at that particular time.  We hope you find this helpful in some way.

White Rhino Security is a security managed services provider for anyone in the United States.