This without context is meangless to PF users. If you want people to examine your PF configuration, post it.

Quote:

Is there a way (tool) to test if this connection is working?

If you, yourself, do not have a remote system with a shell account to test from, you can use remote scanners such as "ShieldsUP!" which is operated by Gibson Research (grc.com). This will tell you if the TCP or UDP port you are interested reflects what Gibson Research defines as "open" "closed" or "stealth", depending on positive, negative, or no response from your server.

Quote:

plus is it possible to only allow this port for this one remote server?

These two rules are in the wrong place, they appear before your Options section. If they were supposed to apply, they are negated by your very first rule in your filtering section, which is "block all":

Remember how filter rules function: Without "quick", the last matching rule wins. And,avoid using "quick", if you can, as any time a quick rule matches, no futher packet matching is done.

This appears to be an end-system firewall as only an external NIC is mentioned in your rules.

If no previous "quick" rule has inadvertently matched, then this is the last rule that will match an inbound TCP session for a local daemon listening on your single NIC to TCP port 5524:

Code:

pass in on $ext_if inet proto tcp from any to any port $tcp_pass flags S/SA keep state

The subsequent pass out rules will not apply, as PF will use the existing state table for the entire time the TCP session remains established.

The most effective way to analyze your rule set is to watch it perform, using pflogd(8) and the pflog(4) facility with a network monitoring tool such as tcpdump(1). You'll need to add the log option to the rules you want to track, of course. This particular rule does not have the $logopt macro in it.