(note: dummy WAN ips)
I have WAN Redundancy using system link-monitor.
WAN1: 1.1.1.4/255.255.255.248 (Primary)
WAN2: 2.2.2.4/255.255.255.248 (Backup)
Management Network: 172.16.200.254/24
Type: Software Switch
Role: LAN
Network 1: 10.161.201.0/24
Type: VLAN
Network interface 1: 10.161.201.254/24
Network 2: 10.161.203.0/24
Type: VLAN
Network interface 2: 10.161.203.254/24
Static Routes:
Dest: 0.0.0.0/0.0.0.0
Gateway: 1.1.1.3
Int: WAN1
Prio: 5
Dest: 0.0.0.0/0.0.0.0
Gateway: 2.2.2.4
Int: WAN2
Prio: 10
Policy Route:
Incoming int: Network interface 2
Source Add: 10.161.203.0/24
Dest Add: ALL
Protocol: ANY
Outgoing int: WAN2
Gateway address: 1.1.1.3
Firewall Policy:
Network Int 1 to WAN1 (Primary)
Network Int 1 to WAN2 (Backup)
Network Int 2 to WAN2 (Primary)
Network Int 2 to WAN1 (Backup)
Mgmt to WAN1
WAN to Mgmt
WAN delegation:
Network 1 uses WAN1 as primary, WAN2 as backup
Network 2 uses WAN2 as primary, WAN1 as backup
Question/Issue:
Network 2 use WAN2 as primary link, now Network 2 users need to access a Server that is sitting on the Management network with WAN 2 IP assignment, i tried creating policy route but still unreachable.
Server they are trying to reach is 1.1.1.5 which within the zone of WAN1, so i tried creating another Policy route to reach this IP via WAN 1 from Network 2 but still no luck.
Policy Route:
Incoming int: Network interface 2
Source Add: 10.161.203.0/24
Dest Add: 1.1.1.5/32
Protocol: ANY
Outgoing int: WAN1
Gateway address: 1.1.1.4
Server has Virtual IP and IP Pool setup, and access from the external network is working fine
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Thanks everyone, Hairpin NAT fixed the issue.
Resolution:
- Stop Policy Route to LAN to Server (Internal IP)
- FW Policy from LAN to DMZ, destination is VIP, NAT enabled.
- No additional Policy Route from LAN to WAN with destination public IP of Server
Created on 08-12-2022 02:50 PM
Hello @lucky_santiago ,
Thanks for reaching Fortinet Community. From the diagram and the requirement it seems like this is an asymmetric routing case. In such case by default FortiGate will be dropping the packets unless manually enabled on the firewall. More info regarding the very same in below link
Hope this helps.
Thanks,
Hi Aashiq,
Thanks for this, I tried enabling asymroute but unfortunately still not working.
I also got a reply from support and suggested hairpin NAT: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-Hairpin-NAT-VIP-in-policy-rout...
Created on 08-12-2022 08:42 PM Edited on 08-12-2022 08:43 PM
Did the TAC person run "flow debug"? That would show you exactly why it wouldn't be able to reach.
I don't think this is "asym routing" issue. Besides, if you did that, you must have lost almost all firewall features. Unless you want the FGT just as a router, you don't want to enable asym routing.
I'm thinking more simple like "you have to do the hairpin because 1.1.1.5 is on the FGT, it would never go out wan2 to come back to wan1, but you don't have a policy from Network2 to wan1", or something like that.
Again the flow debug would show that if that's the case.
Toshi
Thanks everyone, Hairpin NAT fixed the issue.
Resolution:
- Stop Policy Route to LAN to Server (Internal IP)
- FW Policy from LAN to DMZ, destination is VIP, NAT enabled.
- No additional Policy Route from LAN to WAN with destination public IP of Server
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.