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

Opening Port Problem

I have tried so many variations trying to open port 8443 and it is not happening.

I am able to open port 22/SSH but for any other ports I cannot. Can you please help me.

I created a service:
UEC
Desitination Port: 8443
Source Port: 1:65535

Created DNAT
DNAT [UEC_JPP_CC1]
Traffic selector: Any→UEC_JPP→Any
Destination translation: BMCC1 UEC_JPP
Automatic packet filter rule: Yes
Initial packets are logged: Yes


This thread was automatically locked due to age.
Parents
  • Interesting question, Eric - I had the same thought after I posted that.  Apparently, this was added early in V7.0x, and Gert commented:
    You are now also able to create a real 'Internet' Object using the network '0.0.0.0/0' and bind it to the external interface. 

    By doing this, you will not open up access to the DMZ like in the past, when you used the "Any" object.


    My authority for recommending against binding for definitions used in NAT rules was Jack Daniel's later comment
    One common mistake with NAT rules- make sure you do not bind host or network definitions to a specific interface, it can have unintended consequences.


    Then, earlier this year, Jack said:
    I have seen cases where binding to an interface adds enough latency to cause timeouts for some sites (and web apps).


    In Need assistance with IPSEC VPN over PPPoE, CooHandLuke commented:
    I found what I was doing wrong... when I created the network definition for the remote gateway, I inadvertantly bound the definition to the interface connected to the DSL circuit. I changed the definition to not use any defined interface, and it is no longer dropping the packets.

    So, to net it out, it seems to me that we have a dedicated "Internet" definition, so the binding option should be deleted or improved.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • Interesting question, Eric - I had the same thought after I posted that.  Apparently, this was added early in V7.0x, and Gert commented:
    You are now also able to create a real 'Internet' Object using the network '0.0.0.0/0' and bind it to the external interface. 

    By doing this, you will not open up access to the DMZ like in the past, when you used the "Any" object.


    My authority for recommending against binding for definitions used in NAT rules was Jack Daniel's later comment
    One common mistake with NAT rules- make sure you do not bind host or network definitions to a specific interface, it can have unintended consequences.


    Then, earlier this year, Jack said:
    I have seen cases where binding to an interface adds enough latency to cause timeouts for some sites (and web apps).


    In Need assistance with IPSEC VPN over PPPoE, CooHandLuke commented:
    I found what I was doing wrong... when I created the network definition for the remote gateway, I inadvertantly bound the definition to the interface connected to the DSL circuit. I changed the definition to not use any defined interface, and it is no longer dropping the packets.

    So, to net it out, it seems to me that we have a dedicated "Internet" definition, so the binding option should be deleted or improved.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • This finally works now.  I am posting the following entry for other people who may need help.  This confirms that the solutions provided by WINGMAN and BALFSON did work.  THANK YOU

    I have my Definition Service set to the port that I want

    DNAT [JPP_UEC_BMCC1]
    Traffic selector: Any → UEC_JPP → External (WAN) (Address)
    Destination translation: BMCC1
    Automatic packet filter rule: Yes
    Initial packets are logged:   Yes

    You guys have been great.  THANK YOU.