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.