An attempt was made to access a socket in a way forbidden by its access permissions

[jaspernygaard]

We have .net core WebAPI running in Azure via an app service plan and having trouble connecting to an on-premise database. Network wise, we have setup an ExpressRoute assigned the correct vlans and subnets and we can actually tcpping the oracle listerner on port 1521.

However we get the following error, when trying to connect via the dotConnect driver (v9.7.734)

Code: Select all

An attempt was made to access a socket in a way forbidden by its access permissions

So we have build 2 console apps, just reading the Oracle DB system time - one for .net 4.7 and one for .net core 3.1. The .net core 3.1 app throws the same Devart.Data.Oracle.OracleException as mentioned above, however the .net 4.7 one works.
Any input on what could be the problem?

App Service is configured for the .net core 3.1 runtime stack.

[Shalex]

1. Are you using OCI mode (via Oracle Client) or Direct mode? Try changing the mode, does this make a difference?

2. Your .NET Core 3.1 application works with https://www.nuget.org/packages/Devart.Data.Oracle/ (.NET Standard 2.1), doesn't it?

3. Does your .NET Framework 4.7 application work with the package https://www.nuget.org/packages/Devart.Data.Oracle/ (.NET Standard 2.0) or with assemblies from the provider folder "C:\Program Files (x86)\Devart\dotConnect\Oracle\" (.NET Framework 4.7)?

JIC: the issue could be caused by .NET Core 3.1 framework, for example https://feedback.azure.com/forums/16938 ... oject-from

[jaspernygaard]

Hi Shalex,

1. we are using direct mode, as we do not have an oracle client installed on the Azure Web App (it a PaaS service)
2. The .net core 3.1 application does not work with the Devart.Data.Oracle.EFCore 9.12.1064, however as a .net core 2.1 it does
3. Yes - works with the nuget package - haven't tried the installed assemblies.

So a little more information since my post. If we don't route via a custom VNET to our on-premise database, but connect to a public oracle listener, it actually works with .net core 3.1. The case you linked seems to be the same error. I've got a case open at Azure support and they are looking into the memory dump of the error.

[jaspernygaard]

So been troubleshooting the issue with Azure Support, but no real answer of what could be wrong. Found a couple of post on github and SO regarding forcing the TCPClient to run IPv4 - anyone know if it is possible configure the dotConnect driver to force IPv4?

E.g. https://stackoverflow.com/questions/597 ... -it-cannot

.https://github.com/Azure/azure-sdk-for-net/issues/7899

[Shalex]

Try setting the Host (or Server or Data Source) connection string parameter to IPv4 address explicitly.

[jaspernygaard]

Hi Shalex,

I've been reading through the dotConnect for Oracle documentation regarding settings it up for IPv4 without any luck. It is possible to do via the connection string? Or can it be configured in code?

Any information is greatly appreciated.

[Shalex]

IPv4 -> "Host=192.168.10.137;SID=ORACLE19;Direct=True;User Id=scott;Password=tiger;"

IPv6 -> "Host=2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d;SID=ORACLE19;Direct=True;User Id=scott;Password=tiger;"

Domain name -> "Host=dboracle;SID=ORACLE19;Direct=True;User Id=scott;Password=tiger;"

[jaspernygaard]

Of course - connected by domain name, and it tried via IPv6. Setting the IP did indeed force it to connect via IPv4.

Thank you!!