Ok, so it's a Comware 5 model. From the configuration provided I see that on the WAN Gig0/0 interface you have two packet-filtering entities:
Inbound is filtered by the ACL 3100.
Outbound is filtered by QoS policy 'PolicyLimit' that uses ACL 3980 and drops traffic sourced from host xxx.xxx.20.210. Not sure why this construct is so complicated - with time-range, Qos... all kind of bells and whistles, especially taking into account the time range includes all 24 hours... Actually that is why I am not a big fan of GUIs - they produce a code that is not very human-friendly...
Also you have Attack Defence policy 86 applied, it is not packet-filter per se, but it is something to be considered if some ACL rules don't work as expected, as it can detect some ordinary traffic as false-positive and drop it. It is a good idea to disable it while fine-tuning filtering ACLs.
VLAN68 has inbound filter ACL 3200, it is quite promiscuous, as it allows all TCP/UDP traffic from the subnet. I think we can safely ignore it at this moment, unless you think about allowing non-TCP/UDP protocols as ICMP or ESP for your internal clients...
TBH I never used Web GUI on Comware products as CLI gives you much more flexibility and control, so I can't advise you on that, but I am pretty sure we can achieve what you want using CLI.
If I understood you correctly, you need to allow a port or several ports from the Internet (inbound on Gig0/0) to your local subnet on VLAN68 (outbound for the interface). For this purpose you need to edit the ACL 3100 as it is the only packet-filtering entity in this direction. The ACL 3100 looks now like:
acl number 3100
description ExternaltoInternal
rule 0 permit tcp destination xxx.xxx.20.0 0.0.0.255 destination-port eq 3389
rule 1 permit udp destination xxx.xxx.20.0 0.0.0.255 destination-port eq 3389
rule 2 permit tcp destination xxx.xxx.20.64 0 destination-port eq www
rule 3 permit tcp source xxx.xxx.20.50 0 destination-port eq 22
rule 4 permit tcp source xxx.xxx.20109 0 destination-port eq 22
rule 5 permit tcp destination xxx.xxx.20.170 0 destination-port eq 8080
rule 10 permit tcp destination xxx.xxx.20.170 0 destination-port eq 1723
rule 15 permit tcp destination xxx.xxx.20.170 0 destination-port eq www
As you can see all those statements are 'permit' statements. The traffic that doesn't hit any of those rules hits implicit deny at the end of the ACL. In order to allow something additional you need to add rule/-s after the 15th, I suggest you to number them with step of 10 as 20, 30, 40 etc, so you have place to shim additional rules in the future exactly where you need. Existing rules 0 and 1 can be used as a template for your task, as they allow RDP (tcp:3389 and udp:3389) for the whole VLAN68 subnet, just change 'destination-port' numbers to the ports you need to allow, for example if you need to allow Telnet for the whole subnet, the new rule will be:
rule 20 permit tcp destination xxx.xxx.20.0 0.0.0.255 destination-port eq 23
etc.
In order to add the rule to the ACL, open up a CLI session, then:
system-view
acl number 3100
rule 20 permit tcp destination xxx.xxx.20.0 0.0.0.255 destination-port eq 23
...
<add as many rules as needed, every new rule's number should be +10 (rule 20, rule 30, rule 40 etc...)>
quit
Then test the ACL by initiating a traffic from the Internet on certain ports. If something doesn't work, don't rush to blame the ACL, instead run a Wireshark on the local host that is the destination for the traffic and see if the host really doesn't receive anything.
Don't forget to save the configuration ('save force' command) as soon you confirm the ACL works according your expectations.
Please, let me know if you need any help with rules creating - ACLs sometimes get tricky...
P.S. Useful guide to learn more about CLI configuration of ACLs and QoS - https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c02659226