Skip to main content
laf
laf
New Member
November 9, 2016
Question

Specify source IP for load-balance health check

  • November 9, 2016
  • 1 reply
  • 11902 views

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!

1 reply

kcuerrier_FTNT
Staff
kcuerrier_FTNT
Staff
November 9, 2016

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
SuperUser
ede_pfau
SuperUser
November 9, 2016

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
lafAuthor
New Member
November 11, 2016

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!

Terms & ConditionsAccessibility statement