Skip to main content
ntmc01
ntmc01
New Member
May 8, 2021
Question

FGT60D Policy Routes always denied

  • May 8, 2021
  • 1 reply
  • 3885 views

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. 

    1 reply

    SJFriedl
    SJFriedl
    New Member
    May 8, 2021

    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
    ntmc01Author
    New Member
    May 8, 2021

    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
    SJFriedl
    New Member
    May 8, 2021

    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?

    Terms & ConditionsAccessibility statement