NAT DMZ to LAN works but...



  • Hello i have a Pfsense with 3 Interfaces: WAN, LAN, DMZ.

    I have one Server in DMZ and it need enable communication with Web Server in LAN Network.

    DMZ Server: 172.16.50.10
    LAN SERVER: 10.50.50.10 (Hide with NAT IP 172.16.50.222, using proxy ARP)

    I create NAT and Rules (I Try Manual or Automatic) in DMZ, but Firewall permit traffic to NAT IP and Real IP too.

    It is normal? i canno't hide traffic to Real IP from DMZ? I preffer to hide Real IP.

    Enable two traffics, example:

    172.16.50.10 --> 172.16.50.222:80
    172.16.50.10 --> 10.50.50.10:80

    Thank's a lot


  • LAYER 8 Global Moderator

    Just do a outbound nat using your lan interface with source the dmz. This is called a source nat.. It would be a outbound nat on the lan interface.

    For the life of me can not see a use case for doing this though... Would you mind explaining what you this accomplishes exactly? Other than circumvention of a host firewall on the lan box.



  • @johnpoz Thanks for your Answer.

    For example I have a server in DMZ Front to Internet, some people enter to a webpage in this server from internet ( inbound traffic).

    Sometimes, this server need to communicate to another host or server in LAN network, for example to query a DataBase server or web service, that it is not in the same DMZ net.

    For do this, i hide real IP host in LAN over another "virtual IP in this case a NAT" or another IP from the same DMZ subnet for security. If DMZ server is compromise, all connections in server only "appears" to communite to the same Network segment of DMZ.

    I try to test outbound NAT in LAN like your recommendation.

    Thanks ( sorry for my English, i Speak Spanish)

    Oscar.


  • LAYER 8 Global Moderator

    @OscaRCR said in NAT DMZ to LAN works but...:

    connections in server only "appears" to communite to the same Network segment of DMZ.

    That is not a nat, that is a port forward...And again see zero point to this... So you have a server in vlan A, and it needs to talk to something int vlan B.. .So let it via a firewall rule - what do you think you get from hiding anything?

    Sill don't see the point here? If you want dmz to talk to DB, then open up what 1433 to LAN from DMZ with simple firewall rule.

    setup.jpg

    That is your setup? Why can can 10.50 not see that traffic is coming from 172.16? Why can not 172.16 not want to talk to 10.50.50.10?? Why would he use a different IP for the IP of the DB?

    Just block all traffic from DMZ to LAN, except for port 1433 (your db port(s)..



  • @johnpoz Thanks for your Help.

    The scheme is similar like your image.

    Well, i know that is port forward, simply i want to "hide" Real IP, it is all.

    Off course i could permit traffic without change IP host in LAN and it works.

    Oscar.


  • LAYER 8 Global Moderator

    @OscaRCR said in NAT DMZ to LAN works but...:

    i want to "hide" Real IP, it is all.

    For what possible reason?? It just make zero sense... Its a rfc1918 address... There just is NO reason to try and hide it or nat it... There just isn't --- what do you think it gets you other then PITA and more complexity? It sure any sort of added security..



  • @johnpoz

    Just for hide inside real IP, Why i cannot do it? It is valid not? I dont want to show it.

    Not all people works similar to others, like maths. It is not the rule, because i do it with anothers firewalls.

    It enforce to Dev. Dept to understand use of ports and IP in different environements.

    Oscar.


  • LAYER 8 Global Moderator

    @OscaRCR said in NAT DMZ to LAN works but...:

    dont want to show it.

    For why??? its a rfc1918 IP address.. Not sure what you think it hides? But if you want to nat it sure you can... Just ZERO freaking point to it..

    i do it with anothers firewalls.

    And just as pointless there as well.. Doesn't enforce anyone anything about ports an IP.. if anything it confuses the whole matter.. But sure if you want to do it, you can do it... If you like making things difficult for zero reason... Do you like hitting yourself in the head with a hammer - about as productive as what your doing..



  • @johnpoz OK, no problem with that.

    Oscar

    Anyone have other point of view?

    Thanks a Lot.


  • LAYER 8 Global Moderator

    Love to hear them if there is anyone... Dude in the biz for 30 years.. What your doing is completely utterly a pointless waste of time that is only adding complexity... The only time you would ever nat rfc1918 to rfc1918 is if there is an overlap...And its impossible to change one of them for whatever reason.

    If you can not explain WHY your doing, or how it protects you - then its pointless to do it.. Just because you have done it in the past is not a reason to do it now.

    I could see doing it, if these devices had no gateway and you need them to talk to each other thinking they were on the same network, etc. But the solution there would be to just set a gateway on them, etc.



  • Hi,
    In the same position as OscarCR.

    Just moving from Cisco ASA over to pfSense.

    We have a DMZ - all the machines in the DMZ only know about the DMZ addresses, they know nothing of the internal IP range. Anything that is internal has a DMZ address it is NAT'd to.

    All machines have tcp wrappers preventing ssh access to other machines. if a machine is compromised then all that will be seen is the DMZ addresses. No Internal IP addresses will be visible.

    On an ASA you add a firewall rule allowing a real DMZ machine IP to talk to a the DMZ IP of a NAT'd machine. On the ASA the rules work on the NAT'd addresses.

    In pfsense however the same rules don't seem to work. It seems to translate the NAT'd IP's to the internal IP before the rules get processed. Meaning you have to put a firewall rule to say allow DMZ IP to talk directly to an internal IP.

    By doing this however when you connect to the service you want, eg HTTP you then have two IP's you can connect to the NAT'd DMZ IP and the real internal IP.
    eg. telnet <DMZ IP> 80 and telnet <private Internal IP> 80 - both work.

    As OscarCR says it would be nice to hide internal IP addresses on the public DMZ network segment.



  • @nozz
    Thanks for your time with this.

    The same way, work's but enable communication with DMZ IP and Internal IP too.

    I work this with ASA and Checkpoint, and do it.

    Oscar.


Log in to reply