Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
dhafer
New Contributor II

pre_route_auth check fail(id=0) vip loadbalancer issue only in one firewall (HA setup)

Hi,

 

I have 2 firewalls A & B on High-availability active-passive,
On firewall A: WAN1 is the internet facing interface
On firewall B: WAN2 is the internet facing interface
WAN1 & WAN2 are in a zone WAN

 

I have mutliple public ips and I am using one let's say 133.133.133.133
I set multiple vip loadbalancer over 2 servers 192.168.50.1, 192.168.50.2
- 2 public 133.133.133.133 (http/https) using WAN interface
- 1 private with ipaddress 192.168.55.55 used in vpn ipsec tunnel with gateway address 133.133.133.133,

The issue is when I am on firewall A everything works as expected, when I switch to firewall B, traffic to load balancer stop working,
and when I did debug the issue I got pre_route_auth check fail(id=0), drop.

Can someone help me?

Have a nice day.

 

Some configs
# wan https load balancer
config firewall vip
edit "HTTPS_LOAD_BALANCER_A"
set uuid ea1eb11c-14f4-51ef-aa57-d27495e4cc85
set type server-load-balance
set extip 133.133.133.133
set extintf "any"
set server-type https
set http-ip-header enable
set monitor "HC_PING"
set color 17
set extport 443
config realservers
edit 1
set ip 192.168.50.2
set port 443
next
edit 2
set ip 192.168.50.1
set port 443
next
set ssl-mode full
set ssl-certificate "cert_2023"
next
end
# vpn facing load balancer
config firewall vip
edit "VPN_PROD_LOADBALANCER"
set type server-load-balance
set extip 192.168.55.55
set extintf "any"
set server-type https
set color 8
set persistence ssl-session-id
set extport 443
config realservers
edit 1
set ip 192.168.50.1
set port 443
next
edit 2
set ip 192.168.50.2
set port 443
next
end
set ssl-mode full
set ssl-certificate "cert_2023"
next
end

# vpn ingress firewall policy
onfig firewall policy
edit 77
set name "INGRESS CCC PROD"
set srcintf "MY_VPN"
set dstintf "NET-PRIVATE"
set srcaddr "REMOTE_CCC_ADDRESS"
set dstaddr "VPN_PROD_LOADBALANCER"
set action accept
set schedule "always"
set service "HTTPS" "PING"
set utm-status enable
set inspection-mode proxy
set ssl-ssh-profile "certificate-inspection"
set logtraffic all
set nat enable
next
end

# wan ingress firewall policy
config firewall policy
edit 26
set name "WEB_LOAD_BALANCER"
set srcintf "WAN"
set dstintf "NET-PRIVATE"
set srcaddr "all"
set dstaddr "HTTP_LOAD_BALANCER_A" "HTTPS_LOAD_BALANCER_A"
set action accept
set schedule "always"
set service "HTTP" "HTTPS"
set utm-status enable
set inspection-mode proxy
set ssl-ssh-profile "certificate-inspection"
set logtraffic all
set fsso disable
set nat enable
next
end

3 REPLIES 3
Anthony_E
Community Manager
Community Manager

Hello dhafer,

 

Thank you for using the Community Forum.

I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

 

Regards,

Anthony-Fortinet Community Team.
Anthony_E
Community Manager
Community Manager

Hello dhafer,

 

We are still looking an answer for your question.

We will come back to you ASAP.

 

Regards,

Anthony-Fortinet Community Team.
Markus_M
Staff
Staff

Hi dhafer,

 

not sure about the layout generally. I follow but am not sure if that is supposed to be set up this way as HA might synchronize The routes. My first idea is that there is a routing mismatch on the second firewall while some route might be pointing to wan1 instead of wan2. Maybe not route but a session list.

 

One thing to clarify though. Do you get that error when failing over or is this a fresh connection after you failed over?

 

Debug can be interesting to see where the packet is arriving at and maybe leaving. This might help you to find something interesting (I guess your debug is from something similar):

diag debug console timestamp enable

diag debug flow filter port 443

diag debug flow filter addr <at best your client IP address>

diag debug flow show iprope enable

diag debug enable

diag debug flow trace start 20 (=20 packets)

 

And then connect.

You will see some output that shows a "trace_id" which indicates the packet number. Check the first few lines of the packet you will see in inbound interface, the idea of FortiGate on where to route the packet and in the last lines what the decision is.

 

Best regards,

 

Markus

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors