So there are a few things going on here which, I think, are causing confusion.
First, what Snort means by source and destination. While Snort does have the capability to keep some state information for stateful inspection (called flowbits) the signatures are processed against individual packets. This means that the source and destination do not map to client and server, they map directly to the source and destination address fields in the IP header. So that means that the specific packet that caused this rule to fire had 192.168.5.15 in the destination address and 22.214.171.124 in the source address. We're talking about a single packet here, it has nothing to do with who initiated the session.
Second, your NAT device is doing more with UDP than you think it is. TCP is easy. It's a connection oriented protocol. The whole design is that you negotiate a communication session, chat for a while, and then say goodbye. The whole process is very well defined, and the NAT devices follow those standards. They see your SYN go out and add an entry to the xlate table, then the xlate entry gets deleted when the FIN+ACK comes back in, or a FIN+RST goes out, or enough time passes.
UDP, being connectionless, is just fire and forget. The whole idea is that the application either implements it's own handshake and/or retransmission system, or it doesn't need them. So you would assume the firewall would allow your UDP packet to go out, but any response would get blocked. Except it doesn't. Your NAT device knows that even a connectionless protocol like UDP frequently has two-way communication. As such it will insert xlate entries for outgoing UDP traffic just like it would TCP. The rules are a little different, for instance I would expect the entries to time out on a different interval and only be deleted when they time out.
Thirdly, this alert is probably being triggered by the sfPortscan preprocessor for Snort. In a tightly restricted environment I can see it being quite useful. Otherwise it can be quite noisy. The problem lies in the types of detections that it performs
- TCP/UDP traffic where one host talks to one host and hits many ports
- TCP/UDP traffic where many hosts talk to one host and hits many ports
- TCP/UDP/ICMP traffic where one host talks to many hosts on a single port
Largely because of the #3 this alert can be triggered by just about any system that's actually providing a service. For some reason Windows SMB fileservers seem to be the worst offenders for false positives.
Now here's where things get fun. Let's assume configurations (server, network, and firewall) are all good. In that event, chances are, your file server initiated communications with the outside IP. Then the return communication triggered the sfPortscan preprocessor which caused pfSense to display an alert. This is probably a bad thing. Were I you I would start a packet capture for anything to/from your file server and an external address. Then you can start reviewing the packet captures and try to figure out what's going on.