I was trying to access to a specified port of remote machine from my CENTOS machine and i am not able to connect.

If i write telnet remote_machine 666 i have no response.

The client machine is a vmware virtual machine where where the firewalld and iptables are stopped.

In the same vmware server i have another virtual machine (this one in ubuntu), that is able to connect to 666 port of remote machine.

Another curious things are that:

With a nmap, from ubuntu machine i can see remote 666 port as open, while from CENTOS machine 666 port is filtered.
In vmware client i can see ubuntu network adapter type(where it works) is defined as flexible while CENTOS one is defined as VMXNET 3
What could happen?

On the client machine what does "lsof -i :666" show?

I'm thinking that 666 is LISTENing only on localhost and/or some bridge interface accessible to other VMs on same hypervisor but not to machines not on the same hypervisor.

You might want to use netcat (nc) rather than telnet for testing. A lot of distros these days aren't installing the telnet command (not to be confused with the telnet service).

nc -vw2 <remote> 666
Verbosely tries to connect to the remote you specify on port 666 and times out in 2 seconds. Running "man nc" will give you more details. You can even use nc to LISTEN on a port on one side and connect to it from another system to verify firewall settings before the app that will ultimately LISTEN on that port gets installed.

In both client machines lsof command returns nothing.

The nc command in ubuntu client works fine, but in CENTOS returns the message: 'Ncat: Connection timed out.'

It is a bit strange, because in this second machine when i launch the command:

nmap remote_machine -Pn -vv -p 666

it returns me:

PORT STATE SERVICE
666/tcp filtered unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.05 seconds
Raw packets sent: 2 (88B) | Rcvd: 0 (0B)

filtered/unknown basically just means it couldn't reach the port and doesn't know why.

The fact "lsof" didn't show anything LISTENing on port 666 on the server suggests the app that should be LISTENing isn't running. You could run "netstat -an |grep 666" on that same server to see. (Some things do not show up in lsof such as RPC stuff on some platforms but for the most part lsof should show things.)