FYI,
          I found the issue. There were actually a few different problems.
First, The webserver was referencing both private and public ip addresses that correspond to the private ip.

Second, The firewall does not support NAT reflection unless you utilize port forwarding.

The fix was easy. I setup all services to use port forwarding and enabled nat reflection under advanced options and also
modified the lan rule source to * (any) to fix the problem.

What gave it away was that the webserver (with ipcop in front of it) could access webpages via the public ip.
and with pfsense it could not. PFsense does some actual sessioning versus ipcop providing only basic nat.

PFsense was not the issue!!

For future reference, I added some information on this to the FAQ section of the Doc Wiki

http://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F

No, just the one box, the two points on the ascii diagram were the two 'interfaces' of the 1 pfsense box.
I have the vpn access to allow two computers to connect up remotely and talk to each other but not to my lan.
the idea with the nat was to create access to a service on my lan without giving them full lan access, and without requiring them to use me as a default gateway.

here is a screen shot of three rules. I used telnet in this example. The top rule works from my wan IP but then everyone could access it.
The two rules below don't seem to work

nat.PNG_thumb
nat.PNG

i've experienced exhausting our state table before and we have found the culprit. it was a ddos attack on port 445. ever since we disabled port 445 on our windows systems, state exhaution never happened again. it somehow cured the problem but the internet connectivity would still get interrupted occassionally. this gave me doubts on NATing a large network. the only solution i do for now is to reset the state table although it never even consumes half of the maximum that i set.

doh! You are absolutely correct. All the instances where I (incorrectly) thought this was happening has squid installed.

That reflection stuff is hard …
http://forum.pfsense.org/index.php/topic,14572.0.html

I did this and now it works fine…

http://doc.pfsense.org/index.php/Static_Port

I find it.

/etc/inc/filter.inc

add $rules .= "set timeout tcp.established 3600\n"; and $rules .= "set timeout tcp.closing 60\n";

before line $rules .= "\n";

/* User defined maximum states in Advanced menu. */ $rules .= "set limit states {$config['system']['maximumstates']}\n"; } $rules .= "set timeout tcp.established 3600\n"; $rules .= "set timeout tcp.closing 60\n"; $rules .= "\n";

and DC, eMule, uTorrent works well.

More info:  The change that is doing it is when I switch the default LAN -> Any firewall rule from the default gateway to the "WAN1 -> WAN2 Failover".

You can only do that with ICMP and NAT when using 1:1.

They don't differ. They're doing exactly the same thing, and what you're describing different between the two can't happen.

Thanks for the reply.

I believe that I need both interfaces, as the gateway for each IP range is different.  I'm unsure of how a virtual IP would work when I need those IP's routed to a different subnet, even if it's on the same interface.

I got the 1:1 NAT's working last night by playing with the firewall rules a little more.  I now have a setup where I have some 1:1 NATs and also have Advanced Outbound NAT set up.

ASCII Art

WAN1–\              /---DMZ
            \          /
            PFSENSE----LAN
            /         
WAN2--/              ---WIFI

I had the same problem. I solved in another (very unclean and unsecure) way.
Just now I were looking around for some suggestion :-(

Anyway, this is my solution:

You keep in your LAN a PC with the fixed IP address and choose netmask and gateway
(eg 10.1.1.1/30 gw 10.1.1.2).
Assign the gw IP as the first address of the firewall LAN interface.
Assign to the same interface a second IP address for others LAN client, and configure firewall and nat rule accordingly (looking around you can find a step by step document about).
Create the tunnel as usual, then you can connect (only) from the PC to the remote LAN.

Ugly but working.
If someone have a better idea….