1 to 1 NATing on ASA

Phase: 5
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
static (FSMLAN,FSM) interface 10.1.1.2 netmask 255.255.255.255
  match ip FSMLAN host 10.1.1.2 FSM any
    static translation to 0.0.0.0
    translate_hits = 0, untranslate_hits = 39
Additional Information:

Translation to 0.0.0.0 doesn't look right.  You showed two config lines - the first was your general nat/pat for outbound internet (I assume)
nat (FSMLAN) 1 10.1.1.0 255.255.255.0
and the second is the static nat
static (FSMLAN,FSM) interface 10.1.1.2 netmask 255.255.255.255

What is the global nat line? If they are both using interface, this won't work. You would have to create a static PAT instead of a 1-to-1 static nat. Also, in your ACL I would be more specific - the source can be any, but the destination should be specific.

On a side note, sometimes packet-tracer doesn't do the best job, so if that's the only method you've used to test, you may want to try having someone on the outside actually attempt a connection while you use the real time log viewer to look in to this matter.

I'm trying with static entries instead but no luck yet...

oncallnetworks# show run global
global (outside) 1 interface
global (FSM) 1 interface
oncallnetworks# show run nat
nat (inside) 1 172.16.1.0 255.255.255.0
nat (FSMLAN) 1 10.1.1.0 255.255.255.0

static (FSMLAN,FSM) tcp interface 6443 10.1.1.25 6443 netmask 255.255.255.255

I should clarify, I have 2 WAN ports on the firewall

1 for surf traffic, 1 dedicated WAN for an internal server.

FSM - dedicated internet

From what I can see, you have at least 4 interfaces - inside, outside, FSM, and FSMLAN. The RPF check essentially makes sure that the source IP address of a packet entering an interface is valid on that interface. This means that if you have an interface (FSM) that receives a packet with a source of 1.1.1.1, but normal routing would use the outside interface to reach 1.1.1.1, this is an RPF failure because the reverse path can't use the interface the packet was received on originally.

In your packet-tracer, if the FSM interface doesn't have a route to use that interface to reach 208.67.222.222, this will fail regardless of NAT.
Also, since you are using the "interface" in your nat statement, the destination of the packet needs to be that of the interface itself. So if, for example, your interfaces were
FSM: 192.168.1.1/24
FSMLAN: 10.1.1.254/24

then the packet-tracer command would be
packet-tracer input FSM tcp 192.168.1.100 55005 10.1.1.254 8443
-or-
packet-tracer input FSM tcp 192.168.1.100 55005 10.1.1.254 6443

The source address needs to be within a subnet that that is normally routable through the receiving interface, and the source port can be random unless the source is specified via ACL. The destination is the address of the interface itself (not the host it will be translated to) and the destination port must match. In you postings you used ports 8443 and 6443.

I would also make your interface ACL reference the specific host IP address in the destination. In your case the destination host IP is the interface's IP address.

OK that makes more sense,

After a quick lookup I've discovered that ASA's don't support Policy based routing, so effectively I can only have a single NAT pool. So my multiple interfaces won't work with NAT because it gets confused and sends stuff out the wrong WAN interface.

GRRR

Looks like I have to go back to the drawing board.

thanks!

Just to clarify, you can use both interfaces, just not simultaneously. Automatic failover can be configured without too much effort.
To use them simultaneously would require you to have some sort of policy routing happening before the traffic gets to the firewall (via router or L3 switch), and then the firewall would have to be configured with multiple contexts (virtual firewalls) to use both wan links simultaneously. That config can get very complex and confusing. I don't recommend it.