Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
d8c70a99-a39f-4
Participant

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

11 Replies
Vladimir
Champion
Champion

Hmm... Your dropped packet event shows TCP 51004, not RDP.

What do the rule for the RDP logs show you?

0 Kudos
d8c70a99-a39f-4
Participant

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.

0 Kudos
Vladimir
Champion
Champion

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.

0 Kudos
d8c70a99-a39f-4
Participant

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

0 Kudos
d8c70a99-a39f-4
Participant

0 Kudos
Javier_Hijas
Employee Alumnus
Employee Alumnus

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,

0 Kudos
d8c70a99-a39f-4
Participant

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. Smiley Sad

0 Kudos
Matthias_Haas
Advisor

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

0 Kudos
d8c70a99-a39f-4
Participant

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.

0 Kudos
Matthias_Haas
Advisor

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

d8c70a99-a39f-4
Participant

Matthias you are a legend! Smiley Happy 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

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.