Why can't I query SNMP, use syslog, NTP, or other services initiated by the firewall itself over IPsec VPN?

From PFSenseDocs

With an out of the box configuration, you cannot query SNMP on the LAN interface of a remote pfSense over a VPN connection.

Fred Wright explained in a post to the m0n0wall mailing list on September 12, 2004 why this is, and it's the same reason in pfSense.

Due to the way IPsec tunnels are kludged into the FreeBSD kernel, any traffic *initiated* by m0n0wall to go through an IPsec :tunnel gets the wrong source IP (and typically doesn't go through the tunnel at all as a result). Theoretically this :*shouldn't* be an issue for the *server* side of SNMP, but perhaps the server has a bug (well, deficiency, at least) where it :doesn't send the response out through a socket bound to the request packet. You can fake it out by adding a bogus static route :to the remote end of the tunnel via the m0n0wall's LAN IP (assuming that's within the near-end tunnel range). A good test is :to see whether you can ping something at the remote end of the tunnel (e.g. the SNMP remote) *from* the m0n0wall. There's an :annoying but mostly harmless side-effect to this - every LAN packet to the tunnel elicits a no-change ICMP Redirect.

To do this, click "Static Routes" in the webGUI. Click the + to add a static route. In the Interface box, choose LAN, for destination network, enter the remote end VPN subnet, and for the gateway put in the LAN IP address of your local pfSense.

If you are just looking to do a quick test with ping from the console or ssh, you can adjust the ping source to enable traffic to traverse the tunnel like so:

ping -S <pfsense LAN ip> <remote IP address>

So if your pfSense LAN address is 192.168.1.1, and that IP is a part of the subnet defined for the IPsec tunnel, and you want to ping 10.0.0.1 on the other side, you would do this:

ping -S 192.168.1.1 10.0.0.1