pftop output (copied from web UI) filtering on ICMP and showing pings going to 2.222 from pfSense and from a VPN client. (the pings from pfSense would work if there was something there to talk to).:
pfTop: Up State 1-4/4 (614), View: default, Order: bytes
PR DIR SRC DEST STATE AGE EXP PKTS BYTES
icmp Out 10.1.10.2:1487 10.1.10.1:1487 0:0 33:38:42 00:00:09 474338 13281464
icmp In 192.168.5.2:13206 192.168.2.222:13206 0:0 00:07:42 00:00:10 452 37968
icmp Out 192.168.5.2:13206 192.168.2.222:13206 0:0 00:07:42 00:00:10 452 37968
icmp Out 192.168.2.1:47732 192.168.2.222:47732 0:0 00:00:30 00:00:09 30 2520
Here it is w/ filter "net 192.168.2.0/24" without me doing anything:
code_textpfTop: Up State 1-2/2 (514), View: default, Order: bytes
PR DIR SRC DEST STATE AGE EXP PKTS BYTES
udp In 192.168.1.3:61633 192.168.2.101:161 NO_TRAFFIC:SINGLE 00:00:12 00:00:29 2 214
udp Out 192.168.1.3:61633 192.168.2.101:161 SINGLE:NO_TRAFFIC 00:00:12 00:00:29 2 214
Well lookie there, the cause of those lingering ARP queries! .1.3 is a Windows server; I guess it somehow heard that there was supposed to be a 2.101 somewhere and decided to start sending it SNMP queries? Go figure. Getting back on track...
Here's a couple of snapshots using the same "net 192.168.2.0/24" filter (I manually removed the .101 distractor, but it's otherwise untampered) showing me simultaneously trying to open a TCP connection to .2.222 from both the Netgate and the VPN client:
code_textpfTop: Up State 1-5/5 (509), View: default, Order: bytes
PR DIR SRC DEST STATE AGE EXP PKTS BYTES
tcp In 192.168.5.2:34340 192.168.2.222:22222 CLOSED:SYN_SENT 00:00:04 00:00:29 3 180
tcp Out 192.168.5.2:34340 192.168.2.222:22222 SYN_SENT:CLOSED 00:00:04 00:00:29 3 180
tcp Out 192.168.2.1:39581 192.168.2.222:22222 SYN_SENT:CLOSED 00:00:04 00:00:29 2 120
pfTop: Up State 1-5/5 (854), View: default, Order: bytes
PR DIR SRC DEST STATE AGE EXP PKTS BYTES
tcp Out 192.168.2.1:39581 192.168.2.222:22222 SYN_SENT:CLOSED 00:00:24 00:00:28 7 420
tcp In 192.168.5.2:34340 192.168.2.222:22222 CLOSED:SYN_SENT 00:00:24 00:00:21 5 300
tcp Out 192.168.5.2:34340 192.168.2.222:22222 SYN_SENT:CLOSED 00:00:24 00:00:21 5 300
I don't see anything wrong at that point -- it seems to claim that it's at least planning to forward the SYN from the VPN client. Any more ideas on how to get a closer peek at where it's being dropped?