- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
07-23-2024 05:10 AM
Hi,
I'm working on a newly created Azure environment with very little networking set up. Our setups are as follows:
Azure:
On-Prem:
I've just managed to get RDP and ping to work, but there was a strange issue (I'm new to all this). The issue was related to how RDP traffic from Azure was detected under the "cotp" app ID instead of "ms-rdp," which I normally see in the logs.
Right now, I'm at a loss trying to get the Azure VM to talk to the on-prem Domain Controller and the file server. The only traffic I'm seeing on the firewall for SMB shows up under the "quic" app ID. I've allowed this traffic to go through, but I still can't access the file server over SMB. No other traffic is showing in the logs except for "quic," which has been allowed. The other weird issue is that I can't see any AD-related traffic at all. I was hoping to see something getting blocked at the very least, but I see absolutely nothing. I've also configured the Azure VM's DNS to point to the on-prem DC, and that didn't help either.
Can anyone please shed some light on whether something is missing? I just want to be able to connect to the on-prem server from Azure via SMB and join the server to the domain but no meaningful traffic is showing up in the logs.
Many thanks,
J
07-29-2024 06:11 PM
So, it turns out that private DNS zone was stopping things from working properly. Weird but as soon as I removed private DNS zone I was able to get SMB and Active Directory to work with on-prem with some further tweaks with network peering in Azure.
Thanks.
07-23-2024 02:32 PM
OS's based on Windows 11 will attempt to utilize QUIC for SMB transfers by default, and RDP traffic being recognized as cotp on the firewall early in the session is not really unexpected in my experience. The SMB traffic should fail back to proper SMB instead of QUIC as soon as the quic connection fails, so the fact that you're not seeing that is a little odd.
When you say you setup a site-to-site with Azure, how exactly did you do that? Did you use a VM-series firewall or did you use Azure's native site-to-site connection capability through a VPN gateway? Can you validate that you followed https://learn.microsoft.com/en-us/azure/vpn-gateway/tutorial-site-to-site-portal properly?
I personally always try to get folks to use a VM-series so that they have proper logging on both sides. Azure's native networking leaves a lot to be desired in that aspect (in my opinion).
07-23-2024 11:14 PM
Thank you for your reply.
I didn't create S2S VPN myself, but I was told it was created using the guide you'd provided. The virtual network gateway was created using VpnGw2AZ - Generation 2. The whole Azure thing is new to me so I'm learning as I go. I will set up logging and see what I can find there. Thanks.
07-29-2024 06:11 PM
So, it turns out that private DNS zone was stopping things from working properly. Weird but as soon as I removed private DNS zone I was able to get SMB and Active Directory to work with on-prem with some further tweaks with network peering in Azure.
Thanks.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!