Redirect VIP to Internet with Central NAT

[tdh2112]

Hey All,

I am having an issue with setting up VIPs to redirect incoming traffic on a FortiGate with Central NAT enabled to a remote public IP.

A few months back, I had a need to change existing VIPs that mapped from public to private, so that the new mapped IP was another public IP that is not ours. I found this article, and it all worked nice a smooth from testing to deployment in production. This was on a 200F at 7.2.8 without Central NAT. The one strange thing is that I don't get any hits on the Policy Routes.

Now, I have to configure the same thing on two more FortiGates, both also at 7.2.8 - one is a 200F without Central NAT and the other is a 100E with Central NAT enabled. I'm having an issue with the 100E. There is a Central NAT policy that says any>internet / src all | dest all / NAT as outgoing interface. There are three other policies that should not be affecting my traffic as they have defined interfaces and addresses that are not involved with this. The 100E has four WAN connections, zoned as "Internet".

I should mention that we are not changing the existing VIPs until we have been able to test the IP forwarding, which is where we are now.

• I created 28 new test VIPs using different public IPs with our test IP as the "Mapped From" and the remote public IP as the "Mapped To" and all ports defined appropriately (some translated). Note that we needed that many VIPs because some of these services need multiple ports.
• I created four new Firewall Policies (there are four services involved) to allow the traffic to the remote IPs over the appropriate ports (the translated-to ports, where needed).
• I created Policy Routes to direct the traffic back out on the same interface that it came in.

Only 6 of the VIPs worked, and all were matching one of the Firewall Policies. I think I found the reason that 2 of them did not work. They applied to the same Firewall Policy as the 6 that did work, but I realized that with Central NAT, the order of the VIPs matters and found a VIP with the same IP and no ports defined above the more specific new test VIP with ports defined. I moved the less specific VIP down to the bottom and will test again this afternoon when we have another testing session planned.

For the other 20 test VIPs though, there are no conflicting less specific VIPs that could be the cause. When I view the Forward Traffic log and filter by the dest or src IPs, I do not see any traffic being denied or accepted. I do plan to run a packet capture to see if the IPs and Ports are being hit.

Here are some questions that I have:

1. If I see traffic coming to the correct IP and Port in the packet capture, but do not see traffic in the Forwarding Log, does that indicate a problem with the VIP, or with the Policy?
2. Does the ingress/egress packet flow change with Central NAT? I do know that without Central NAT, VIP processing occurs before firewall policies are evaluated, followed by routing.
3. Is there anything else I should be zeroing in on to figure this out?

Thank you all for any guidance you can provide!

[rahulkaushik-22]

@tdh2112 

Here are some questions that I have:

1. If I see traffic coming to the correct IP and Port in the packet capture, but do not see traffic in the Forwarding Log, does that indicate a problem with the VIP, or with the Policy?

     Ans: Check MAC address of the destination and make sure it's Fortigate MAC. Sniffer captures traffic on wire so you will also seen the traffic not belongs to Fortigate.

1. Does the ingress/egress packet flow change with Central NAT? I do know that without Central NAT, VIP processing occurs before firewall policies are evaluated, followed by routing.
   Ans: No, it does not change with Central NAT. In Central NAT, VIP is done at the kernel level and you need to select private IP belong to VIP in the firewall policy not VIP object. Infact you would not seen VIP objects in the policy.
2. Is there anything else I should be zeroing in on to figure this out?
3. I created Policy Routes to direct the traffic back out on the same interface that it came in.
   I don't think policy routes work on reply traffic. It only works for original direction.
   
   Please run dia de flow for the traffic and see what it reveals
   
   dia de flow filter addr x.x.x.x ------> x.x.x.x IP address of the client or actual server
   dia de flow filter port Y ---------> Relevant port
   dia de flow trace start 20 --> capture 20 lines
   dia de en
   
   dia de dis/ dia de reset : To stop capturing
   
   
4. 
   
   

[tdh2112]

Thank you for your reply, Rahul!

Ans: Check MAC address of the destination and make sure it's Fortigate MAC. Sniffer captures traffic on wire so you will also seen the traffic not belongs to Fortigate.

Okay, understood.

you need to select private IP belong to VIP in the firewall policy not VIP object. Infact you would not seen VIP objects in the policy.

I do have the Mapped To addresses as the Dest in the policies.

I don't think policy routes work on reply traffic. It only works for original direction.

The policy routes are basically set to Incoming: "WAN1" | Outgoing: "WAN1" | Src: 0.0.0.0 | Dest: "%OURTESTIP%" | Gateway: "%WAN1DG%". So, that should handle the original traffic, correct?

[rahulkaushik-22]

Hi @tdh2112 
Please provide more information about the topology. Why is there a need to configure VIP on wan1 to wan1? We usually use VIP to access resources on private IPs.  
It seems like you want the firewall to inspect before reaching the server.
Check dia de flow output. Refer to the article: https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-First-steps-to-troubleshoot-connecti... to run dia de flow on Fortigate.

Regards, 
Rahul Kaushik

[tdh2112]

@rahulkaushik-22 

We previously had VIPs configured for public to private. However, we are moving the processing of this data off-site. The data is sent in by thousands of devices out in the world, so reprogramming all of those would be a monstrous task. Therefore, these packets that currently come in through Wan1, will need to get forwarded on to thew new destination by the firewall.

Regardless, we have it working now. I added a comment to this thread with more details on what fixed it.

[tdh2112 · Accepted solution]

We got this working!

As it turns out, I had to change the interface on the VIPs from 'wan1' to 'any'. As soon as I made that change, it started working perfectly. I don't quite understand why that worked, but it did.