Opening Port Problem

'Any→UEC_JPP→Any', use 'Traffic selector: Any→UEC_JPP→External (Address)'.

The problem persist.

Here is what I am trying to do.
I have a server that has a service running on port 8443.
I want to allow internet user to access port 8443 on server3 in my network.

what you need to do is a DNAT only 

Created DNAT
DNAT [UEC_JPP_CC1]
Traffic selector: Any→UEC_JPP→external interface of astaro box (depends on your topology)
Destination translation: BMCC1 UEC_JPP
Automatic packet filter rule: Yes
Initial packets are logged: Yes

Several comments:

1 - It's unlikely that this is causing a problem, but, when the 'Destination service' is not being changed, leave that field empty.

2 - Sometmes, people create routing problems when they bind a definition to an interface.  Please check your network and host definitions to be sure that all of them list 'Interface: >' instead of being bound to Internal or External.

3 - If your public IP is not on the External interface of the Astaro, then remember that you also need to port forward from your other router to the Astaro.

4 - What do you see in the packet filter log when you try to reach the server from the outside?

5 - If you're still having problems, please show pictures of BMCC1 and UEC_JPP.

Cheers - Bob

2 - Sometmes, people create routing problems when they bind a definition to an interface.  Please check your network and host definitions to be sure that all of them list 'Interface: >' instead of being bound to Internal or External.

I've seen this comment about choosing "Any" as the interface setting instead of specifying "Internal" or "External" several times.  Bob can you, or any of our forum friends or Astaro personnel, please elaborate on this a bit.

1.) Is there simply no reason to ever specify Internal or External?

2.) Is the problem that people often get confused about the routing circuits (what's in - what's out, etc.), or does it actually just not work correctly sometimes?

3.) Is there any security or performance reason one might want to specify?

It all kind of makes one wonder why the choice is even offered?

Eric

4 win boxes:
Always make sure your created rules local policy rules are off and firewall is off in windows. That causes untold major headaches when everything else is right. I still use local policy for pop up alerts like log ons etc.

Also, is this a pass through bridge router? Make sure its not blocking ports but what you configured to allow. no dhcp allowed. 

Server should be dnatted to a local IP of server box from external Ip assigned by ISP.

Try cloning your working port then change the port to 8443 or make new port 8443. Maybe the old one was incorrect?

I don't know what else it could be unless you muffed up somewhere naming rules and incorrect porting numbers and ethos.

Your right there... on one of these anyway. 

M

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

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.