This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NAT - Translating non-matching services

I would like to redirect port 80 on the outside of the firewall, to a different service port (not 80, but 963) on a machine on the inside.
So the NATrule that I want to implement would look like this:
Any->OutsideIP (Address) / http -> None -> WebServer / 963

Why does the source service *have* to match the destination service? I realize that the PF cannot explicitly contend with "source -> service -> destination" in a differring service instance. But thats what "service groups" are for. eg HTTP + 963 = my weird web service
so PF rule would be "any -> my weird web service -> webserver".
Should that not "fool" PF in allowing the packet?

So, if there is a method to do this, I am certainly interested. This is a production environment (Running ASL 5.200).

Thanks
E


This thread was automatically locked due to age.
Parents
  • so you want to forward port 80 on external interface to an internal machine and translate the destination port to 963 ->

    add a dnat/snat:  no match -> external address -> http -> internal machine -> no change -> 963

    then allow from any to internal machine port 963 in the packet filter 

    that's it if your web server is really listen to port 963 and if there is no local firewall installed on the webserver.
  • [ QUOTE ]
    so you want to forward port 80 on external interface to an internal machine and translate the destination port to 963 ->

    add a dnat/snat:  no match -> external address -> http -> internal machine -> no change -> 963

    [/ QUOTE ]
    Sorry, same error as before "The matching service protocol is not the same as the translated one."

    [ QUOTE ]
    that's it if your web server is really listen to port 963 and if there is no local firewall installed on the webserver. 

    [/ QUOTE ]
    Correct, don't ask me, I'm just The Enabler, the dev's give me the weird requests, I just make em happen! 

    Thanks!
  • AHA!
    So, the services may not match, but the protocol types do have to match.
    So, http is a TCP service, and my other service has to be TCP as well. It cannot be TCP/UDP as when it is created.

    So the above rules will work, just make sure that the services both match protocol types.

    Cheers
    Elsifer
Reply
  • AHA!
    So, the services may not match, but the protocol types do have to match.
    So, http is a TCP service, and my other service has to be TCP as well. It cannot be TCP/UDP as when it is created.

    So the above rules will work, just make sure that the services both match protocol types.

    Cheers
    Elsifer
Children
No Data