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

FGT60D Policy Routes always denied

Hoping somebody can help me get Policy Routes working on an old FGT60D v5.2.0. I realise it's an old firmware but not able to upgrade for the moment!

 

The FGT60D has an ISP WAN interface, a LAN interface for my regular home network, and a DMZ interface on 192.168.0.1/24, which is my home lab network. My home lab has a Palo Alto VM on 192.168.0.254, which is the outside "untrusted" interface for my lab.

 

I want internet SMTP traffic to be routed out the DMZ port without address translation to my home lab. There's no blocking of SMTP by my ISP; I'm currently using destination NAT on the FGT60D to a postfix VM in my home lab, which works fine, except that the source of all mails are shown as 192.168.0.1. And that's what I want to try to solve with policy routing. My understanding is that the onbound SMTP will hit the Palo Alto with the original source address. 

 

No matter what I've tried, I can't get it working, and can only see connection attempts as "deny" in the Local Traffic logs:

 

Deny log: deny — ImgBB (ibb.co)

Policy Route: policy-route — ImgBB (ibb.co)

IPV4 Policy: ipv4-policy — ImgBB (ibb.co)

 

Hopefully I'm even in the right ballpark using policy routing in the first place to try and preserve source IP. Any help would be really appreciated. 

3 REPLIES 3
SJFriedl
New Contributor II

ntmc01 wrote:

Hoping somebody can help me get Policy Routes working on an old FGT60D v5.2.0.

From the deny log it looks like 176.* is the outside address of your Fortigate, and you're trying to pass that *destination* address through the Fortigate unchanged - which should be straightforward - through the DMZ over to a different firewall, the Palo Alto.

The thing I'm confused about: if you enable NAT, it should be converting the *destination* IP, of 176.* to 192.168.*, not the *source*, so something just doesn't feel right here. Do you also have NAT turned on in the Palo Alto?

 

If you look at your IPv4 policy page in Sequence mode, what's policy #0?

ntmc01

SJFriedl wrote:
you're trying to pass that *destination* address through the Fortigate unchanged

Not quite, I want there to be no source address translation at all, so that the source is the last public address before

hitting my SMTP server. 

 

On the Palo Alto I have 'no source translation' configured in the NAT policy, so it's essentially transparent in terms of source, with postfix logs showing the source as being the FortiGate's gateway:

 

May 8 15:32:12 mid-smtp-01 postfix/smtpd[1863]: connect from unknown[192.168.0.1] May 8 15:32:13 mid-smtp-01 postfix/smtpd[1863]: 26E7C60DD404: client=unknown[192.168.0.1]

 

I feel like if I can forward SMTP to port 25 on the PA on 192.168.0.254 without source translation, in the same way I'm doing from the PA to the SMTP server, it would achieve what I want. Policy route sounded like the way to go, but every combination I've tried doesn't work.

 

Feel like I'm doing something silly in the policy rule or completely misunderstanding how this would work.

 

SJFriedl wrote:

If you look at your IPv4 policy page in Sequence mode, what's policy #0?

 

Not sure there's a sequence tab in v5.2.0, but I don't see a policy #0. I presume this is implicit deny? I have a standard deny any/any all/all rule at the bottom for logging purposes. 

SJFriedl
New Contributor II

I suppose if it were me, I'd get into the CLI and run something like:

 

diagnose sniffer packet any "tcp port 25" 4

 

and see what's doing this translation in the Fortigate; maybe it will tell you something?

 

Do you have a Virtual IP defined anywhere that shares the public IP?

Labels
Top Kudoed Authors