Address to use for Tunnnel Monitoring with Azure VPN

Reply
Highlighted
L3 Networker

Address to use for Tunnnel Monitoring with Azure VPN

I have used this KB article to configure an IPSec tunnel to an Azure network

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm6WCAS

That has worked fine and the tunnel is up and passing traffic.  However I want to enable tunnel monitoring.  In the section "Tunnel Interface" point 2 says "Assign an IP on same subnet as the Azure Gateway for dynamic routing and/or tunnel monitoring inside the IPv4 tab." but I can't work out what address they mean.  As it is an unnumbered VPN, the only address I have for the Azure end is the external internet address (13.93.153.246 in the example) so I clearly can't pick an address in that network.

 

Does it mean use an address in the remote azure network (192.100.0.0/16 in the example)?  Because I can't see what other addresses are available.  What's confusing me is if I did, presumably that address would be seen as local to the VPN gateway, rather that down the tunnel, so surely it wouldn't pass the ping responses down the tunnel?

 

The address I will be monitoring will be a host in the 192.100.0.0 network, I understand that, it's the address to assign my tunnel interface I am struggling with.


Accepted Solutions
Highlighted
L3 Networker

Thanks for the reply, I had completely forgotten about this post. It was the source address I was enquiring about - the tunnel monitor pings need to come from the tunnel interface which, from the KB information, doesn't use an address in order to bring up the VPN.

 

In the end I got it working by assigning my tunnel interface an IP address in an internal network (using the examples in the KB article that would be the 192.168.1.0/24 network) and the monitoring is working OK, that did not break the VPN and it doesn't seem to care that the tunnel interface is nowhere near the network that it has taken an address from, I guess it intercepts responses to that address before processing routing.

View solution in original post


All Replies
Highlighted
Cyber Elite

Most traditional VPN configurations allowed an option to have the tunnel interface use a IP.

In appears in Azure that this is not possible.

 

Yet, Tunnel monitoring could be used to monitor an IP in your 192.100.0.0/16 network.

 

If your FW is monitoring an remote (Azure) network IP and that devices fails to respond, then your tunnel would be considered down.

 

Isn't this what you were looking for.

 

I do not believe the remote VPN tunnel monitor requires the remote tunnel interface have an IP, only an address that your local FW can ping/monitor....

 

What other questions can I answer?

Help the community: Like helpful comments and mark solutions
Highlighted
L3 Networker

Thanks for the reply, I had completely forgotten about this post. It was the source address I was enquiring about - the tunnel monitor pings need to come from the tunnel interface which, from the KB information, doesn't use an address in order to bring up the VPN.

 

In the end I got it working by assigning my tunnel interface an IP address in an internal network (using the examples in the KB article that would be the 192.168.1.0/24 network) and the monitoring is working OK, that did not break the VPN and it doesn't seem to care that the tunnel interface is nowhere near the network that it has taken an address from, I guess it intercepts responses to that address before processing routing.

View solution in original post

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 Live Community as a whole!

The Live Community thanks you for your participation!