Port Forwards for IP Ranges

[MikOnsite]

Hello!

So we have recently gained a new client who is trying to install a Infotronics GT-400 hand punch time clock.  They had a Fortigate E60 that was installed by a previous IT provider and we are new to this product.  The payroll servicer is Paycor and they provided a list of IP ranges that need allow outbound/inbound traffic for HTTP (80), HTTPS (443) and SMTP (25).

Inside the Fortigate GUI, we went to Addresses and created an entry for each range and then created an address group containing each of the individual range entries.  We then went to the IPv4 Policy section and created a new policy by listing the WAN connection as the Incoming Interface, the internal LAN as the Outgoing Interface, our address group as the Source and the reserved time clock IP as the Destination.  We set schedule as Always and chose HTTP, HTTPS and SMTP as the Services.  We left the action as ACCEPT.  IP Pool Configuration was set to Use Outgoing Interface Address with default Proxy Options.  The policy was enabled at this time.

My question is simply ... did we do this correctly and should it allow traffic across the address group as we intended?

Any help or insights would be welcomed as it seems the time clock is stuck on "please wait" when trying to communicate.

[lobstercreed]

Hi James,

While I could be wrong, I'd be willing to bet your next paycheck (lol) that your rule is backwards of what it needs to be (if not, NAT needs to be turned off).  A few salient points:

[ol]

"IP ranges that need allow outbound/inbound traffic" -- which is it?  Inbound or outbound?  It will never be both, and anyone who says that doesn't know firewalls.  All traffic is bidirectional, yes, but only one side starts a given conversation and that's the side that matters to any modern, stateful firewall (the last 30 years).

Most likely it is outbound (the clock connecting out to Paycor at the specified IPs) which is why I think your rule is just backwards.  This is further supported by the list of services you mentioned.  Check your hit count on the incoming rule -- likely 0.  Just reverse that rule (interfaces and addresses) and see if that solves your problem.

If inbound is required, you can't build it the way you described because the packet coming from the outside will not be destined for W.X.Y.Z private (RFC 1918) address that you're using.  If inbound is needed (such as when you're hosting your own web server), you have to create a VIP that translates a public IP from your WAN to the internal IP of the end host.  Then you build your firewall policy from whatever to the VIP, not to the end host address object.  That's another reason I'm quite certain no inbound traffic is required.  You would potentially need a separate public IP for each and every time clock which is crazy expensive for most organizations.

Never, ever NAT an incoming rule (WAN -> LAN).  NAT is for outbound only (LAN -> WAN).  When you do it inbound you lose any potential logs that exist at the endpoint telling you where the traffic came from.  It will all look like it came from your firewall instead.[/ol]

Hope that helps! - Daniel