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.
Solved! Go to Solution.
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.
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.
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?
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.
ede_pfau wrote:Yes, basically.
The gateway of the private server LAN would be the port on the FGT, not a switch in between. 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.
Thank you Ede! Will set the GW on the FGT port 26 (ie. 192.168.233.1) and set as next hop from the switch where the servers are connected.
on the switch (I know this is not related to FGT anymore, but just to get some ideas), I assume I can have other servers on it (say they have IP of 192.168.133.x and these servers do not need Internet access at all). Could I just create two VLANs. VLAN 233 would be link with FGT port 26 and VLAN 133 will just be local without any Internet access.
Sure. Just create a VLAN port for VLAN 233 on physical port 26.
But hey, to really isolate a server group you could just put them on another port - the 1240 has got some!
Then you can control traffic from and to that group with policies. Works just as good as with a virtual port (VLAN port) but you spare yourself the extra effort to configure a VLAN on the switch.
ede_pfau wrote:Will play around the FGT, never tried setting the interface as VLAN. I do see there is an option to set the interface type as VLAN, 802.3ad Aggregate, Redundant Interface, Loopback, hard switch, soft switch and WiFi-SSIDSure. Just create a VLAN port for VLAN 233 on physical port 26.
But hey, to really isolate a server group you could just put them on another port - the 1240 has got some!
Then you can control traffic from and to that group with policies. Works just as good as with a virtual port (VLAN port) but you spare yourself the extra effort to configure a VLAN on the switch.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1735 | |
1107 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.