Kadaster werkt niet op verbeterjehuis.nl

Datasets BAG
#1

The following url to access Kadaster API: https://bag.basisregistraties.overheid.nl/

Cannot be accessed by these Web Applications (their ips):

Test Web App:
51.144.182.8,104.40.218.203,23.97.213.221,51.136.20.166,168.63.99.58, 51.144.182.8,104.40.218.203,23.97.213.221,51.136.20.166,168.63.99.58,104.45.3.231,51.136.16.47,51.144.237.16

Prod Web App:
51.137.106.244,51.145.133.11,51.145.134.235,40.113.126.251,137.117.160.142,51.145.128.185,51.137.106.36,51.145.156.40,51.137.106.244,51.145.133.11,51.145.134.235

Seems Kadaster rejects these ips from connecting to it.

Who can help me?
marlon.mintjes@milieucentraal.nl

#2

I guess you mean the API on https://bag.basisregistraties.overheid.nl/api/v1/ (with api/v1) ?

Did you get an exception or error message that you could share? Maybe even the requests youā€™re trying to do? With just the IPs I havenā€™t been able to find anything in our logs so far.

#3

No connection to the issue described in Vreemd (Python) connectie probleem (geodata.nationaalgeoregister.nl) - Toepassingen - Geoforum ?

#4

Yes API V1:https://bag.basisregistraties.overheid.nl/api/v1/

Error we get: their server does not respond do either our TEST or PROD servers but responds from other locations
System.Net.Http.HttpRequestException: An error occurred while sending the request. ā€”> System.Net.WebException: Unable to connect to the remote server ā€”> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 145.77.103.22:443
at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)
at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
ā€” End of inner exception stack trace ā€”
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
ā€” End of inner exception stack trace ā€”
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable1.ConfiguredTaskAwaiter.GetResult() at TT.ApiGateway.Kadaster.Repositories.Client.<GetAsync>d__4.MoveNext() in D:\a\1\s\src\backend\TT.ApiGateway\Repositories\Client.cs:line 48 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.ConfiguredTaskAwaitable1.ConfiguredTaskAwaiter.GetResult()
at TT.ApiGateway.Kadaster.Repositories.Client.d__51.MoveNext() in D:\a\1\s\src\backend\TT.ApiGateway\Repositories\Client.cs:line 69 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()
at TT.ApiGateway.Kadaster.Repositories.HouseRepository.d__5.MoveNext() in D:\a\1\s\src\backend\TT.ApiGateway\Repositories\HouseRepository.cs:line 79

#5

Is this the result you get with every request, or does it only happen sometimes? If the first, Iā€™m afraid itā€™s got nothing to do with the API.

#6

And the error is clear that their server fails to respond us, and we can call it because it gives us back their IP, this means our servers can kinda reach it for first contact but then their server doesnā€™t respond to us:
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 145.77.103.22:443

We do not have this error outside the TEST + PROD servers

#7

Neem aan dat we in het Nederlands verder kunnenā€¦

Ik lees de error als dat er ā€˜geenā€™ verbinding gemaakt kan worden (ip:145.77.103.22:443), m.a.w. vanuit de TEST + PROD servers kan de ā€˜APIā€™ uberhaupt niet gevonden worden.
Het lijkt er op het request dat jullie sturen niet eens aankomt op de API, m.a.w. dat is iets buiten onze invloedssfeer (op basis van de huidige informatie die we nu zien/hebben)

Dat de IP in het lijstje terugkomt bekent niet dat er ook daadwerkelijk ā€˜connectieā€™ is gemaakt, dit zegt alleen dat de DNS (de naam bag.basisregistraties.overheid.nl) ergens in een lookup table naar IP 145.77.103.22 geresolved is. (gezien die in 't verleden met ā€˜goedeā€™ connecties is ingevuld)

Gezien de lijst met IPā€™s lijken dit omgevingen op Azure te zijn en zoals je aangeeft werkt het wel vanuit andere locaties (ā€œoutsideā€). Wat zijn deze ā€œoutsideā€ omgevingen, de dev/ontwikkel omgevingen van de developers?

Vooralsnog zou ik zeggen dat er iets in de routing vanuit jullie stacks @Azure (?) iets aan de hand is.

Wat ik zou doen, gezien het schijnbaar Windows bakken betreft (D:\a\1\s\src\backend\TT.ApiGateway\Repositories\Client.cs:line) is een terminal/rdp sessie starten en iets van een ping/tracert proberen uit te voeren op de API. (mogelijk misschien wel eerst een browser sessieā€¦)

1 like
#8

We zijn met onze netwerkleverancier aan het kijken in hoeverre er aan onze kant een blokkade zit op deze IPā€™s. Zoals Robin al aangegeven heeft zien wij de genoemde IPā€™s niet terug in onze logging, dus het lijkt erop dat wij nooit een vraag vanuit jullie omgevingen te kijken.

Daarom ook de vraag of jullie zelf ook verder willen zoeken of er wellicht aan jullie kant in de routering iets fout gaat, want jullie zijn de enige gebruiker die deze bevinding heeft gedaan. Alle andere gebruikers (en dat zijn er heel veel op de BAG API) hebben geen problemen met het benaderen van de API.

#9

Dank voor jullie antwoord. Inmiddels doet de verbinding het gelukkig weer. Helaas weten we dus nog niet waar het nu precies aan heeft gelegen.

#10

Zouden jullie nog wel zelf verder willen zoeken of jullie ook iets kunnen vinden in jullie verbinding? Als jullie dat doen dan laten wij ook nog uitzoeken of er aan onze kant een blokkade heeft gezeten. Voor zover ik heb begrepen hebben jullie namleijk al eerder last gehad van een soortgelijke situatie (en toen komen we aan onze kant niets vinden), ik zou wel graag willen voorkomen dat jullie over een tijdje weer problemen hebben.

#11

Gaan we doen! Het is fijn als het inderdaad voor nu altijd opgelost is :slight_smile:

#12

Voor zover ik weet hebben wij niets aangepast, ik wacht nog even op het onderzoek over een mogelijke blokkade in ons netwerk, maar ik verwacht eigenlijk dat daar niet uit gaan komen dat er een blokkade is geweest. Dan zou er nu dus iets gewijzigd moeten zijn aan jullie kant waardoor het weer werkt, en als jullie dat niet kunnen achterhalen vrees ik dat het zeker nog een keer voor gaat komen.

#13

@MC1234 Bij ons is het onderzoek afgerond: er zijn geen blokkades geconstateerd aan onze kant op de genoemde IP-adressen. Wij kunnen daarmee niet anders dan concluderen dat het probleem met de onbereikbaarheid niet aan onze kant heeft gezeten. We hopen dat jullie er zelf achter kunnen waardoor de blokkade wordt veroorzaakt zodat jullie dit voor de toekomst kunnen voorkomen.

#14

@jasperroes: We hebben helaas toch weer een probleem met de connectie met het Kadaster vanuit zoekjeenergielabel.nl. Zie de bijlage met de bevindingen van ons webbureau Dept. Willen jullie hier naar kijken? Kan het te maken hebben met een firewall aan jullie of onze kant? Dank! Annemarie Hop

Zoekjeenergielabel API Kadaster issues

#15

Jasper is begin dit jaar van positie gewisseld. Zijn vervanger is @sylviaverkleij.

#16

Als ik die screenshots zie, lijkt het er meer op dat het om een issue met TLS1.2 gaat.

Ik zou voor de verbinding van een applicatie met een server niet alleen op een ping-utility vertrouwen. Kan de applicatie TLS1.2 aan? Kan de handshake succesvol uitgevoerd worden? Met een browser is bag.basisregistraties.overheid.nl prima beschikbaar. En de server kan best geconfigureerd zijn om een pin-request te negeren. Ik zou dus eerst eens de echte requests vanuit de applicatie loggen, om te zien waar het mis gaat vanuit de applicatie.

#17

Hallo @MC1234. Net als alle twee de vorige keren dat jullie problemen ondervonden is er aan onze kant niets aangepast en zijn er ook geen andere klanten die problemen ondervinden met de bereikbaarheid van deze API. De vorige twee keren hebben wij uitgebreid onderzoek gedaan naar of wij iets konden vinden en hebben we dat ook teruggekoppeld via het forum. Ik heb toen ook gevraagd of jullie zelf al wat meer onderzoek hadden gedaan en daar hebben we niets op teruggehoord. Zonder een veel uitgebreider onderzoek van jullie kant, inclusief de precieze echte request die vanuit jullie applicatie worden gedaan (vanuit de omgeving waar jullie problemen op hebben en die niet aan andere locatie) kunnen wij nu niets doen.

#18

Beste @jasperroes, bedankt voor je reactie en je aanbod om te helpen. Ik heb een account voor het forum aangemaakt zodat we rechtstreeks kunnen communiceren.
Ik hoop dat we er samen uit kunnen komen. We hebben uitgebreid onderzoek gedaan, maar komen er zelf niet uit wat de verklaring is voor het issue.

Je vroeg om een voorbeeld van de precieze aanroep die we doen, deze stuur ik je hier toe:

curl -H ā€˜x-api-key: <API_KEY>ā€™ -H ā€˜Accept: application/hal+json, application/jsonā€™ -H ā€˜Host: bag.basisregistraties.overheid.nlā€™ ā€˜https://bag.basisregistraties.overheid.nl/api/v1/nummeraanduidingen?postcode=3013AA&huisnummer=27&geldigOp=2021-03-24ā€™

Ik ben benieuwd of je hier iets uit kan herleiden.

@sbjager bedankt ook voor jouw reactie. Ik heb deze voorgelegd aan een collega van DevOps die hier eerder al bij betrokken is geweest. Hij gaf aan dat we geen TLS versie pinnen we deze alleen configureren voor de inkomende verbinding en niet de uitgaande waar het nu om gaat. Ik hoop dat ik het zo goed verwoord.

We kijken uit naar jullie reactie.

Met vriendelijke groet,
Arnout Cornelissen
(servicemanager Dept)

#19

Zet de verbose optie eens aan zou ik zeggen, kijken wat curl zelf zegt. -v of --verbose toevoegen aan je commando.

1 like
#20

Zat nog eens te kijken naar die stacktrace. Welke .NET versie targeten jullie? En welke versies staan op jullie test en prod servers? Kadaster ondersteund alleen nog maar TLS 1.2, en als je dat vanuit .NET wil gebruiken moet je 4.7 targeten. En zelfs dan kan het nog misgaan. Check dus de instellingen op je servers, en vergelijk dat met de locaties waar het wel werkt.

Zie c# - TLS 1.2 not negotiated in .NET 4.7 without explicit ServicePointManager.SecurityProtocol call - Stack Overflow

en Transport Layer Security (TLS) best practices with the .NET Framework - .NET Framework | Microsoft Learn