Well, I made progress, but I believe that I do need ICMP to be routable from both the Internal and External interfaces to the DMZ server.  I simply don't see a way to do this with port forwarding, while 1:1 NAT creates issues with SIP and the source address of the DMZ server when communicating with Internal network devices.  I'm just going to use a different router until I can figure this out.  It's a shame that testing on this particular deployment requires as much preparation and down time as it does.  It may be that I can do this by editing IPtables directly, but i'm not sure when I will be able to spend more time testing. Thank you for the advice.

I seem to remember that there were PPPoE problems in an early 1.2 version. Update to 1.2-release or one of the 1.2.1RCs and see if your problem goes away is my best bet.

You are going to have to give a bit more detail on this if you want someone to help. Do all port-forwards from all secondary WANs initally work, but stop working? What do you see in the logs when the port-forwards stop working? What do the state tables look like? What you are saying doesn't make any sense logically. BTW- you should not use registered ports for external port shifts. (tcp/udp 2000 is Cisco SCCP.)

i'm having the same problem. when i entered the proxy manually (3128), it can be done. but when i use the redirect rules NAT for LAN interfaces from 80 to 3128, seems to be unresolved web. hiks…can anyone help me?

Ok. Problem solved (in part at least). I've disabled NAT reflection, created some DNS forwarder and Port forward entries and it works as expected. Well, the only drawback is not being able to ping server from LAN, but it should be enough. BTW. I've encountered strange thing (bug) in Firewall Aliases. As all of us I'm lazy so I tried to create alias for all ports my server should provide and then create just one Port Forward entry using alias created earlier. But it didn't work, I couldn't connect to server. So I've removed alias and created 5 separated entries in Port Forward (one for each port) and it works! Is this a bug or just my misunderstanding what is a purpose of port aliases? BTW2. I've encoutered another problem with strange HTTPS lags which I describing here: http://forum.pfsense.org/index.php/topic,12343.0.html Best Regards, motzel

http://forum.pfsense.org/index.php/topic,7001.0.html NAT and firewall are separate rulesets. So yes if you delete the "allow all" rule you block everything. Although i dont think 1:1 NAT is easier. 1:1 NAT approach: 1: set the 1:1 mapping. 2: create an alias containing all the needed ports. 3: create a firewallrule allowing the alias for the server in question normal port-forward approach: 1: create an alias containing all the needed ports. 2: forward the alias to your server ports. The corresponding firewallrule gets autocreated. 3: enable AoN and set the outbound mapping. You just the do "about" the same thing at different places. IMO the second is "better" because it works with NAT-reflection (see link above). Also you dont forward everything per default leaving the option to use a single IP for multiple Server.

@GruensFroeschli: If you can access it via a browser, the portforward itself is working. –> Not a problem on the pfSense side. Doublecheck if your client is correctly configured. I did that yesterday (rebuilt the client) and it didn't make a difference. I tried AGAIN today, and guess what, it started working again. I am not sure if a patch was applied to the client overnight to fix something. The fact that the repository was accessible by the browser and not via a client made me think that the client used a different set of HTTP methods to get to the repository. In any event, thank you everyone for your help, I appreciate everyone's input.

firewall–>NAT

I found the solution : I checked "Bypass firewall rules for traffic on the same interface  " under "System /advanced"  ,now all the different subnet can communicate .

You cannot have a /32 as WAN (unless you have PPPoE WAN). And from what you desribe it seems that you just can use the 24.x.111.143/29 block. You could go with the "transparent bridge" approach where the pfSense has no IP out of this range. In fact the IP you have on the pfSense is only to manage it. The clients have then public IP's out of your usable range. They have the gateway you have now on the pfSense directly. –> The will not send traffic to the pfSense and pfSense will not NAT it. Make sure you set the correct gateway and the correct subnetmask (are you sure you mean 255.255.248.0? this is a /21 subnet instead of a /29 --> 255.255.255.248) Search the forum and the tutorials on how to set this up.

It won't delete any rules already there but if AoN is enabled no rules will be automatically generated for new LAN type interfaces, just like it states.

Take care! What routers like the afore mentioned do with one of the hosts on a switch port is far from being a DMZ! This is called an "Exposed host". Only SOHO marketing calls it a DMZ… Once you have a host exposed to the untrusted network (internet) completely, this machine can be compromised. Since it resides within the other machine's subnet it can easily spread malware or access other resources on your LAN. Make sure this host is really safe and locked down… An option you could choose is to get a VLAN capable switch and define virtual subnets. This way you can setup a real DMZ and filter or block traffic between your subnets. Wikipedia has an article about it: http://en.wikipedia.org/wiki/Demilitarized_zone_(computing) but the german article describes the "exposed host" way better (it isn't mentioned in the english version at all...). http://de.wikipedia.org/wiki/Demilitarized_Zone

Thank you for the layout, in the mean time: Figured it out, evidently VMware infrastructure WON'T work on a NAT'd port forward!  So in order to make it work I either have to build a VPN, or give up an external IP (yuck!), unless someone has a bright idea. mckoz

Similar problem here. I'm running pfSense 1.2.1 live from the CD as a test, in hopes that it can be used more permanently. I've got an alias defined that contains the same ports (80,443,3389), and in the same order.  80 is the first port defined in the alias. I have a NAT rule using this port alias that has automatically created a firewall rule for me, and… this rule works for me over port 80, but not over port 443. If however, I add an additional NAT rule that specifies port 443 instead of referencing my port alias, and give that rule higher precedence over that of the rule using the port alias, my test is a success... even across port 443. I too would like to know if I have overlooked something. Any suggestions you can offer are more than welcome. Thanks

OK… I'm a moron... I looked a little closer and realized that the servers that I was attempting to connect to using a NAT defined on PFSense1 had PFSense2 defined as the gateway (both have IPs on the same subnet).  (that may cause some arp issues).  Given the fact that the inbound and outbound traffic is taking different paths and ending up on different interfaces on the PFSense box providing NATing services, I'm surprised that the SYN/ACK was ever received and that the session established. I additionally corrected the Static Routes to NOT include any locally attached subnets. After taking these two steps, the NATs work as expected. Brian

I never actually tested this. I "think" if you create an "advanced outbound NAT" rule that NAT's from the WAN to your LAN it should rewriting the source.

@GruensFroeschli: Are you talking about a bridging firewall or about a router without NAT? first case: no second case: yes I was thinking about bridging but you've convinced me to do it by routing! :-) Thanks a lot, GFK's