Skip to main content
rcslab
rcslab
New Member
February 21, 2018
Solved

FortiGate 1240B configuration for computer connect directly on the physical interface

  • February 21, 2018
  • 1 reply
  • 10373 views

We have some computers that are configured with public IP address, the current setup looks like top left corner of the attachment.

Because these servers are directly on the Public Internet, we would like to apply some policy to the incoming traffic, so I'm wondering if it is possible to do something like bottom left of the attachment

 

 

Currently, I have 1 server connected to port 21 with the following configuration of system interface and policy.  When I do a test ping to the server 73.xxx.xxx.100 I do see the IMCP packet come into port 27 but I don't see the ICMP to port 21.  I am guessing port 21 is not configured correctly or I'm missing some other policy?

 

config system interface edit "port21" set vdom "root" set allowaccess ping set vlanforward enable set type physical set description "Test Server NIC1" set alias "WebServer" set snmp-index 31 next end

 

config firewall policy edit 55 set srcintf "port27" set dstintf "port21" set srcaddr "all" set dstaddr "73.xxx.xxx.100" set action accept set schedule "always" set service "ALL_ICMP" next end

Thank you for your help.

Best answer by ede_pfau

As the FGT is acting as a router you cannot have the same subnet on different ports. Each port spans a broadcast domain of it's own.

Put your servers on inside ports (as depicted) but with IP addresses of a private LAN (RFC 1918). Then, create port forwarding Virtual IPs to direct traffic from WAN to those server ports, across policies. The FGT will not only proxy arp for the external address of a VIP but apply source NAT to outgoing traffic for those protected servers.

 

I wonder how you survived with your servers on a WAN switch up until today.

1 reply

ede_pfau
SuperUser
ede_pfauAnswer
SuperUser
February 21, 2018

As the FGT is acting as a router you cannot have the same subnet on different ports. Each port spans a broadcast domain of it's own.

Put your servers on inside ports (as depicted) but with IP addresses of a private LAN (RFC 1918). Then, create port forwarding Virtual IPs to direct traffic from WAN to those server ports, across policies. The FGT will not only proxy arp for the external address of a VIP but apply source NAT to outgoing traffic for those protected servers.

 

I wonder how you survived with your servers on a WAN switch up until today.

rcslab
rcslabAuthor
New Member
February 21, 2018

ede_pfau wrote:

As the FGT is acting as a router you cannot have the same subnet on different ports. Each port spans a broadcast domain of it's own.

Put your servers on inside ports (as depicted) but with IP addresses of a private LAN (RFC 1918). Then, create port forwarding Virtual IPs to direct traffic from WAN to those server ports, across policies. The FGT will not only proxy arp for the external address of a VIP but apply source NAT to outgoing traffic for those protected servers.

 

I wonder how you survived with your servers on a WAN switch up until today.

What I didn't put down is there is a PANW FW sitting between public Internet and the 12-ports switch, what we are interest is getting some stats/report from FGT and so would like to move them to the FGT.  So your suggestion is as follow:

 

 

Basically, reIP the servers with private IP (ie. 192.168.2.xxx), on the FGT do a IPV4_VIP (73.x.x.100 <=> 192.168.2.100, etc.) and update the policy to route traffic to 192.168.2.1 for these servers?

ede_pfau
SuperUser
ede_pfau
SuperUser
February 22, 2018

Yes, basically.

The gateway of the private server LAN would be the port on the FGT, not a switch inbetween. Even if the 'switch' 192.168.2.1 is a PANWFW, it would run in transparent mode; even then, the next hop is the FGT.

 

The routing is done with a static route (a default route in this case). The policy will decide which sessions are allowed, and in which direction.

 

Best practice would be to avoid the range 192.168.[0-3].x - there are too many network devices with default addresses in that range. 192.168.233.0 would be fine, 172.16.11.0 and 10.11.12.0 as well.

Terms & ConditionsAccessibility statement