You would need a reverse proxy in order to do that. There are a couple packages for pfSense that may help (mod_security, for example) but nothing with NAT alone can do that.

Thank you. It has worked. :-) I

I'm not sure about 1.2.3, but if you activate AON in 2.0 you will see all of the auto-created rules and NAT function won't change until you start editing those rules.

dc server just allowes everyone to connect all the work on the share loke shareing etc gets done by client softwer server is just to get everyone talking to one another but ill try it on another pc and os

all are on defualt havnt setup any rules as of yes  ill disable it and test it to see what happens

Dears, it is my fault, dont  apply my public ip alias.

You have to enable NAT reflection for you to get to internal IPs using the External IP from behind the firewall.

Which service are you using to setup the GRE tunnel?

Could you post a screen shot of your manual outbound rules?

The outbound nat is the last rule applied to the package. First you define rules and if you need to Route the packet to a different route, you define it in advanced rules options. When packet is leaving pfsense by interface x ou y, then outbound nat is applied if defined.

@sriraminfotec: thanks for the response. Now is there no other way of getting authentication ? The DVR does not have much security and the password can also be easily changed. When you mention outbound traffic, does not CP treat the traffic moving out of the DVR as outbound ? Well for authentication or restricted access you have a few options Get a new DVR that supports better Access Control List (ACL). Use VPN in conjunction with pfsense. Restrict inbound traffic to the DVR to a few known fixed/statics IP addresses. It may not be ideal but a workable solution. The DVR will not initiate outbound traffic on its own unless it is going out to get software update checks or some function like alert notification, etc.  All firewall/proxy knows or keep tracks of who starts the traffic (this is why they maintain state).  In your example, the outbound traffic from the DVR was initiated by someone from the inbound (outside the WAN link), so the initiator is from the inbound side.  To help you understand more of the inbound/outbound traffic, think of it as who started the request for the traffic, is the request started by someone/devices from the WAN (that would mean inbound) or someone/devices from the LAN (outbound). Hope this helps.

Hi Thanks for your replies. I could get it up and running.  Of course, I did a factory reset also. I just added an alias for the ports needed by the dvr. When to NAT port settings and did the rest as per Metu69 advise. Only I used the alias for the ports. The Source was any. It started working like a charm. Now I wanted to have captive portal so that any one accessing the DVR from the remote using the dynamic dns address should be presented with a login screen for access to the dvr. But I think this is not possible. Somewhere else I read that this is called reverse captive portal. I am not sure so I request others not to take this as the last word on CP. Please suggest how security can be achieved if not using CP. Thanks

Finally working. Thanks all for the help and guidance. In the postfix forwarder tab for Domains to Forward, I had listed the exchange server and its internal IP, which was exch.domain.com. The not relaying error finally clicked with me that the mail was coming in as mail.domain.com. So I added that with the same internal IP to the Domains to Forward and things began to work. For good measure I added the root domain also. I am still having odd issues which I'll take to an exchange forum. I'm jazzed about pfSense, and hope to use it more. Great work!

@jimp: With pass, the traffic will pass that matches the NAT rule exactly. Some people prefer to have more fine-grained control over who/what is allowed to reach systems to which ports are forwarded. If it's a web server that the world can access, then pass may be OK. If it's a private system locked down to only a few remote IPs, then someone might want to add the nat and firewall rules separately and come up with a more complex set of rules to control access. Thanks.  That really clear up my understanding on how the two features works.

Thanks!

Is there a reason you want to NAT between the DMZ and LAN, rather than just straight routing? There's no reason the LAN hosts and DMZ hosts shouldn't be able to find each other via default route (pfsense). You only need outbound NAT for LAN via WAN.

IMO, I would use CARP. The reason why is that you can setup clustering later if you use that type of VIP. If you plan to never cluster, then ProxyARP or IP alias works really well also. If clustering is a possibility, it takes 3 public IPs to do that, so start using IPs at the end and work backwards asigning them.