|
Health probes from a load balancer on Azure by default uses HTTP probes. Though there is no limitation to using any other TCP port, hence some customers may use some other ports, for example TCP port 22 used for SSH.
While using this port, it may happen that the FortiGate doesn't respond to the health probes or simply drop the packets, as this won't be allowed by the local-in-policy.
In such cases, check whether SSH is allowed on the interface, connecting to external and internal load balancers respectively.
edit "port1"
set vdom "root"
set ip 10.240.32.4 255.255.255.0
set allowaccess ssh probe-response
set type physical
set description "WAN"
set alias "WAN"
set role wan
set snmp-index 1
set ip-managed-by-fortiipam disable
next
No responses seen on sniffer, just SYN packets:
diagnose sniffer packet any "host 168.63.129.16" 4 0 a
Using Original Sniffing Mode
interfaces=[any]
filters=[host 168.63.129.16]
2024-09-10 13:10:54.974570 port1 in 168.63.129.16.57623 -> 10.240.32.4.22: syn 1586926946
2024-09-10 13:10:54.974571 port1 in 168.63.129.16.57624 -> 10.240.32.4.22: syn 2816949503
2024-09-10 13:10:55.053353 port2 in 168.63.129.16.57630 -> 10.240.33.4.22: syn 2816083531
Debugs, showing the packet dropped by local-in-policy:
d2024-09-10 14:22:45 id=65308 trace_id=322 func=print_pkt_detail line=5942 msg="vd-root:0 received a packet(proto=6, 168.63.129.16:59987->10.240
.32.4:22) tun_id=0.0.0.0 from port1. flag [S], seq 3488371182, ack 0, win 64240"
2024-09-10 14:22:45 id=65308 trace_id=322 func=init_ip_session_common line=6127 msg="allocate a new session-00029e43"
2024-09-10 14:22:45 id=65308 trace_id=322 func=iprope_dnat_check line=5480 msg="in-[port1], out-[]"
2024-09-10 14:22:45 id=65308 trace_id=322 func=iprope_dnat_tree_check line=824 msg="len=0"
2024-09-10 14:22:45 id=65308 trace_id=322 func=iprope_dnat_check line=5505 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, fla
g-00000000"
2024-09-10 14:22:45 id=65308 trace_id=322 func=__vf_ip_route_input_rcu line=1988 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
2024-09-10 14:22:45 id=65308 trace_id=322 func=iprope_access_proxy_check line=458 msg="in-[port1], out-[], skb_flags-02000000, vid-0"
2024-09-10 14:22:45 id=65308 trace_id=322 func=__iprope_check_one_policy line=2374 msg="policy-4294967295 is matched, act-drop"
Next thing to check is, if trusted host is configured in system admin settings:
config system admin
edit "admin"
set trusthost1 10.251.32.0 255.255.240.0
set trusthost2 10.232.0.0 255.248.0.0
set trusthost3 10.240.0.0 255.248.0.0
set accprofile "super_admin"
set vdom "root"
next
In the above example, trusted host is configured, add the load balancer host address 168.63.129.16/32, in trust host under the 'admin' user. With this, SSH is allowed by the device and the traffic from the load balancer is not dropped by the local in policy.
More information on Health Probes on Azure.
|
