Internal DNS mapping based on ports


  • Banned

    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!!


  • Banned

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


  • Banned

    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?


  • Banned

    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.


  • Banned

    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.


  • Banned

    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.


  • Banned

    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.


  • Banned

    @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>