Specify source IP for load-balance health check

[laf]

Hi guys,

I've defined a health check using TCP/53. All is happening on Fortigate 100D, running 5.2.2 and Load Balance module.

I defined a virtual server and then two real servers; trouble is that one real server is behind FGT while the 2nd is reachable over an IPSEC tunnel in another location.

As you can guess, first server is shown healthy while the 2nd one over IPSEC is marked as down. 

Here's my config:

config firewall vip edit "extdns-TCP" set uuid b3f0d4da-a68b-51e6-103a-e99a21773537 set type server-load-balance set extip 64.21.x.y set extintf "wan1" set server-type tcp set monitor "extdns" set extport 53 config realservers edit 1 set ip 172.16.130.101 set port 53 next edit 2 set ip 172.16.151.101 set port 53 set status standby next end next end

And here're the failed attempts of 2nd server health checks:

FG100D(root) # diagnose sniffer packet any 'host 172.16.151.101' interfaces=[any] filters=[host 172.16.151.101] 6.522865 172.16.3.49.12793 -> 172.16.151.101.53: syn 1797401734 6.523058 172.16.3.49.12795 -> 172.16.151.101.53: syn 1349138583

Also here's the routing table:

FG100D (root) # get router info routing-table all | grep 172.16.151 S 172.16.151.0/24 [10/0] is directly connected, MACH

How can I change the source IP address that goes over the tunnel for health check from current: 172.16.3.49 to anything else that's already allowed in tunnel.

Thanks in advance!

[kcuerrier_FTNT]

Hello,

The Source IP cannot be modified for Health Check instances.

The Firmware automatically assumes that there is no routing issue between the Firewall, load balancer and the back end physical server. 

In this case where you are using the FortiGate as the load balancer, it will always use the egress interface primary IP for health Check instances.

The only reason I could see you needing to apply a source IP on a health check is if the back end server resides remotely across a VPN tunnel, in this case apply addressing to the tunnel interfaces.

Thank you

[ede_pfau]

I bet it's not the source address but the return route on the remote end. Can you see any traffic at the remote end, or remote server? Is there a route back to the originating FGT for the source address you see there?

If the VPN policy permits you can send traffic from any source address across a tunnel. Even tunnel establishment is only governed by the destination address. Anyway, if it's a FGT-to-FGT tunnel, you could specify '0.0.0.0/0' in the phase2 Quick Mode selectors if you haven't already.

But I think it's the routing.

[laf]

Hi guys,

Thanks a lot, for your input. I highly appreciated. Now on my issue, I ll share two paths:

1. More insight if you can call it this way about source IP being chosen for health check

2. A workaround to solve the health check after all.

No1:

 - here's my connected routing table

get router info routing-table connected C 10.255.255.0/24 is directly connected, Lo_Test C 64.21.x.y/24 is directly connected, wan1 C 172.16.3.16/29 is directly connected, SC_Interconnec C 172.16.3.48/29 is directly connected, port8 C 172.16.130.0/24 is directly connected, DMZ C 172.25.3.0/24 is directly connected, Internal3 C 172.25.4.0/24 is directly connected, LAN

From my previous post you can see that health check driver/code picked port8 as source IP address, although it's not related by any mean to the IPSEC VPN. As a matter of fact that segment has no FW access and business reason to reach resources over that VPN. 

Next I shutdown (Cisco guy) port8:

FG100D (root) # config system interface

FG100D (interface) # edit port8

FG100D (port8) # set status down

FG100D (port8) # next

FG100D (interface) # end

FG100D # get router info routing-table connected C 10.255.255.0/24 is directly connected, Lo_Test C 64.21.x.y/24 is directly connected, wan1 C 172.16.3.16/29 is directly connected, SC_Interconnec C 172.16.130.0/24 is directly connected, DMZ C 172.25.3.0/24 is directly connected, Internal3 C 172.25.4.0/24 is directly connected, LAN

But I still got same failed health check attempts using SAME IP address:

89.254000 172.16.3.49.17000 -> 172.16.151.101.53: syn 374101849 89.254286 172.16.3.49.17002 -> 172.16.151.101.53: syn 3719936891 91.254012 172.16.3.49.17004 -> 172.16.151.101.53: syn 3362905948

I probably needed to delete/create again health status for that external_over_IPSEC server but couldn't afford it due to production concern in regard to port8 being shut.

So this health check source IP pickup process is special at least.

No2:

The IPSEC tunnel is built with a 3rd party vendor (hope you like this expression :) ), so I can't benefit from the tunnel IP addressing and dynamic routing or 0.0.0.0/0 which I love and use with other Fortigate FWs.

I still think I can address the tunnel on Fortigate and keep IPSEC connection UP, but I am not sure (I can try this on a maintenance window).

Two questions:

 - anyone used addressing on FGT interface tunnel only and not on the other end; does this work?

 - if I ll have IP addressing you guys think health check will be sourced with local tunnel IP address?

Thanks in advance!

[ede_pfau]

This is known behavior in FortiOS: traffic originating from the FGT itself across an IPsec tunnel will be assigned the lowest interface address. Where "lowest" is somehow difficult to define - FortiOS enumerates interfaces in a way that differs from the alphabetical order of their interface names.

If you want to assign a know IP address to such traffic you need to assign addresses to the tunnel ends. IMHO this doesn't have any implications for the rest of the setup (as long as these addresses are unique, and well chosen, preferably from an unused subnet).

Please check the CLI Reference for the "local-gw" option. And I think this is mentioned in a KB article somewhere.

You can immediately check the effectiveness of the assignment by sniffing at the remote end. The incoming policy should allow traffic from the IF subnet, sure.