Toegang tot één domein geweigerd

INTERNET TOEGANG
,
1

Hallo,

Sinds enige tijd kan ik vanaf mijn interne netwerk niet meer naar tesla.com. Ik krijg de volgende melding:

Access Denied
You don’t have permission to access “http://www.tesla.com/” on this server.

Dit geldt overigens ook voor alle subdomeinen van Tesla, dus bijvoorbeeld ook auth.tesla.com (nodig om te verbinden met mijn auto). Het maakt niet uit met welk apparaat ik het probeer, bij alle krijg ik deze melding. Gebruik ik 4G of VPN, dan is er geen probleem. In eerste instantie dacht ik dat Tesla mijn IP adres om wat voor reden dan ook geblokt heeft. Maar ook als ik op de router (Draytek Vigor 2927) een route-policy activeer waarbij het uitgaande verkeer over hetzelfde WAN, maar via ander IP adres gestuurd wordt (freedom subnet), dan werkt het ook niet. Ook de DNS servers aanpassen op de router voor LAN1levert niks op.

Mijn vragen aan jullie:

  • Kan het zijn dat Tesla mij toch blokt, ook al gebruik ik een nog nooit gebruikt uitgaand IP adres uit mijn subnet? Maw kan men via mijn subnet-IP een relatie leggen met mijn eigen IP? Als dat zo is moet ik waarschijnlijk bij Tesla zijn
  • Kan het zijn dat Freedom het verkeer naar tesla voor mijn aansluiting blokt? En zoja, waarom?
  • Zijn er andere wegen die ik kan bewandelen om de oorzaak te vinden of beter nog, om dit op te lossen?

Groet,
Richard

2

Hier geen probleem… de site te bereiken.
Doe’s

traceroute www.tesla.com
traceroute to www.tesla.com (104.126.124.83), 30 hops max, 60 byte packets
 1  xxxx.xxxx.xxxx.xxxx (xx.xx.x.x)  1.169 ms  1.449 ms  1.756 ms
 2  xxx.xxx.xxxx.connected.by.freedominter.net (185.93.xxx.xxx)  23.671 ms  23.762 ms  23.878 ms
 3  ae5.core1.fi001.nl.freedomnet.nl (185.93.175.215)  26.443 ms  26.556 ms  26.680 ms
 4  amsix-ams8.netarch.akamai.com (80.249.209.208)  104.107 ms  104.158 ms  104.221 ms
 5  192.168.224.29 (192.168.224.29)  26.752 ms  26.878 ms  26.985 ms
 6  192.168.231.7 (192.168.231.7)  27.106 ms 192.168.237.3 (192.168.237.3)  25.642 ms 192.168.234.5 (192.168.234.5)  25.698 ms
 7  192.168.242.159 (192.168.242.159)  25.811 ms  3.278 ms  11.426 ms
 8  a104-126-124-83.deploy.static.akamaitechnologies.com (104.126.124.83)  11.455 ms  11.444 ms  11.445 ms

en check of je dns (thuis) op orde is en je niet per ongeluk naar een ander resolver ip gaat die het anders resolved.

3

Hoi,

Weet dat sommige uitgegeven IP blokken wel eens geblokt worden omdat ze eerst eigendom waren van een ander land of bedrijf.
Kijk eens waar je IP adres van Freedom op geregistreerd staat.

4

Kan een IPv4-adres-reputatie-probleem zijn. Zo te zien gebruikt Tesla vooral Akamai’s CDN. Je kunt je IP-adres hier checken:

https://www.akamai.com/us/en/clientrep-lookup/

1 like
5

Hier de traceroute:

traceroute to e1792.dscx.akamaiedge.net (23.222.32.231), 64 hops max, 52 byte packets
 1  192.168.x.x (192.168.x.x)  15.659 ms  6.429 ms  2.651 ms
 2  xxx.xx.xxx.connected.by.freedominter.net (185.93.xxx.xxx)  6.049 ms  8.600 ms  21.247 ms
 3  connected.by.freedom.nl (185.93.175.240)  7.781 ms  10.463 ms  18.570 ms
 4  et-0-0-1-1000.core1.fi001.nl.freedomnet.nl (185.93.175.218)  11.789 ms  19.185 ms  6.707 ms
 5  amsix-ams9.netarch.akamai.com (80.249.208.168)  16.826 ms  13.898 ms  13.400 ms
 6  a23-222-32-231.deploy.static.akamaitechnologies.com (23.222.32.231)  19.235 ms  13.284 ms  19.595 ms

DNS:

cat /etc/resolv.conf                      
#
# macOS Notice
#
# This file is not consulted for DNS hostname resolution, address
# resolution, or the DNS query routing mechanism used by most
# processes on this system.
#
# To view the DNS configuration used by this system, use:
#   scutil --dns
#
# SEE ALSO
#   dns-sd(1), scutil(8)
#
# This file is automatically generated.
#
nameserver 8.8.8.8
nameserver 8.8.4.4

scutil --dns geeft

> resolver #1
>   nameserver[0] : 8.8.8.8
>   nameserver[1] : 8.8.4.4
>   flags    : Request A records
>   reach    : 0x00000002 (Reachable)
6

Handige link! Dank, er lijkt echter geen probleem…

The IP Address 45.80.xxx.x did not receive a bad risk score. (mijn freedom ip)
The IP Address 45.80.xxx.x did not receive a bad risk score. (subnet ip)

7

Hoe kom ik daar achter?

8

Dan zal je toch naar Tesla support zelf moeten omdat het er op lijkt dat je op de server (of het voor/portaal) wordt geblokkeerd. Je zult niet de eerste zijn die ergens vanwege achterstallig onderhoud, de deur wordt gewezen.

Check voor de zekerheid ook nog even je ad/blockers/ghosteries van je browser. Mogelijk dat je met een andere browser of op de commandline er wel doorheen komt bv curl https://www.tesla.com ; wanneer je dan een zooi html terugkrijgt, weet je genoeg. Bij blokkeren, check ook of er onderwater misschien wat meer in de geretourneerde inhoud zit.

9

Geldt dit ook voor https://www.tesla.com ?

10

Allen dank voor het meedenken.

Ik zou dan graag weten op basis van welke informatie van mijn netwerk ze de blokkade toepassen - dan wel wat ik voor informatie aan ze moet verschaffen. Het IP nummer is niet voldoende, want ook met een ander IP werkt het niet.

Ik heb net een telefoon gebruikt die nog nooit via mijn lan op het internet is geweest, zelfde melding. Ik heb het MAC adres van de router aangepast, maakt ook niets uit.

Ik heb ook al zitten pluizen in het retourverkeer, niets gevonden.

Ik krijg dezelfde melding op zowel een HTTP als HTTPS. aanvraag:
Access Denied
You don’t have permission to access “http://www.tesla.com/ ” on this server.

11

Heb je de mogelijkheid om het met een andere browser te proberen? Ik kan het probleem niet reproduceren, bij mij kan ik gewoon naar die website. Heb je al geprobeerd je router opnieuw op te starten?

12

Welk ander IP ? waarbij ik vermoed dat het IP niet terzake doet.
Is dat andere IP in/van jouw omgeving/bedrijf of totaal ergens anders gelocaliseerd, mijn part via hotspot van MacDo.

En nogmaals: gebruik https://… en maak desnoods je cookie/cache compleet leeg of gebruik privacy-browsing omdat het anders wel’s kan terugvallen op oude protocollen. Indien je weet/kunt Wiresharken, kan dat vaak ook wat inzicht geven.

13

Paar opmerkingen:
MAC adres, hoewel het een wereldwijd uniek adres zou moeten zijn (ideeën uit 1977, toen er ook zeker geen plek was voor meer dan een 10000 computers…) , is het dat beslist niet. Er zijn vele duplicaten alleen merkt vrijwel niemand dat omdat de adapter verschillende kanten opgestuurd worden. MAC adressen worden gebruikt door Bluetooth, Ethernet, TokenRing, en anderen. MAC adressen zijn ook niet onveranderbaar, alle adapters kunnen aangepast worden. ELKE ethernet interface heeft een uniek adres…
Een MAC adres wordt niet buiten het “broadcast” domain (AKA LAN) waarop de ethernet poort is aangesloten gebruikt.
een MAC adres is dus geldig tot de volgende router. MAC adres aanpassen zal geen invloed hebben op www.tesla.com

Als je “curl https://www.tesla.com -L -v” gebruikt dan zou je een 401 / 403 moeten krijgen de evt. redirects worden door -L opgelost, maar zijn mogelijk wel zichtbaar.
Als het eerste contact al mis is dan doet de andere kant mogelijk aan “IP-reputation”… dat was een aardig idee als het ook zou kunnen werken… IP-reputation verklaart in hoeverre een adres behoort tot: een Datacenter, een VPN farm, een SPAM outfit, … Dialup set etc. hoort. Probleem is dat adressen niet meer eenmalig uitgedeeld worden (zoals to een jaar of 10 geleden), maar hergebruikt, geleend, verhuurd, verkocht worden. waardoor een adres dat 5 jaar geleden bij een spam-outfit in verweggistan hoorde, daarna in een DC is gebruikt voor VPN’s, en vervolgens nu verhuurd is aan een ISP oid.
Met een beetje pech houdt de IP-repuatie dienst de eigenaar (verhuur bedrijf) bij en niet de werkelijke gebruiker… Met een beetje meer pech is de DB van de reputatie dienst niet up to date, met nog een beetje meer pech is de database bij de filter provider een beetje out of date…
(vaak is het geinstaleerd en is er daarna (jaren) nooit meer naar gekeken…, een update van de database zou wonderen kunnen opleveren).

Je kunt het probleem vermoedelijk alleen oplossen door contact op te nemen met Tesla, en uit zien te vinden waarom je er niet bij kan, hopelijk kun je de betrokken IP reputatie provider boven water krijgen. Dan kun je of zelf of mogelijk via freedom zaken recht gezet krijgen.

2 likes
14

Ok, duidelijk. Allen bedankt. Ik ga contact zoeken met Tesla. Ter info:

curl https://www.tesla.com -L -v
*   Trying 23.222.32.231...
* TCP_NODELAY set
* Connected to www.tesla.com (23.222.32.231) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Palo Alto; O=TESLA, INC.; CN=*.tesla.com
*  start date: Mar 27 00:00:00 2022 GMT
*  expire date: Mar 28 23:59:59 2023 GMT
*  subjectAltName: host "www.tesla.com" matched cert's "*.tesla.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fe1e3009a00)
> GET / HTTP/2
> Host: www.tesla.com
> User-Agent: curl/7.64.1
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 403 
< server: AkamaiGHost
< mime-version: 1.0
< content-type: text/html
< content-length: 262
< expires: Mon, 23 Jan 2023 16:16:42 GMT
< x-reference-error: 18.7c31302.1674490602.1884f66a
< date: Mon, 23 Jan 2023 16:16:42 GMT
< permissions-policy: interest-cohort=()
< strict-transport-security: max-age=15768000
< 
<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD><BODY>
<H1>Access Denied</H1>
 
You don't have permission to access "http&#58;&#47;&#47;www&#46;tesla&#46;com&#47;" on this server.<P>
Reference&#32;&#35;18&#46;7c31302&#46;1674490602&#46;1884f66a
</BODY>
</HTML>
* Connection #0 to host www.tesla.com left intact
* Closing connection 0
15

Ik denk dat je je browser settings of zo, moet aanpassen.
met TLSv1.3 gaat het prima.

curl https://www.tesla.com -L -v
* Rebuilt URL to: https://www.tesla.com/
*   Trying 104.126.124.83...
* TCP_NODELAY set
* Connected to www.tesla.com (104.126.124.83) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
[cut]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
.... [cut]
> GET / HTTP/2
> Host: www.tesla.com
> User-Agent: curl/7.58.0
> Accept: */*
16

tls v 1.2 is niet het probleem: (tls v1.1 wordt (terecht) niet geaccepteerd).
Het is niet de load balancer/reverse proxy die weigert (het proces dat de SSL verbinding maakt).

Maar een achterliggende server, je hebt meer info nodig van tesla zelf.

$ curl -v -k https://www.tesla.com/ --tls-max 1.2 -o t.t
* Connected to www.tesla.com (2a02:26f0:fe00:3a8::700) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
} [5 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [225 bytes data]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* [CONN-0-0][CF-SSL] TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2992 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=Palo Alto; O=TESLA, INC.; CN=*.tesla.com
*  start date: Mar 27 00:00:00 2022 GMT
*  expire date: Mar 28 23:59:59 2023 GMT
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: www.tesla.com]
* h2h3 [user-agent: curl/7.87.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x55c1cb4ef390)
} [5 bytes data]
> GET / HTTP/2
> Host: www.tesla.com
> user-agent: curl/7.87.0
> accept: */*
> 
{ [5 bytes data]
< HTTP/2 200 
< content-type: text/html; charset=UTF-8
< x-drupal-dynamic-cache: MISS
< x-ua-compatible: IE=edge
< content-language: en
< permissions-policy: interest-cohort=()
< last-modified: Thu, 19 Jan 2023 17:44:24 GMT
< etag: "1674150264"
< x-generator: Drupal 9 (https://www.drupal.org)
< x-drupal-cache: MISS
< cache-control: max-age=10
< x-tzla-edge-hostname-vcl: drupal8-prod
< x-tzla-edge-backend-fetch-if-stale: false
< x-tzla-edge-was-304: false
< x-tzla-edge-age: 60.000
< x-tzla-edge-grace: 0.000
< x-tzla-edge-backend-retry: 0
< x-tzla-edge-backend-conn-time: 0.000
< x-tzla-edge-backend-ttfb: 0.000
< x-tzla-edge-backend-reason: OK
< x-tzla-edge-backend-status: 200
< x-varnish: 740747316 748342727
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< x-tzla-edge-cache-hit: Hit
< x-tzla-edge-ttl: 11.887
< x-tzla-edge-grace-backend-unhealthy: 0.000
< x-tzla-edge-backend-stream: false
< x-tzla-edge-client-restarts: 0
< x-tzla-edge-client-req-ttl: -1.000
< x-tzla-edge-server: sjc04p1tegvr68.teslamotors.com
< x-tzla-edge-cache-hits: 2
< date: Tue, 24 Jan 2023 10:44:09 GMT
< permissions-policy: interest-cohort=()
< strict-transport-security: max-age=15768000
< 
{ [5 bytes data]
100  460k    0  460k    0     0   453k      0 --:--:--  0:00:01 --:--:--  454k
* Connection #0 to host www.tesla.com left intact
2 likes
17

Hoi @richardw

Ik dacht dat het al aan mij lag, hier ook al enige tijd issues met Tesla site en het wordt steeds erger, mobiele app werkt steeds slechter via de wifi en vanaf laptop gebruik ik een VPN om er omheen te gaan.

Ik ben benieuwd of jij dit hebt kunnen tackelen.

Gr.

Laurens

18

Het is niet gelukt om het op te lossen, Tesla is een black box, kastje en muur. Ik heb uiteindelijk op mijn router een permanente vpn verbinding (via NordVPN) ingesteld en gebruik een route policy om al het verkeer naar tesla via die verbinding te laten lopen.

Groet, Richard

19

Je zou ook nog even contact kunnen opnemen met de HD van Freedom. Misschien is het mogelijk om een nieuwe IP-adres toegewezen te krijgen?

20

Hi, zoals in de initiële post aangegeven, het ip adres is niet het probleem.