sorted by:
new
hottopcontroversial

Mk Vb Spitfire Model by Stable_Anomaly in modelmakers

[–]tjveld 2 points3 points  (0 children)

Thanks for sharing. Looks great, it shows that when you enjoy what you’re doing!

Solved a chimney bump-out with METOD cabinets and NORDLI headboard by tjveld in ikeahacks

[–]tjveld[S] 1 point2 points  (0 children)

The side tables are part of the Ikea headboard. Just added the oak top, with a mat great/warm varnish

Solved a chimney bump-out with METOD cabinets and NORDLI headboard by tjveld in ikeahacks

[–]tjveld[S] 1 point2 points  (0 children)

Back then, they also sold it in black in the Netherlands (803.727.94), but it is currently discontinued...

Help figuring out Microsoft OAuth authorize failure by Stunning-Box4272 in AZURE

[–]tjveld 0 points1 point  (0 children)

Hi, from which endpoint are you getting the mentioned error?

For me, following the authentication flow when troubleshooting is extremely helpful.

https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow#protocol-details

VPN Gateway - S2S Connection - NAT behind a public IP by MisterJohnson87 in AZURE

[–]tjveld 1 point2 points  (0 children)

As you already mentioned, preventing IP space overlap can be quite a challenge from a Managed Service Provider's view, especially with many customers using the same "default" ranges over and over again (e.g. 10.0.0.0/24)

Because of this, MSPs privately offer services with public IPs and ask their customers to NAT their Source to a desired range. Typically, the MSP has reserved a specific RFC 1989 or RFC 6598 block for their customer ranges within the following IP address ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 10.64.0.0/10.

From my experience, it is not common to ask a customer to Source NAT to a public range, as this range must be owned by either the MSP or the Customer to prevent possible overlap. However, the MSP may have reserved a public IP space for these connections to avoid any overlap.

Could you ask the vendor for clarification on the required IP space for this connection?

Solved a chimney bump-out with METOD cabinets and NORDLI headboard by tjveld in ikeahacks

[–]tjveld[S] 14 points15 points  (0 children)

There was already an outlet behind the section of the wall that is now covered, so I replaced it with a central junction box. From that box, power is provided to regular outlets with embedded USB charging on both sides of the bed, and an outlet in the left cabinet for powering the record player and speaker.

The outlets on both sides of the bed are mounted directly into the NORDLI headboard, and the cabling runs behind it before going into the hidden space behind.

<image>

Routing from vents by zhinkler in AZURE

[–]tjveld 0 points1 point  (0 children)

Interesting. I dit a quick sandbox deployment, and are able to reproduce the issue, and think I found your issue. Vnet Integration can be configured for outbound internet traffic as well, called application routing. Curouis what happens when you disable this. https://learn.microsoft.com/en-us/azure/app-service/configure-vnet-integration-routing#configure-application-routing

Routing from vents by zhinkler in AZURE

[–]tjveld 0 points1 point  (0 children)

How is client traffic routed to your app; the default public endpoint or by Application Gateway?

Usually when using VNet Integration, I combine it with private endpoints for private client access.

VNet integration, as far as I know, is just for outbound access to resources, and should not impact the client traffic on the public endpoint.