NAT Reflection status?

[sporkme]

I think I pretty much understand how the reflection options are supposed to work, but I'm having issues (2.1.4) and I'm wondering if there are any caveats that I don't know of.

Currently, I'm able to get reflection working only with the proxy option.  I do not want to use this option for two reasons:

•It appears all external traffic passes through the proxy
•All traffic appears to come from the proxy, so any services that log a source address no longer have the "real" source, everything appears to come form pfsense itself

Two things that I have configured that I'm not sure are compatible with the standard reflection rules are using virtual IPs for the NAT rules (additional external addresses - "if alias" type) and a legacy bridge interface I'm trying really hard to get rid of (chicken and egg problem - need to get NAT working before I can yank the bridge interface).

When I initiate a connection from inside to a service that's forwarded on the outside with "pure nat" reflection enabled, I see no packets blocked in the firewall logs.  For state entries, I see the following:

Proto	Source -> Router -> Destination	State	
tcp	192.168.11.102:22 <- x.x.x.222:22 <- x.x.x.211:55418	CLOSED:SYN_SENT
tcp	x.x.x.211:51893 -> 192.168.11.102:22	SYN_SENT:CLOSED

x.x.x.222 is an alias on pfsense's wan interface
x.x.x.211 is the wan interface's main IP
192.168.11.102 is the port forward target IP

Not seen there is the connection source, which is 192.168.11.101.

If I'm reading this right, there's no state being generated from 192.168.11.101 to the ultimate destination after NAT of 192.168.11.101, and the state entries shown above represent the destination (192.168.11.102) reaching back to pfsense's main WAN IP and the second state entry is likely the already-translated source IP hitting the destination.

What's going wrong in this scenario?

Is my bridge interfering in some way?

Is reflection not supported with if aliases?

What else can I do to troubleshoot?

[sporkme]

Hmmm…  Maybe I'm on to something here.

If I run tcpdump on the bridge interface while attempting the connection, I see this:

16:33:25.603399 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.x.x.222 tell 0.0.0.0, length 50
16:33:26.714153 IP (tos 0x0, ttl 64, id 12716, offset 0, flags [DF], proto TCP (6), length 60)
    x.x.x.211.59721 > x.x.x.222.22: Flags [s], cksum 0x210a (correct), seq 2823335170, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 753592721 ecr 0], length 0
16:33:29.914115 IP (tos 0x0, ttl 64, id 12731, offset 0, flags [DF], proto TCP (6), length 60)
    x.x.x.211.59721 > x.x.x.222.22: Flags [s], cksum 0x148a (correct), seq 2823335170, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 753595921 ecr 0], length 0

So it looks like my reflections are reflecting, but rather than the packets hitting the virtual IP, they are heading out the bridge.[/s][/s]