Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Internal DNS mapping based on ports

    Scheduled Pinned Locked Moved DHCP and DNS
    8 Posts 2 Posters 1.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D Offline
      dcol Banned
      last edited by

      I have an issue with internal mappings that I will try to explain the best I can. Everything is working fine from the internet, only internal LAN machines have an issue

      I switched, on the advice of other members, from NAT Reflection to DNS Resolver Host Overrides. My url, lets say www.xyz.com, properly resolves to my internal server 192.168.20.2 using DNS Resolver.

      Problem is, I also need the LAN to get to the same URL, using assigned ports,  to other IP's on the same computer, ie www.xyz.com:6000 needs to goto 192.168.20.4 instead of 192.168.20.2. Right now with DNS Resolver, www.xyz.com:6000 goes to 192.168.20.2. Everything worked fine when I was using NAT Reflection.

      Question is, how can I redirect to another server IP based on the port. Port forwarding is setup to redirect the external Internet IP to the correct IP based on the port. How do I do that with DNS Resolver? Maybe setup another port forward from the LAN to the IP?

      LAN - 192.168.1.0/24
      Server - 192.168.20.0/24 - One computer using 3 IP's 192.168.20.2,3,4 Each IP is bound to a different program.

      Thanks for your help!!

      1 Reply Last reply Reply Quote 0
      • D Offline
        doktornotor Banned
        last edited by

        You don't do any such thing with DNS. You could use something like HAProxy on pfSense's LAN and point your DNS there.

        1 Reply Last reply Reply Quote 0
        • D Offline
          dcol Banned
          last edited by

          Don't want to add packages, especially a proxy package. Any way to do this with port forwarding? Maybe have the LAN as source. If not, I will have to go back to NAT reflection, which worked fine. What is the point on leaving NAT Reflection if I have to add a proxy?

          1 Reply Last reply Reply Quote 0
          • D Offline
            doktornotor Banned
            last edited by

            No, there won't be any port forwarding anywhere, the packets won't ever reach the router! The way to do it is to have 3 different DNS records for 3 different services pointing to proper IPs.

            
            foo.example.com -> 192.168.20.2 
            bar.example.com -> 192.168.20.3
            baz.example.com -> 192.168.20.4
            ...
            
            

            Dunno why people start with completely broken design and then go hacking around it with clusterfucks.

            1 Reply Last reply Reply Quote 0
            • D Offline
              dcol Banned
              last edited by

              Can't do that since the programs are internally linked to the same URL which is an https extended validation and only uses the one url.
              Don't understand broken design comment unless you are referring to PFsense.
              I guess NAT reflection was a better choice all along.

              I will wait until this weekend to change it back to see if anyone else has any suggestions.

              Thanks for your input.

              1 Reply Last reply Reply Quote 0
              • D Offline
                doktornotor Banned
                last edited by

                Your options are:
                -recode the programs and whatever is using them to use SRV records (those DO care about ports, the rest just does NOT)

                • get a SAN or wildcard cert

                As for the broken design: "the programs are internally linked to the same URL" is exactly that. Plus you'd have avoided all of this hassle if you had not been inventing WTF setups like having multiple IPs on the same computer that just break things and help nothing.

                1 Reply Last reply Reply Quote 0
                • D Offline
                  dcol Banned
                  last edited by

                  Please do not assume code is broken on something you know nothing about. There are three IP's used for good reasons due to three SMTP servers that are running on the same computer. They pass emails between them for different functionality. One handles attachments, one spam, and one IMAP/SMTP outbound. All are encrypted and use https via the same URL. I have been in IT for 40 years so keep your tudes at bay please.

                  Seems every time I ask questions I get some snotty arrogant answers.

                  1 Reply Last reply Reply Quote 0
                  • D Offline
                    doktornotor Banned
                    last edited by

                    @dcol:

                    There are three IP's used for good reasons due to three SMTP servers that are running on the same computer. They pass emails between them for different functionality. One handles attachments, one spam, and one IMAP/SMTP outbound.

                    Yeah. That's what you normally do on localhost (127.0.0.1, [[::1]]). I.e., do AV filtering on a localhost: <someport>and spam filtering on localhost:<anotherport>. Why should you be opening those to the entire LAN (or even WAN) goes beyond me. There's no reason why anyone should be abusing those from inside LAN or from WAN. They are for mailserver use, nothing else.

                    @dcol:

                    All are encrypted and use https via the same URL

                    Funny, I thought mailservers were using SMTP/IMAP/POP. Not HTTPS. Even if you were running webmail on the normal mailserver, you do not need any HTTP(S) for the rest. Huh.</anotherport></someport>

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.