@PiBa is correct. Snort can't see the encrypted traffic (well, not in clear-text form). Snort uses PCAP, and you can envision it as getting a copy of every single packet that traverses the NIC. Snort is the first thing a packet sees after coming off the wire going through the NIC inbound into pfSense, and Snort is the last thing a packet sees before leaving the NIC on the wire outbound for the Internet. That description assumes Snort is running on the WAN.
If it helps in understanding the flow, just remember that Snort sees exactly what the NIC driver sees -- raw packets coming and going off the wire. For inbound traffic coming from the WAN into pfSense this means before the firewall rules have been applied and any NAT removed (thus the "destination IP" will always be the WAN IP address). For outbound traffic going out on the WAN, Snort sees the traffic after the WAN firewall rules have been applied and NAT put in place (so the "source IP" will always be the WAN IP address).
So generally I recommend running Snort on the LAN interface so that the NAT stuff is not masking internal hosts. It's not helpful to have a dozen alerts from internal hosts attempting to communicate with a malware C&C server but all the alerts showing up on the WAN with just the WAN IP address as the source IP due to NAT. Much easier to find the infected hosts when Snort is on the LAN and the alerts have the actual pre-NAT source IP addresses of the infected hosts listed.
EDIT: for others reading this in the future, I need to add a clarification to the flow description above. Snort is getting copies of packets coming from and going to the NIC driver. It is not inline, but rather is on a parallel path so to speak. The original packet continues on to pfSense for processing while a copy of the packet is passed over to Snort for it to analyze.
Bill
