Hello,
For quite a while I've had multiple VIP's created mapping external IP's to internal IP's and it's been working just fine. The policy looks like port 16 (externel) all to switch (internal) VIP and set the service but NAT is not enabled. Everything works fine.
But now I created a DMZ on port 10, I created new VIP's mapping external IP to a new DMZ subnet and did everything the same as I did for the for the internal interface however it appears that NAT isn't working. If I enable NAT (use destination interface address) then things seem to work, able to use the service and ping but I shouldn't have to enable NAT in the policy. This also causes issues with the logs as everything appears to come from the IP address of port 10.
Why does VIP work when creating policies from external to switch (internal) but not when mapping to port 10? Hopefully this makes sense...I can always provide more detail...it's just strange...
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.
There's 3 things
The diag debug flow might shed some light
2nd you pretty much never need a SNAT route on a policy-that's a VIP which the VIP is a DNAT function to begin with
3rd can you shed the configuration of the VIP and the firewall-policy?
But I would start with the diag debug flow to ensure the policy-id(s) in question are the ones you are interested in.
PCNSE
NSE
StrongSwan
For the machine in the DMZ that you are VIP'ing to, can it get to the internet? If NAT inbound makes it work that makes it seem like a routing issue, or the machine doesn't know how to respond to the public host, but with NAT it responds to the DMZ IP which is in the same subnet. Make sure the DMZ host has the right subnet and default gateway, and the DMZ interface matches.
99% the default gateway on the dmz server is somehting other than the FGT dmz port ip.
Following is the logic why it works when source ip nat is enabled.
When we enable source nat to outgoing interface, the packet send out of FGT will have a same subnet ip as the server.
When server has to send a reply, server will see that source ip is from same subnet, so it will arp for the ip (which is FGT dmz ip), FGT will respond to arp and server will send the packet to firewall and firewall will forward the packet.
When we not doing source nat the source ip will be from other subnet and the server will send the packet to the default gateway, which looks like is not FGT, so packet will never reach back.
There are other chances, like firewall allowing only from same subnet etc, but i am pretty confident it is the default gateway misconfiguration.
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 |
---|---|
1714 | |
1093 | |
752 | |
447 | |
232 |
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.