Minimum Firewall Rules to browse web

[wiz561]

Last weekend, I modified the network a bit and increased the vlans so that my network is a bit more secure.  My setup is as follows:

WAN - Internet
vlan1 - Servers (only need outbound web and nfs)
vlan2 - Workstations (outbound web and nfs)
vlan3 - wireless (outbound web only)
…

Things are working, but I've run into a problem where it seems like the return traffic is getting blocked.  So, for example, I have ssh open to a server on vlan1.  I have the NAT rule and also the firewall rule to allow ssh to the box in particular.  It works and I can ssh in, but after about a minute or so of being connected, the connection drops and I can't reconnect.

When you create the firewall rules, do you also have to create the return traffic rule?  So, should you allow everything over port 1024 out?  Being the security person I am, I'm a little uneasy about doing this.

Thanks in advanced.

[KOM]

When you create the firewall rules, do you also have to create the return traffic rule?

No.  pfSense is a stateful firewall.  Return traffic is automatically allowed in.  If something is being blocked, it will be in the firewall log.

Why do you need a NAT rule to access a server via SSH?  Post screens of your rules and interface/network details.

[jim82]

Generally it's a bad idea to use VLAN1 as it's the default VLAN on layer2 managed switches. You might run into issues using it, you might not.

Best practice would be to use fx.:

VLAN10
VLAN20
VLAN30
etc.

Keep unused switchports on the default VLAN(VLAN1) and customize the ports you need with your "own" VLAN's. This way you also avoid someone just plugging in a cable and gaining access to your Server VLAN.

BR Jim

[wiz561]

Thanks for the responses.  My setup is a little more complicated than what I posted and I left a lot out due to laziness and overloading readers and getting possible responses.  So here's what I'm doing (in detail).

I have pfsense running on vmware esxi.  I have two interfaces; one for the WAN that's a straight shot out and the other that plugs into a virtual switch and I let vmware take care of the vlans.  I went vlan crazy over the weekend…

vlan101 - 10.0.1.0/24 - old original 'lan' interface
vlan110 - 10.0.110.0/24 - servers
vlan113 - 10.0.113.0/24 - printers
vlan102 - 10.0.2.0/24 - guest network
vlan114 - 10.0.114.0/24 - hdhome cable boxes
vlan112 - 10.0.112.0/24 - wireless (internal lan)
vlan115 - 10.0.115.0/24 - for misc devices and future use

My goal is to be restrictive but make things work.  So, I did a default deny and am just slowly adding rules to make things work and then clean things up with aliases in the future.  Things are working, but it just seems like sometimes my connection stops working...for example, ssh.  I ssh in and things are working OK but then after a few minutes, the connection cuts out and I'm unable to reconnect.  Going through the pfsense logs, I see...

block - source (10.0.110.3:22) - dest: <my external="" ip="">- tcp:a

Attached are a number of screenshots of my setup.  I also run snort but the 104.207.x.x ip is not in the block list.

Finally, I added an easy rule to the firewall for 10.0.110.3 src: * dst: * to allow everything from that IP out so that I can ssh into it until I can figure why it's dropping the connection.

Thanks in advanced for any help.

EDIT: I removed some of the attachments containing additional information I didn't want out.  The 'solved' part is unrelated to the information in the pictures.

</my>

[KOM]

I don't see anything that jumps out at me.  If you click the red X in the far left of the firewall log, what rule is blocking those ACKs, the Default Deny rule?

I would remove extra stuff like Snort until you get this figured out.

[wiz561]

Interesting….thanks for the response and information.  When I click on the TCP:A block, I get:

snort2c:0label "Block snort2c hosts"

When I click on the TCP:RA block, I get...

@9(1000000103) block drop in log inet all label "Default deny rule IPv4"

The TCP:A log points to snort.  Don't exactly know why, but that's a huge lead for me to track it down.  The TCP:RA one points to a default deny rule.  Now I do have snort setup to autoblock, do you think snort blocked it and then sends the tcp reset ack because of the snort block?

Thank you again for the help!</snort2c:0>

[wiz561]

OK, I feel stupid now.  I was trying to diagnose why tcp/443 wasn't working, so I ran a nmap scan to check to see if the port was open or not.  It came back as being 'filtered'.  OK, so I'll give tcp/22 a scan since I know it's open. That came back as being filtered.  Confused and still connected, I started digging through the logs and it dropped my connection.

I ran through the snort logs and sure enough, it caught the 'potential ssh scan'.  Glad to know everything is working properly with blocking, but I should have dug a little deeper before posting.

Nonetheless, I'm glad I posted and found out how to diagnose a firewall block.  Thanks for the assistance.

[KOM]

Just to let you know, traffic that appears blocked but should be allowed by rule is usually what's called out-of-state traffic.  When a connection is torn down, pf will close a state before the destination end sends back an ACK, so the ACK is considered a new inbound connection and dropped since there is no WAN rule to allow it in.