I haven't personally had to do this but I believe you can accomplish what you want by creating a new Alias:

Under "Firewall->Aliases" click on the "+" to create a new alias.
Give it a Name then add the IP addresses in the Host(s) section by clicking the "+" to add new host addresses.
Click "Save"
In your NAT rule change the Destination Type to: "Single host or alias" and type the alias Name you created above in address
Click "Save" and "Apply Changes"

That should do it, unless I'm totally wrong (which happens often enough  :o ) and some brighter soul than I will save you  ;)

If you enable manual outbound NAT, you can specify a rule on the LAN interface that changes anything destined to 192.168.4.80 to use the LAN interface address or a VIP. Just like creating a manual WAN rule. I really think the other way would be less "complicated". It up to you.

"simply because it's rather common to obfuscate configuration information when posting to public forums."

Not when its rfc1918, and if you did want to hide it a bit showing 10.x.x.250/16 would of shown its private space, etc. and a different network.

" I've had to set up NAT"

Out of the box nat would be active - you should not have had to do anything..  If you did, seems you might of done it wrong.

Out of the box public IP on wan, private on lan there would be nothing to really setup.  Bing bang zoom up and running.

I would suggest checking for host firewalls - but you state "no traffic is being passed to the internal host on the LAN segment."

Your 80 is bad example if your running web gui on that port on pfsense..  I would check with ssh, so from outside you see packets at wan but nothing leaving lan interface..  Then you got a configuration problem with pfsense.  Is your nat set to automatic?  You mention you can ping hosts from pfsense and see packets from wan..  Are hosts actually using pfsense for internet and their default gateway?  And this is working?  If clients are pointing to pfsense as their default gateway then your forwards are not going to work because of asynchronous routing

But you say your not seeing the packets even go to the client when you sniff on the lan interface of pfsense?  So couldn't even be that.

Do you have as well a DHCP available to you from your ISP?

If so you could create a VIP for the static and then 1:1 it to your desired server. Otherwise as said- just port forward your mail ports.  :)

Using your firewall as gateway and using transparent proxy are easiest ways but all depends on what exactly you are trying to achieve. If you can provide some more details, you may get more comprehensive replies.

I don't know. In my setup NAT between IPs on the same interface wasn't necessary. As I know it would not work if the NAT IP is bound to another device. But maybe it works for localhost.

Basically, it should be doable to bind local services at IP aliases.

Thanks for the additional ideas.  I have a comcast cable modem, not a DSL service so I ma not sure if this will apply.  I have tried looking around in the modem and I could not find any of the settings that you mentioned.  That could mean that they do not apply or I just do not have access to see them on the customer side.

At any rate, since I could not get pfSense to completely work with my environment I have stopped using it and I now just have Ubuntu server with iptables running with my own rule set and everything is working fine with that.

I just have tested from another location.
There I do get the web interface for the DVR..

From multiple connections I cannot reach the DVR, and from some locations I can…

Someone has any ideas?

Sounds like you're doing things right. The scenario you described will work fine. I think the most likely issue is pfblocker's data is something like 2 years old at this point, the package maintainers stopped updating the list a couple years ago when countryipblocks.net discontinued their free lists. Use a better data source (like a paid subscription to countryipblocks.net) and I suspect it'll probably work.

We'll be putting out a better alternative in the not too distant future for country IP lists, that's something you'll want to keep an eye out for. (subscribe to announcements list @ lists.pfsense.org if you haven't already)

I've heard of such horrid scenarios in industrial automation. Apparently with some SCADA systems the world will come crashing down if X PLC isn't 192.168.1.10, Y HMI isn't 192.168.1.20, or what have you. Absurd, but SCADA is full of network and (in)security absurdities.

It's not possible to have one machine with duplicated IPs existing simultaneously on multiple VLANs. You want to talk to 1.2.3.4 which is NATed to 192.168.1.10, there can only be one 192.168.1.10 as there is no possible way to differentiate which 192.168.1.10 you want - the NAT happens purely at layer 3.

VMs (in a production server-grade hypervisor, not VirtualBox) could work. Multiple physical boxes would work.

Hello everybody,

Thanks a lot for this post, it finally worked great for me too !!!  8)
Never have guessed it could deal with LAN gateway… Very good job !
Does anybody know where this behavior come from ? What's the link between LAN GW and NAT Reflection ?  :o
Thank you for your answer... and the fix !

Pierre

It depends on what the application expects from the NAT. PfSense by default allocates a new source port at the WAN interface for each new outgoing (LAN to internet) UDP connection. This apparently breaks some applications that expect that each client IP-source port pair on a LAN host would retain the same port number on the WAN interface for all outgoing traffic that comes from the same client IP-source port pair, in addition solving collisions automatically between clients that use the same source UDP port (I believe this is what is called "cone NAT"). The solution on pfSense is to use static-port on outbound NAT but it has limitations, you can't then have two hosts on the LAN use the same source UDP port for outgoing connections because they would collide on the WAN interface.

Apologies, All.

I'll need more time to test. I don't think I'll be able to get back to this and/or provide logs until this weekend.

I'll reconfigure my local pfSense so that there is a spinning disk device to which it can log. I'll then look at what's going on.

I do have a very large pfSense built out of an Dell 1850 Series 2 at work. It is an egress router for our 100Mb/s service in front of 6 TMG Gateways. It does have 2 of it 5 nics configured for NAT, however nothing is currently attached - they are for testing. I'll attach a simple linux device [likely CentOS 6.5x64] to it tomorrow and see if I have trouble rsync'ing there. I was going to complain and say that rsync works through the Dell 1850-pfSense [and subsequent TMG firewalls], however its configuration through which I'm rsyncing at work, is only routing, and not NAT. I need to test rsync through NAT.

Again my apologies. I'll have some relevant testing for you guys to look at either tomorrow night, or this weekend.

Thanks for your patience.

Ryan

Yes finally got it working. Thanks a lot.