tunnel monitor works improperly

cancel
Showing results for 
Search instead for 
Did you mean: 

tunnel monitor works improperly

L2 Linker

hello

 

I am trying to enable the tunnel monitoring for an IPSec tunnel(not sure what device the other end is using) and got very interesting result.

The proxy id config is

local:172.16.17.3/32

remote: 146.48.211.0/24

 

My client subnet 172.16.2.0/24 will be natted to 172.16.17.3/32 while accessing to 146.48.211.0/24.

 

I assigned an IP 172.16.2.222 to the tunnel interface and it is able to ping 146.48.211.163 before enabling the "tunnel monitoring"

146.48.211.163 is being used as the dest IP in the tunnel monitoring config.

 

The result after enabling tunnel monitoring is really interesting and I cannot understand why.

As long as I enabled the tunnel monitor, the tunnel status icon changes to "red" and the tunnel interface is not able to ping the dest IP.

monitor: on
monitor status: down
monitor dest: 146.48.211.163
monitor interval: 2 seconds
monitor threshold: 5 probe losses
monitor bitmap: 00000
monitor packets sent: 118

monitor packets recv: 0

 

1 ACCEPTED SOLUTION

Accepted Solutions

L4 Transporter

Hi @DongQu ,

There are some gotchas when working with tunnel monitor, which is very crucial to remember:

- Tunnel monitor are ping probes that are source from the ip assigned on the tunnel interface.

- Those probes does not pass through any policy (that incluse nat and security) neither the routing tabel. Which means when you run the pings manualy they will match your NAT rule and the source will be NAT-ed behing the ip in your local proxy-id. In addition ping will check the routing tabel before being routed through the tunnel.

- Source and destination of those ping probes must match your local and remote proxy. Because the tunnel monitor probes does not pass through the NAT policy the source is not matching your proxy-id and therefor it will be dropped by the IPsec tunnel.

- The whole purpose of tunnel monitor is to "disable" the logical/virtual tunnel interface if the ping is failing. That is why you will see status as red, while phase1 and phase2 established. Because the tunnel interface is listed as down, the associated static routes will also be "disabled" and will be removed from forwading table (FIB), which will cause your manual pings to fail (no more route to destination)

 

From what I understand you will hide your local network behind one ip address and list only this address in the proxy-id. In that case I believe it is more conviniant to assign the IP that you will use for source NAT to the tunnel interface. After that just change the NAT rule to use interface ip for the dynamic ip and port nat.

 

This way the tunnel monitor probes will be sourced from IP that is part of the proxy-id without the need to add additional addresses to the proxy-id

View solution in original post

1 REPLY 1

L4 Transporter

Hi @DongQu ,

There are some gotchas when working with tunnel monitor, which is very crucial to remember:

- Tunnel monitor are ping probes that are source from the ip assigned on the tunnel interface.

- Those probes does not pass through any policy (that incluse nat and security) neither the routing tabel. Which means when you run the pings manualy they will match your NAT rule and the source will be NAT-ed behing the ip in your local proxy-id. In addition ping will check the routing tabel before being routed through the tunnel.

- Source and destination of those ping probes must match your local and remote proxy. Because the tunnel monitor probes does not pass through the NAT policy the source is not matching your proxy-id and therefor it will be dropped by the IPsec tunnel.

- The whole purpose of tunnel monitor is to "disable" the logical/virtual tunnel interface if the ping is failing. That is why you will see status as red, while phase1 and phase2 established. Because the tunnel interface is listed as down, the associated static routes will also be "disabled" and will be removed from forwading table (FIB), which will cause your manual pings to fail (no more route to destination)

 

From what I understand you will hide your local network behind one ip address and list only this address in the proxy-id. In that case I believe it is more conviniant to assign the IP that you will use for source NAT to the tunnel interface. After that just change the NAT rule to use interface ip for the dynamic ip and port nat.

 

This way the tunnel monitor probes will be sourced from IP that is part of the proxy-id without the need to add additional addresses to the proxy-id

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

The LIVEcommunity thanks you for your participation!