At her business my wife switched to adsl service from True.  I am running a DDNS client there which has updated its internet ip.  I can ping that ip.  However, I cannot connect to some services that the internet router is port mapping to local hosts.  Does True somehow block incoming traffic or does it have some additional NAT layer that interferes with incoming traffic?

Many of the wired Internet Service Providers have a habit of, if not outright switching you to Carrier Grade NAT (IP range 100.64.0.0 – 100.127.255.255), then redirecting traffic through proxies.

 

What ports are working for you, and which ports are not?

 

I'd expect many of the sub 1024 ports like 21, 22, 23, 25, 53, 80, 137, 138, 139, etc, could be blocked either by their gateway firewall or your router (due to internal daemon/service conflicts).

True probably block port 80,25 and some more.

Try port forwarding to 8000 instead of 80 etc.

The ports I am trying to use are all high-numbered, above 1024.   It's not my router that is doing the blocking because I have configured port mapping for those services.  If True is using Carrier Grade NAT then how is that I can ping the DDNS address of the router?

 

Can anyone confirm that True is known to be using Carrier Grade NAT?   The DDNS is currently in the 58.x.x.x range, not IP range 100.64.0.0 – 100.127.255.255.

The easy way to check for NAT is to log on to your router and record the WAN IP, then go to one of the many " what's my IP" sites and verify that the two match.

 

On 1/21/2017 at 10:17 AM, CaptHaddock said:

However, I cannot connect to some services that the internet router is port mapping to local hosts.

 

Cannot connect to "Some" services, or "Any" services. 

What ports are working for you, and which ports are not?

 

If your router's actual WAN address (as reported in the router's web config interface) and your DDNS-reported public IP address are the same then you should have direct traffic access to your router service. 

6 minutes ago, RichCor said:

 

Cannot connect to "Some" services, or "Any" services. 

What ports are working for you, and which ports are not?

 

If your router's actual WAN address (as reported in the router's web config interface) and your DDNS-reported public IP address are the same then you should have direct traffic access to your router service. 

 

I am only attempting to use two ports, neither of which works.  I will check the wan ip address of the router the next time I go to the store. 

 

I see from another thread here as late as 2016 that True was indeed assigning CGN addresses to customers.  Some of the posters in that thread were able to get a regular, routeable, dynamic ip after asking True to make that change.  So, we are pursuing that avenue now with True email support.

My current experience is that  when using  a particular site I am  plagued with the following matter 58.97.16.11 cache app when one actually   gets the blasted page up it is in Chinese and states lord only knows what. True seem to be doing all they can to destroy  and block services  here in Thailand.

 

My I P is totally different to the one shown below and as said it seems as if True have a link  to a Chinese site or it's a confounded  infection. Searched my machines with Malaware bytes and   they are clean

 

Do any of you pundits have any idea of how to deal with this blight upon  my system please?  

22 minutes ago, CaptHaddock said:

I will check the wan ip address of the router the next time I go to the store. 

 

I see from another thread here as late as 2016 that True was indeed assigning CGN addresses to customers.  Some of the posters in that thread were able to get a regular, routeable, dynamic ip after asking True to make that change.

 

If True is providing your router a CGN private IP then, as Crossy noted, you'll need to log into your router's web config interface to find this out   ...as this isn't a 'public' address it isn't usually discoverable (expect when what you want to do doesn't work).  True's Gateway/Concentrator take your outgoing traffic, records it then converts your private IP traffic to a shared public IP -- and return traffic gets matched back to the original outgoing request and routed back to your specific private IP and router.  Most online sites don't detect this ISP CGN to Public IP background conversion happening.

 

Wishing you luck with True.  

Oh, and remember what you did with them as you will most likely have to repeat the process with True again and again (the 'provisioning' on their side sometimes gets reset to default and back to CGN you go).

34 minutes ago, shunter said:

when using  a particular site

 

This sounds more like the 'site' your browsing isn't defining the proper character display codepage.

 

Since your question seems like it might get rather involved it would probably be better to open your own topic and ask the question there. 

6 minutes ago, RichCor said:

 

If True is providing your router a CGN private IP then, as Crossy noted, you'll need to log into your router's web config interface to find this out   ...as this isn't a 'public' address it isn't usually discoverable (expect when what you want to do doesn't work).  True's Gateway/Concentrator take your outgoing traffic, records it then converts your private IP traffic to a shared public IP -- and return traffic gets matched back to the original outgoing request and routed back to your specific private IP and router.  Most online sites don't detect this ISP CGN to Public IP background conversion happening.

 

Wishing you luck with True.  

Oh, and remember what you did with them as you will most likely have to repeat the process with True again and again (the 'provisioning' on their side sometimes gets reset to default and back to CGN you go).

 

I understand what NATted addresses are, thanks.  I wasn't asking for a basic tutorial, just information about True's practices which I found on the other thread.

 

Quote

 

richcor. I D| 10

 

This sounds more like the 'site' your browsing isn't defining the proper character display codepage.

 

Since your question seems like it might get rather involved it would probably be better to open your own topic and ask the question there. 

 

 

 Thank you for your sage advice,  however the site  is not at fault as when using any of my office machines all functions correctly, same provider (True)  but different I P

As a matter of interest and perhaps an aid to identifying  the problem below is a screen shot that links to the I P 58.97.16,11

 

It's an elusive  creature that very occasionally appears for whatever reason.

Sorry  but below is the English translation of the originalmessage in Chinese.The original had vanished from the google record but more by luck than judgement I had  planted it into a bookmark folder. hence the  post below.

 

 

18 minutes ago, shunter said:

below is the English translation of the originalmessage in Chinese

 

The English translation is referring to a hosting service providing "name-based virtual hosting, also called shared IP hosting, the virtual hosts serve multiple hostnames (or domain names) on a single machine with a single IP address".

 

A site that uses virtual shared hosting (and sharing a single IP address) cannot be contacted directly using an IP address. 

 

Since you can connect with this site on other computers, but not this specific computer, then something is 'breaking' or filtering the browsers request where passing the hostname is part of the request.

 

A test to see if it is something involving your ISP would be to invoke a VPN (where the ISP is precluded from blocking or filtering the connection traffic).  Any free VPN would do.

Thank you rich cor.

I shall shortly commence an assault on  the  parties involved to see what has happened

An update on my problem.  I checked the WAN side of the router and it shows 2 ips.  One it calls "ip" is 58.x.x.130.  The other it calls "remote access" is 58.x.x.1, on the same network and obviously True's router.  If I check with whatismyipaddress.com, it reports 58.x.x.130.  Nevertheless, I conclude that True must be NATting me since although I can ping the 58.x.x.130 address, it is not passing traffic through to my mapped ports.

 

I spoke to True tech support, an exercise is frustration.  When I got to the supervisor level, he not only spoke good English, but seemed familiar with the concept of CGN.  He did the surprising thing of asking me what I wanted him to do.  I told him I wanted a dynamic, public ip.  He replied, "Oh, a dynamic ip," ignoring the crucial word "public" for which I yelled at him.  He went to confer with someone and is supposed to call me back Friday morning.

8 hours ago, CaptHaddock said:

An update on my problem.  I checked the WAN side of the router and it shows 2 ips.  One it calls "ip" is 58.x.x.130.  The other it calls "remote access" is 58.x.x.1, on the same network and obviously True's router.  If I check with whatismyipaddress.com, it reports 58.x.x.130.  Nevertheless, I conclude that True must be NATting me since although I can ping the 58.x.x.130 address, it is not passing traffic through to my mapped ports.

 

I had TRUE ADSL several years ago and I recall the 58.x.x.x WAN address range and they were definitely public and externally accessible then. In any case you have already confirmed that you don't have CG-NAT with the above test.

 

You mentioned that you are able to ping the WAN address. Most routers have the option to ignore external WAN ping requests so you could try switching between enable/disable on that option to determine whether the pings are really reaching your router.

 

Also most consumer routers have an option to allow/disallow remote management on the WAN port often on port 8000 or 8080. Have you tried enabling that and then try connecting to (e.g.) 58.x.x.x:8080? If you are able to connect to the router GUI from an external internet connection then you can be pretty confident that you have a local issue somewhere which is preventing the port mapping from working.

17 hours ago, thedemon said:

I had TRUE ADSL several years ago and I recall the 58.x.x.x WAN address range and they were definitely public and externally accessible then. In any case you have already confirmed that you don't have CG-NAT with the above test.

 

You mentioned that you are able to ping the WAN address. Most routers have the option to ignore external WAN ping requests so you could try switching between enable/disable on that option to determine whether the pings are really reaching your router.

 

Also most consumer routers have an option to allow/disallow remote management on the WAN port often on port 8000 or 8080. Have you tried enabling that and then try connecting to (e.g.) 58.x.x.x:8080? If you are able to connect to the router GUI from an external internet connection then you can be pretty confident that you have a local issue somewhere which is preventing the port mapping from working.

I found the problem.  True wasn't blocking ports.  There was an option in configuring the port mapping to select the WAN interface for which the default was not the correct value.  Once fixed, the port mapping is working fine.