LAN/DMZ NAT
-
I need for a server on the DMZ subnet to respond to clients on the LAN subnet on both the private IP address and a public IP address that has 1:1 NAT from the WAN. Port forwarding does not allow sufficient protocols to accomplish what I need. ICMP, for instance, is not an option. If I swap the DMZ and LAN interfaces so that I can configure 1:1 NAT from the DMZ (now the LAN, in function) to convert the public address to the private LAN address (now the DMZ, in function), I run into the problem where traffic originating from the server is converted to the public address when it reaches the DMZ.
How would one configure Pfsense to allow communication between the DMZ server and the LAN so that traffic originating from the DMZ retains the private address but traffic directed to the public address of the server is routed correctly, in a manner that allows for protocols other than TCP, UDP, GRE, and ESP?
I have done substantial reading and searching, and I have junked my earlier questions as I discovered the common answers to them. This is the distillation of the dilemma that I can not seem to get my head around.
Thank you for your patience. I realize that this question may seem idiotic or indicative of some very backwards reasoning. I would love to be set straight if it allows me to better understand the subject.
-
http://forum.pfsense.org/index.php/topic,7001.0.html
Enable NAT reflection.
However:
@http://forum.pfsense.org/index.php/topic:NAT-Reflection does not work with 1:1 NAT
http://forum.pfsense.org/index.php?topic=7266.msg41244
quote:
You most likely need to setup split dns or add a port forward on top of the 1:1 nat to invoke reflection. Reflection by default does not work with 1:1 nat's. So your most likely resolving the public IP address which will not forward back across to the 1:1 server.How to set up split-DNS with the DNS-forwarder in pfSense:
http://forum.pfsense.org/index.php/topic,9440.0.htmlI basically would ditch the 1:1 NAT and use normal port-forwards.
This might be an interresting read for you:
http://forum.pfsense.org/index.php/topic,12285.msg66822.html#msg66822 -
Thank you for the advice.
Given that I require port ranges well in excess of 500, is there an advantage to using NAT reflection rather than configuring duplicate port-forwarding entries for the internal and external interfaces? The server in question is a Mitel phone application server and is hosting several different applications with various and lextensive port and IP requirements.
Also, is there a way to forward ICMP or other packets without using 1:1 NAT?
-
Hmmm. From what you describe 1:1 NAT might be your only option.
Also if you are working with portranges over 500 i'd set up split DNS so your internal clients can access the public address directly with the private IP.No. You can only forward TCP, UDP, GRE and ESP.
-
Unfortunately, I need the actual IP addresses to be routable. I am spending this Saturday testing port forwarding. I may be ok with the protocols available, but I do not know about the reflection and public/private routing issues. The vendor swears that my configuration will work with a Sonicwall TZ190, so I assume that there must be a way to make this work with Pfsense. I am not opposed to purchasing a commercial router. I simply do not believe that it is better to "just make it work" rather than fully understanding the requirements and the mechanics that are enabling or preventing the functionality.
-
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.