Assistance with an internal port forward



  • I'm trying to get an internal port forward to work.

    I have a domain pointed (internally) to my firewall.

    What I'm trying to make is a NAT rule that directs a port to another internal IP

    So if I try to hit my firewall at port 10060, it directs it to the specific server at 10060

    The rule I made was

    Interface: LAN
    Source: Any
    Destination: 10.9.0.1 <– Firewall
    Destination Port: 10060
    Target: 10.9.0.10 <--- Internal server 
    Target Port: 10060

    This doesn't work

    However, if I change Destination from 10.9.0.1 to ANY, it works, so I'm not sure why that is, but I don't want to globally override that port.

    Can anyone help?



  • Why would you want to do this? Why not just set your internal DNS to point directly to the internal server instead of your firewall? You're just trying to bounce a forward from an internal host to another internal host via the firewall's internal interface. Unless I misread your post.


  • LAYER 8 Netgate

    Yeah. Bouncing connections in and back out of the same interface is doomed to failure. Sometimes in strange, unpredictable, and intermittent ways. Just don't do it.

    If you really need this put the asset you are redirecting to on another interface and redirect to that.  That will work fine.



  • @muswellhillbilly:

    Why would you want to do this? Why not just set your internal DNS to point directly to the internal server instead of your firewall? You're just trying to bounce a forward from an internal host to another internal host via the firewall's internal interface. Unless I misread your post.

    Externally my domain points to my firewall and has specific ports forwarded to specific machines for different services.
    Internally my domain ALSO points to my firewall.

    I'm trying to achieve the same thing.

    For example, one machine hosts and IceCast2 server for music streaming.

    Right now people can go to http://mydomain.com:10060/stream.m3u and listen.
    However, if they're on my network, that doesn't work.

    If I point my DNS to the one server internally, I remove the ability to reach ALL other servers with the same name.

    If you really need this put the asset you are redirecting to on another interface and redirect to that.  That will work fine.

    Unfortunately, that's not possible as I need that resource to be on LAN due to it's other purposes.

    I should mention again, that if I do the port forward with destination set to ANY it works, but if I only put in the firewall's IP, use the "This Firewall" alias, or 127.0.0.1 it doesn't work.
    That suggests to me there is a correct thing to use for the destination to make this work, if using "Any" does work.


  • LAYER 8 Global Moderator

    "If I point my DNS to the one server internally, I remove the ability to reach ALL other servers with the same name."

    Huh???  You just create a record for mydomain.com that points to your internal IP on your internal dns..



  • @johnpoz:

    "If I point my DNS to the one server internally, I remove the ability to reach ALL other servers with the same name."

    Huh???  You just create a record for mydomain.com that points to your internal IP on your internal dns..

    Maybe I worded that poorly

    Externally
    domain.com:80 -> Server A
    domain.com:81 -> Server B
    domain.com:82 -> Server C

    If I point the DNS for domain.com to any one of those servers, I relinquish the ability to have the other two accessible.
    What I'm trying to do is point the DNS internally to the firewall and then use NAT to forward the ports back to the correct servers.

    EDIT: added pictures of the rule that works and the rule that doesn't.
    (But the rule that works is too broad, I want to be specific as I don't want to forward ALL attempts at 10068, just the ones that target the firewall itself).





  • LAYER 8 Global Moderator

    why not just do

    server1.domain.tld publicIP –- serverA privateIP-A
    server2.domain.tld publicIP --- serverB privateIP-B
    server3.domain.tld publicIP --- serverC privateIP-C

    then on internal
    server1.domain.tld privateIP-A
    server2.domain.tld privateIP-B
    server3.domain.tld privateIP-C

    Much cleaner solution..

    If you don't want to use the :port in your url just setup reverse proxy on pfsense.



  • @johnpoz:

    why not just do

    server1.domain.tld publicIP –- serverA privateIP-A
    server2.domain.tld publicIP --- serverB privateIP-B
    server3.domain.tld publicIP --- serverC privateIP-C

    then on internal
    server1.domain.tld privateIP-A
    server2.domain.tld privateIP-B
    server3.domain.tld privateIP-C

    Much cleaner solution..

    If you don't want to use the :port in your url just setup reverse proxy on pfsense.

    If I was doing it from scratch, I would have done it that way, but I'm not.  There's hard coded things going years back that used to all run off a single server.

    I know it's not best practice, but it's what I need to do for my scenario.

    Based on the pictures I uploaded, you can see there HAS to be some way to make it work given my constraints.  I just need to find out what it is.
    Considering it works with the destination being "Any", then there must be some destination(s) that will make it work.

    (And for what it's worth, I'm pushing to have some of that changed so I CAN use best practices)



  • @Trel:

    If I was doing it from scratch, I would have done it that way, but I'm not.  There's hard coded things going years back that used to all run off a single server.

    I know it's not best practice, but it's what I need to do for my scenario.

    I'm not sure what you mean by 'hard coded things', but if you just need to resolve one host internally then surely a DNS override would work just as well. You just need to enter the address for one host - how hard can it be?



  • @muswellhillbilly:

    @Trel:

    If I was doing it from scratch, I would have done it that way, but I'm not.  There's hard coded things going years back that used to all run off a single server.

    I know it's not best practice, but it's what I need to do for my scenario.

    I'm not sure what you mean by 'hard coded things', but if you just need to resolve one host internally then surely a DNS override would work just as well. You just need to enter the address for one host - how hard can it be?

    Ok, I have two things off the top of my head that are hard coded.

    One is hardcoded to look at: http://domain.com:8080/path_to_xml/file.xml
    One is hardcoded to look at: http://domain.com:10060/stream128.m3u

    The webserver which serves the XML is one one server, the IceCast server which serves the m3u is on a second server.

    How would I achieve this with a DNS override?

    Pfsense: I can change
    Servers Themselves: I can change
    DNS: I can change
    Devices that look at those URLs and Ports: I cannot change

    What are you suggesting I do here?

    (I'm sorry if I sound a bit snappy here, I'm just not sure how I'm supposed to point DNS to two different locations for the same name without NAT as well.  And I'm dealing with an excellent bug in my registrar's UI that has locked me out of making any DNS changes at all on two of my domains.  Didn't meant to take out my bad day on you)


  • LAYER 8 Netgate

    I try to tell people that domain.com shouldn't be used as a hostname. I always lose. Whoever did that painted you into a corner.

    So you're saying both those URLs need to go to different destination servers?

    Yes, you'll need a port forward.  Doing it with the clients on the same subnet as the servers is going to be pretty hokey. You see, NAT is a router function and you don't route same-subnet traffic so anything that "works" will be a hack.

    My recommendation is to put the servers (which you say you can change) on a different subnet and NAT port forwards will work fine. But you've already said you can't do that either.

    You might try enabling the NAT destination IP again and and checking Static route filtering in System > Advanced > Firewall/NAT tab .



  • @Derelict:

    I try to tell people that domain.com shouldn't be used as a hostname. I always lose. Whoever did that painted you into a corner.

    So you're saying both those URLs need to go to different destination servers?

    Yes, you'll need a port forward.  Doing it with the clients on the same subnet as the servers is going to be pretty hokey. You see, NAT is a router function and you don't route same-subnet traffic so anything that "works" will be a hack.

    My recommendation is to put the servers (which you say you can change) on a different subnet and NAT port forwards will work fine. But you've already said you can't do that either.

    You might try enabling the NAT destination IP again and and checking Static route filtering in System > Advanced > Firewall/NAT tab .

    Well it's not domain.com specifically, I don't think they want me mentioning their real one.  But I agree.  My home setup has an internal domain, but I use s1.trel.co, s2.trel.co, etc to separate them even when they all point to the same IP externally.

    For the static route filtering option, it refers to defined interfaces, not physical ones, right?

    Do you have any idea at all why the NAT rule I have in the picture I uploaded earlier works when it's destination is * vs any one IP/Alias?

    EDIT: the static route filtering option didn't make a difference, if it absolutely can't be done without forwarding ALL destinations at that port, I'll have to tell them it can't be done.


  • LAYER 8 Netgate

    If I have time I'll lab it tonight.  I don't know if you need to enable NAT reflection or another hack to make it work.

    Just so I'm clear you want:

    pfSense: 192.168.1.1/24
    ifAlias VIP: 192.168.1.2
    Host 1: 192.168.1.100
    Server 1: 192.168.1.200

    Port forward connections from 192.168.1.100 to 192.168.1.2:8000 to 192.168.1.200:8000 instead.


  • LAYER 8 Global Moderator

    You want a simpler solution.. Run those services on the same box - since the moron that hard coded a single name thought that was how it worked..  Also agree using a domain name as FQDN to point to a host is a bad ide.. host.domain.tld should always be used..

    Fix the hard code.. Which again is BAD idea…



  • I'm in agreement with JP on this one. The more you try to work around the bad decisions made before you inherited this system, the more convoluted and unmanageable your environment will become. You have an opportunity to fix things here rather than just work around them. Otherwise you'll only make your life and the life of guy who eventually inherits your network more miserable in the long run.

    Puts me in mind of the following classic image: http://blog.thingsdesigner.com/uploads/id/tree_swing_development_requirements.jpg


  • LAYER 8 Global Moderator

    ^ exactly… You also have some moron hard coding ports in the url??  This is also really bad practice if you ask me...

    Also lets clarify "hardcode"  your saying the application has http://domain.com:8080/path_to_xml/file.xml in its code, and to change that has to be recompiled?  Or are you saying its in the registry and or conf or ini file that controls the application.. And you just don't want to push out the update to the configuration?



  • @johnpoz:

    ^ exactly… You also have some moron hard coding ports in the url??  This is also really bad practice if you ask me...

    Also lets clarify "hardcode"  your saying the application has http://domain.com:8080/path_to_xml/file.xml in its code, and to change that has to be recompiled?  Or are you saying its in the registry and or conf or ini file that controls the application.. And you just don't want to push out the update to the configuration?

    It's not that they don't want to push out the configuration, but that the devices it's on need to have the configuration changed, which can't be done remotely.  (Not that they don't want to push out config, but that there's no mechanism to do so here). An example using the Icecast server.  It's a playlist included with the device that has the proper URI to the Icecast server.  I could change it in the config on their devices, but I can't do that without the device.  Remotely changing it isn't an option.  On the one I have sitting next to me, I already did, but the guy three states over, not so much.

    However, they won't be available to change any time in the near future.  If I change it to multiple subdomains off the hostname, I break it for everyone who's currently remote.  If I don't, I'm apparently breaking (or rather, not making it work) for everyone who is local at the moment.

    Only possible workable solution if port forwarding is not an option is to use DNS to make multiple names, and deal with the remote ones as they come in.
    It looks like it's going to be a case of "It's definitely not the best way, it's just the only way".



  • For anyone wondering what I ended up doing was setting up DNS entries for the different servers.

    Externally, they all point to the same IP, internally, to the different servers.
    As I get my hands on the devices with the old config, I'll update them accordingly.

    Since it's all going off a single IP, the external devices which I can't updated would work just as well with domain.com as with server01.domain.com when it comes to the port forward externally.


Log in to reply