hmm, strange, since the wan link is physically always up, its either the ppp session that dies, or an upstream router, so that there is no more dataconnectivity, but physical link stays up.

Offcourse, if bsd looks at the PPOE session, than that could be the cause.

Anyway, i can live with it untill 2.0 comes out.

Firewall rules determine that. See the multi-WAN chapter of the book for more info. http://pfsense.org/book

The FTP will be that way because that's how PF's FTP proxy functions.

Web traffic will never show up like that, short of having a package installed that proxies it (haproxy being the only one right now that would do so).

How i missed that I just dont know.
All sorted TY.

Yeah that's wrong, changed that, thanks.

Outbound NAT has nothing to do with port forwards, don't change it unless you have a reason to do so.

Use Diagnostics -> Packet capture to see where the traffic goes/doesn't go.

You can specify ranges of VIPs only with PARP.
THis can be usefull if you want to 1:1 NAT map a whole range at once.

But usually you define VIPs for such an usage how you want it as single IPs.

You can also not use aliases in the Advanced outbound NAT rules :(

Can you show your NAT rules?

This is currently not possible.
If you want to forward from a external portrange to different internal portrange you will have to stop using aliases and create "normal" portforwards.

What exactly do you mean with
"I was not sure how to route the traffic on the second server to make sure that it gets the correct IP" ?

Do you want to know how set up the pfSense, so traffic from the second server appears as if from the second IP?
Or do you mean: that if a request from the second IP arrives, the answer leaves via the correct interface?

Answers to inbound requests to the second IP will always leave via the correct interface.

For outbound traffic go to:
firewall –> NAT --> outbound and select "manual outbound rule generation".
Below should a rule be autocreated for the primary WAN.
Create your own rule above this default rule with as source your server IP (x.x.x.x/32) and as NAT-IP the IP of your second interface.

Forward port 80/TCP (and possibly 443/TCP) on each WAN interface to 10.0.0.100.

You should move the webGUI to a different port if you want to have 443 for your webserver.

Yes "External port ranges" is the destination port in the packet going to the pfSense from the outside.
The pfSense then rewrites it to whatever you define and sends it to your server.

I got this fixed. I had setup a rule pointing to the wrong IP. All good now.

You either have the whole webinterface on https or http.
Not both.

Well, the packet capture was very enlightening.  It showed, well, no packets at all.  A little detective work with alternate ports indicates that my lovely ISP is blocking port 80, despite allowing port 25 and being a commercial connection.  Changed to another port number and everything works as it should.  As for the original issue with the VNC ports, I suspect there was a separate issue there as well.  I'll consider this mystery solved.  Thanks for all your time and effort, it certainly did lead me to the solution.  Port forwarding works just fine, as long as the packets actually get there!