Traffic Should Pass, But Doesn't
-
After some conversations here, I simplified my firewall rules. Unfortunately, in my firewall logs, I'm seeing some traffic being blocked by my second to last block rule that should be passed by my second pass rule. Here are the log entries:
Apr 18 12:40:40 VPN_LAN VPN_LAN: Default Reject IPv4 (1491926872) 192.168.20.4:49745 216.58.195.74:443 TCP:PA
Apr 18 12:23:35 VPN_LAN VPN_LAN: Default Reject IPv4 (1491926872) 192.168.20.4:51525 216.58.195.77:443 TCP:PA
Apr 18 12:23:35 VPN_LAN VPN_LAN: Default Reject IPv4 (1491926872) 192.168.20.4:51524 172.217.6.42:443 TCP:PA
Apr 18 12:23:35 VPN_LAN VPN_LAN: Default Reject IPv4 (1491926872) 192.168.20.4:51524 172.217.6.42:443 TCP:Aand here are my firewall rules for that interface (VPN_LAN):
Rules (Drag to Change Order)
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
VPN_LAN Permit Traffic Rules
30 /24.73 MiB IPv4 * VPN_LAN net * LOCAL SUBNETS * * none VPN_LAN: Pass All Local Traffic
35 /475.39 MiB IPv4 * VPN_LAN net * ! LOCAL SUBNETS * VPN_Group none VPN_LAN: Pass All Outbound Via VPN_Group
VPN_LAN Reject Traffic Rules
0 /0 B IPv4 TCP/UDP VPN_LAN net * ! VPN_LAN address 123 (NTP) * none VPN_LAN: Reject Non-Local NTP
0 /58 KiB IPv4 * * * * * * none VPN_LAN: Default Reject IPv4
0 /0 B IPv6 * * * * * * none VPN_LAN: Default Reject IPv6I've attached a screenshot for easier reading.
I can't get a screenshot of the whole rule in question, but the important fields in the rule are:
- Action: Pass
- Interface: VPN_LAN
- Address Family: IPv4
- Protocol: Any
- Source: VPN_LAN net
- Destination: Invert Match is checked, Single host or Alias, LOCAL_SUBNETS
- Gateway: VPN_Group - VPN Gateway Group
The LOCAL_SUBNETS Alias contains the following Networks:
192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24, 192.168.40.0/24, 192.168.1.0/24
of which, only 192.168.20.0/24 currently has anything attached (that's VPN_LAN).
The Gateway is in there because this is over my VPN where I've got two separate servers running concurrently and their respective WAN interfaces are grouped into a Gateway Group.
AFAIK, that rule applies to the VPN_LAN interface and passes any outgoing IPv4 traffic from the 192.168.20.0/24 network that's going anywhere that's NOT on my local subnets to my VPN's Gateway Group. It seems to be doing that most of the time. But, for some reason, it's not catching the particular traffic to those external IPs (which appear to be Google-owned servers). Am I misinterpreting my rule?
 -
Rules (Drag to Change Order)
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
VPN_LAN Permit Traffic Rules
30 /24.73 MiB IPv4 * VPN_LAN net *LOCAL SUBNETS* * none VPN_LAN: Pass All Local Traffic
35 /475.39 MiB IPv4 * VPN_LAN net * ! LOCAL SUBNETS * VPN_Group none VPN_LAN: Pass All Outbound Via VPN_Group
VPN_LAN Reject Traffic Rules
0 /0 B IPv4 TCP/UDP VPN_LAN net * ! VPN_LAN address 123 (NTP) * none VPN_LAN: Reject Non-Local NTP
0 /58 KiB IPv4 * * * * * * none VPN_LAN: Default Reject IPv4
0 /0 B IPv6 * * * * * * none VPN_LAN: Default Reject IPv6Redo your rules like so:
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions VPN_LAN Permit Traffic Rules 30 /24.73 MiB IPv4 * VPN_LAN net * * * VPN_Group none VPN_LAN: Pass All Local TrafficYour first two rules passed LAN traffic and non-LAN traffic, effectively passing everything. From glancing at it I would think that the traffic being blocked should be blocked by rule two, maybe it already had been blocked before you edited/reordered rules?
Also, it's generally better to filter traffic by destination port, not destination address. It's not always the case but for what it looks like you are trying to do it is. Your first two rules are just one pass anything from my subnet to anywhere via the VPN gateway.
pfSense non-floating rules are first match wins and anything not explicitly passed is blocked.
So placing block rules after a pass any rule does nothing, the traffic has already been passed. If you want to block something specific then block it before you pass everything.
-
Also it's typically better to Block than Reject unless you have a specific reason to Reject (and there are reasons to do so).
But think of it this way:
Someone you don't want to talk to knocks on your door:
Block = you say nothing, they have no idea anyones home and they move on to the next house
Reject = you don't open the door but tell them you're home and don't want to talk, so they come back later to see if you're in the mood then -
All non SYN TCP packets are out of state. pfSense is stateful, and out of state is ALWAYS blocked.
-
TS_b:
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions VPN_LAN Permit Traffic Rules 30 /24.73 MiB IPv4 * VPN_LAN net * * * VPN_Group none VPN_LAN: Pass All Local TrafficThat was my first shot at simplifying my rules. Then I started worrying what would happen with the local-to-local traffic and the Gateway Group in there. So, I split the internal-internal traffic rule out from the internal-external rule. So, internal traffic won't have trouble with that in there?
Regarding filtering by port vs address, I initially had that. But, for a home network, keeping up with the ports was too much. So, I tried to re-create the default allow everything internal to get out rule. But, since I had that Gateway Group on my traffic heading for the VPN tunnel, I split the rule.
Regarding "anything not explicitly passed is blocked," I was pretty sure of that. But, my setup is a modified version of a Guide for setting up my VPN and the author explicitly blocked everything left for logging reasons. When I re-did these rules, I couldn't find an example of what the default, out-of-box rules looked like. So, on the assumption it couldn't hurt, I left the rules in. Plus, the logging.
Regarding Blocking vs Rejecting: the author of that guide used "reject rather than block on internal interfaces to ensure a response to any programs trying to send traffic preventing delays associated with waiting for time outs to occur." So, my external interfaces use Block, while my internal ones use Reject.
Harvy66: non-SYN TCP. That was interesting. I started searching and found that the TCP:PA on the log entries means the traffic is a reply packet. So, the SYN part of the handshake was missing. According to:
Sometimes log entries will be present that, while labeled with the "Default deny" rule, look like they belong to legitimate traffic. The most common example is seeing a connection blocked involving a web server.
As also stated in this m0n0wall FAQ, this is likely due to a TCP FIN packet arriving after the connection's state has been removed. This happens because on occasion a packet will be lost, and the retransmits will be blocked because the firewall has already closed the connection.
It is harmless, and does not indicate an actual blocked connection. All stateful firewalls do this, though some don't generate log messages for this blocked traffic even if all blocked traffic is logged.
These blocked packets will occur even if rules exist which look as though they should match the traffic, such as an "Allow All" rule, as pass rules for TCP only allow TCP SYN packets to create a state. These rules assume TCP traffic with other flags will either be part of an existing state in the state table, or packets with spoofed TCP flags.
Thanks, all.
-
The reason that it is recommended to whitelist ports not addresses (if whitelisting is what you want to do) is because there are 1024 managed ports, but almost 4.3 billion IPv4 addresses. So ports are actually dramatically easier to keep track of.
About the only time you'd probably want to filter by addresses on a home network is if you want to open up a port that you would otherwise leave closed, but only for something very specific.
Out of the 1024 managed ports, you probably only need <10. Ports 80, 443, 22, 123, 53, 25, 465, 993, 995, 1024:65535 - if you allow those ports for TCP/UDP traffic you will very likely have no compatibility issues and your network will be more secure than your average bear's. :)
That's only one piece of the pie but it's actually a pretty easy one for most home networks that most people pass on.
-
Why is it more secure to disallow connections to, say, port 26 but allow connections to 1024:65535?
If anything it is more difficult for bad actors to listen on the low ports.
-
Well from my understanding of it, just choosing what ports & traffic to pass is just one part of the very complex issue of network security. Really all that non-IT/CS home users like myself can hope for is a happy compromise in network security that hopefully makes our networks a lot less appealing/easy of a target than the large number of home users running a SOHO router with the default configs & passwords.
But in my mind it makes sense that closing off at least some of the ports that you know you won't be using will provide some level of protection. 1024:65535 are used by so many different things and often at random that for a home network I don't think it's at all practical to try and whitelist the high ports.
whitelisting the managed ports on the other hand can be done over one cup of coffee for most home networks.
I would argue that while it isn't secure in and of itself, it is more secure than allowing any or blacklisting.
But I'm no IT specialist and I'm just learning all of this too. This is just my understanding. I definitely value your feedback on my understanding no matter how scathing it may be . ;)
-
But in my mind it makes sense that closing off at least some of the ports that you know you won't be using will provide some level of protection. 1024:65535 are used by so many different things and often at random that for a home network I don't think it's at all practical to try and whitelist the high ports.
whitelisting the managed ports on the other hand can be done over one cup of coffee for most home networks.
I would argue that while it isn't secure in and of itself, it is more secure than allowing any or blacklisting.
But I'm no IT specialist and I'm just learning all of this too. This is just my understanding. I definitely value your feedback on my understanding no matter how scathing it may be . ;)
I setup my home network as a whitelist and it was muuuuch easier than I expected. I guess it depends what you are running though. I'd say half of the multiplayer games I play require a new port or two. Certain services like torrents require practically every port.
-
Ports are just ports, no preference over one or the other. The only slight twist is that the so called "privileged ports" under 1024 are supposed to be superuser accessible (for listening on a local system) only but that doesn't offer any real security anymore. The whole concept of privileged ports dates back from 1970's and 80's when the only systems running an operating system compareable to what we now have were the large mainframes with fully locked down access to the machine themselves, a regular user on those systems was not able to use the privileged ports. Now of course you are the master on your own home computer and you can set up any service you wish listening on the privileged ports. This means that when filtering outgoing traffic there's zero difference if the traffic goes to a privileged port or not. In other words, you no longer can trust that a service listening on a privileged port to be trustworty in any sense. This is the main motivation behind SSL/TLS and other cryptographic authentication methods, need to verify that a peer you're connecting to is what it claims to be.
-
I setup my home network as a whitelist and it was muuuuch easier than I expected. I guess it depends what you are running though. I'd say half of the multiplayer games I play require a new port or two. Certain services like torrents require practically every port.
Where did you start/ what method did you use to whitelist the high ports?
Just trial and error and looking at the logs? I'd certainly be interested in doing it myself if it isn't that difficult.
-
I setup my home network as a whitelist and it was muuuuch easier than I expected. I guess it depends what you are running though. I'd say half of the multiplayer games I play require a new port or two. Certain services like torrents require practically every port.
Where did you start/ what method did you use to whitelist the high ports?
Just trial and error and looking at the logs? I'd certainly be interested in doing it myself if it isn't that difficult.
Yeah, pretty much. A quick glance at my port aliases seems to show that that I only had whitelist maybe 20 ports. That number has been slowly increased over the course of about a year to include services for visiting familiy members & friends and 2 or 3 additional services I added. So I think I initially had to whitelist like 14 ports for all my devices to operate seamlessly?
Whitelisting was mostly done as a learning experience, so in some ways I wanted it to be kinda tedious but it wasn't.
Discouraging illegitimate & malware services was a factor in choosing whitelisting but it's also useful being more aware of the types of legitimate services running.
-
I setup my home network as a whitelist and it was muuuuch easier than I expected. I guess it depends what you are running though. I'd say half of the multiplayer games I play require a new port or two. Certain services like torrents require practically every port.
Where did you start/ what method did you use to whitelist the high ports?
Just trial and error and looking at the logs? I'd certainly be interested in doing it myself if it isn't that difficult.
Yeah, pretty much. A quick glance at my port aliases seems to show that that I only had whitelist maybe 20 ports. That number has been slowly increased over the course of about a year to include services for visiting familiy members & friends and 2 or 3 additional services I added. So I think I initially had to whitelist like 14 ports for all my devices to operate seamlessly?
Whitelisting was mostly done as a learning experience, so in some ways I wanted it to be kinda tedious but it wasn't.
Discouraging illegitimate & malware services was a factor in choosing whitelisting but it's also useful being more aware of the types of legitimate services running.
20 ports overall, or 20 named ports (i.e., <1024)? I've only been using pfSense for about 10 days and my list of allowed WAN ports was the following:
Out WAN Ports Out WAN Name 21 FTP 22 SSH 25 SMTP 37 TimeServer (Obsolete, but needed for TiVo) 43 WHOIS protocol (If you use a WHOIS program to attain host records) 80 HTTP 119 NNTP 143 IMAP 443 HTTPS 465 SMTPS 587 SMTPS 990 FTPS Protocol (control), FTP over TLS/SSL 993 IMAPS 995 IMAP 3478 Steamworks P2P Networking and Steam Voice Chat 4379 Steamworks P2P Networking and Steam Voice Chat 4380 Steam Client 5055 Golf With Your Friends 5058 Golf With Your Friends 5222 XMPP 5223 TiVo 5228 Google Play Store, Talk, Chrome 6667 IRC 6697 IRCS 7287 TiVo 7288 TiVo 7680 Windows 10 Delivery Optimization Service 8078 TiVo 8079 TiVo 8080 HTTP Alt 8081 TiVo 8082 Gremlins Game 8181 TiVo 8443 CalDAV 8843 CardDAV 13000 Uplay 13005 Uplay 13200 Uplay 14000 Uplay 14001 Uplay 14008 Uplay 19302:19309 Google Hangouts 27000:27037 Steam Client 8500:8599 Gremlins Game 8800:8899 Gremlins Gameand my list of allowed LAN ports was bigger. That's 255 open ports and the time associated with looking through the logs when the wife complained as she was trying to get into some game tournament or another, and then trying to confirm what I was seeing in the logs on the game forums (most of whom don't bother listing ports or servers). It just got old, fast. From a security POV, I'd have preferred whitelisting ports. But, this is not a full-time job I'm paid to do. It's just me keeping the home network working.
-
20 ports overall, or 20 named ports (i.e., <1024)? I've only been using pfSense for about 10 days and my list of allowed WAN ports was the following:
and my list of allowed LAN ports was bigger. That's 255 open ports and the time associated with looking through the logs when the wife complained as she was trying to get into some game tournament or another, and then trying to confirm what I was seeing in the logs on the game forums (most of whom don't bother listing ports or servers). It just got old, fast. From a security POV, I'd have preferred whitelisting ports. But, this is not a full-time job I'm paid to do. It's just me keeping the home network working.
20 ports overall. I'm only referring to white-listed LAN ports. All WAN ports are blocked.
For dedicated gaming devices, I'd probably lazily resort to UPnP on the WAN ports.
-
Wow, thanks for the info I might have to give it a shot.
I envisioned hours looking through logs and constantly coming back to it as different things didn't work.
