- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Re: Azure VPN and UDR
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Azure VPN and UDR
Hi,
This is a tricky one to explain - but basically i have a point2site VPN to Azure.
My Azure VNET is carved into multiple subnets, for 1 of the subnets (MGMT) i have route defined to for 0.0.0.0/0 with the next hop as the CloudGuard. Any VMs on this subnet can access internet via the cloudguard and can access other subnets without any problems.
The problem i have is that when i connect my Point2Site VPN i cant RDP to a VM on the MGMT subnet. I can RDP to any other subnet and i can even RDP from the MGMT subnet to any other subnet.
In the logs i can see the connection being dropped, but doesn't specify the rule thats dropping.
Im totally stuck, so any help would be great.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmm... Your dropped packet event shows TCP 51004, not RDP.
What do the rule for the RDP logs show you?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Vladimir,
Its odd cause i can't see any rule picking up the RDP traffic originating from the VPN address. all i see is this dropped log.
To me it looks like the log is showing the connection of the was dropped back to the VPN machine and the outbound port is 51004.
10.10.227.36 is the MGMT VM and 10.10.7.131 is my VPN VM.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am, not being very proficient in Azure but OK with AWS, would like to clarify something:
Do Asure UDRs allow you to setup routes that depend on protocols or port numbers?
If yes, which is pretty doubtful, they are still just routes external to the instance (or VM) that you are trying to connect to.
If your default gateway (CloudGuard) is defined in UDR and you want to use RDP coming from different source, you may have to hard code the return rout in the OS of the system that you are trying to access.
So "route add -p point2site_range MASK x.x.x.x Azure_VPN_gateway.
Unless I am off by a mile...
Typically, there are Jump (or bastion) hosts used for remote access.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Vladimir,
The UDRs are setup to route based on CIDR with the next hop as being Virtual Network Gateway, Virtual Network, Internet or Virtual Appliance.
For the internet traffic, i have set the CIDR to 0.0.0.0/0 and next hop as the virtual appliance being the CloudGuard.
I have also tried adding a static route, but still get the same issue.
Maybe i should set the CIDR as 10.10.7.0/24 and next hope as virtual network or Virtual Appliance???
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi d8c70a99-a39f-4e73-8ae4-72a99ac8e406
I recommend you following that packet step by step to understand what is going on. Something that could happen is that the RDP answer is getting to the gateway through a different interface which might be enough as to drop that packet. Try also opening the log details to see if you find more information on the drop reason. I am still not sure I fully understood the flow you are trying, if you document the topology and flow with a diagram post it here and I am sure it will get more clear.
HTHs,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the reply Javier. I will upload a diagram to try and make it clearer.
Ultimately i just want to route all subnet traffic out of the CloudGuard but continue to allow RDP traffic from the Point2Site VPN. It seems that when i setup the UDR for the MGMT traffic it drops RDP inbound.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
from my experience it is always good to check the effective routes on the interfaces of the VMs:
(in my sceenshot we don't see any routes as the VM is not running):
If you just have modified the default route, then traffic within your VNET will not be routed through the CloudGuard as there is still a system route for the vnet
Matthias
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Matthias,
The routes are below, but I'm confused because all the other subnets that dont have UDR, but contain the default routes can all RDP to the VPN Subnet and Vice Versa. So it is something to do with the UDR routing 0.0.0.0/0 to the cloudguard.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
<because all the other subnets that dont have UDR, but contain the default routes can all RDP to the VPN Subnet and Vice Versa
In my opinion this is because the vnet route (10.10.224.0/22) is still valid, so traffic from/to subnets in this VNET is not routed to the cloudguard. You have to replace this route with a UDR, pointing to the cloudguard (and you have to do this in every subnet). After that, the traffic will be routed to the cloudguard (if this is what you want) ?
Matthias
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Matthias you are a legend! Thank you so much.
Basically what i did in the end was set the VPN subnet 10.10.7.0/24 with the next hop as the Virtual Gateway and it all sprung into life.
Thanks everyone for the help.
Cheers
![](/skins/images/BFDD56B372A07FDFABDEF003EE622D96/responsive_peak/images/icon_anonymous_message.png)