How to put two ports on the same network?

[#1]

We just got a new FortiGate 50B. I' d like to connect it to: - our uplink (a router sitting on the local end of a T1) - our LAN (a switch with a bunch of PCs on it) - and our one public server. I' d like the public server to have a public IP, and the LAN to be a separate private net with NAT. Our T1 comes with a /28 so we have several usable public IPs. The T1 router has one IP, the FortiGate can have a second one (which it can also NAT all the LAN PCs to), and the public server can have a third. It' d be really nice not to have to use a separate switch to sit between the FortiGate, T1 router, and public server. What I need to do is configure the FortiGate such that both the uplink port and the public server port are treated as being on the same /28 subnet, with the FortiGate bridging between the two ports. I asked about this before we bought it, and was told we could do it. Now that I' m poring over the documentation and config interface, I don' t see quite how I' m supposed to...

[#2]

Hi! Actually you can do this with VIP' s. Just define your internal network. then define another (independent) DMZ network for your server. Create a VIP on the external interface and write a policy from " all" to the VIP (so that your server is public). Then define a NAT Policy for your clients from internal to WAN (both policies including the desired services). Now you can connect tho the VIP from internal and wan. On the other hand, you can ope this with routing (had to use it with Netscreen/Juniper devices, since they do not support this *loopback-pat* or whatever you call it.) ut this needs a bit of cooperation of your internat provider. Let' s start off with a simple configuration. your public ip' s (example) 11.2.3.16-31 .16 -Network adress, unusable .17 Router of ISP .18 Your FG .19 - .30 spare .31 - Broadcast adress, don' t use! let' s split this /28 network in two /29 subnets. One is located between the FG and the ISP Router and one is located between your server and your DMZ interface. What' s to change: * change the Netmask of your external interface to /29. * change the ip of the DMZ interface to some IP of the second half, excluding the first and last. (in our exaple 11.2.3.25-30 would be possible, let' s take .25) * change the ip of your server to any other spare from the second subnet. let' s take .26 * default GW of your server is your FG then (.25 !!!) * On ISP' s router: change the netmask from /28 to /29 and write a static route that the Network 10.3.2.24/29 is reachable via gateway 11.3.2.18 (Your external interface of the FG) your public ip' s (example) 11.2.3.16-23 .16 -Network adress, unusable .17 Router of ISP .18 Your FG .19 - .22 spare .23 - Broadcast adress, don' t use! AND your public ip' s (example) 11.2.3.24-31 .24 -Network adress, unusable .25 Your FG' s DMZ Interface .26 Your Server .27 - .30 spare .31 - Broadcast adress, don' t use! That' s it.

[#3]

Splitting our external network into two separate networks, one for DMZ on WAN2 and one for public on WAN1, was one of the first solutions I thought of. Unfortunately, that is an unsupported router configuration from our ISP. They will not change the netmask on our uplink router, so we can' t have a truly separate DMZ on public address space. That is why I wanted to bridge WAN1 and WAN2, so both could have the same subnet with the same netmask, and packets from the public Internet would read the server connected to WAN2. Since this is apparently not possible, the solution seems to be to make a VIP on the public subnet on WAN1 that proxies for the server on WAN2. Either WAN2 must have NAT & private address space, or there' s a way to put the same subnet on WAN1 and WAN2. Either way, I need a solution that does not require changing netmask on the WAN1 subnet.

[rwpatterson]

As far as your ISP is concernered, you have a router with 8 IP addresses in the subnet (for example): 10.10.10.1-8 10.10.10.1 T-1 interface 10.10.10.2 Fortigate and LAN outgoing IP addresses 10.10.10.3 server 10.10.10.4-8 spares On the back end that the ISP doesn' t see, you have your users on the internal port(s), and they' re set to NAT on the way out so the IP they are reporting is the Fortigate IP address. On the internel interface, you can pick whatever IP address scheme you want. This is private to you. The server is set up with a VIP that maps the 10.10.10.2 to the inside address. This too is invisible to the outside world. This VIP mapping could be from the internal port(s) or from the DMZ or even wan2 port. The designations are totally arbitrary. You could use any ports for any purposes. The Fortigate is the Fortigate. If the server is a mail server, you' ll also need to create an IP ;pool with the one single outside IP address so that the incoming matches the outgoing. This is so outside server see the same address. Some servers won' t allow coonections if the two are different. This cuts down on spam.

[#5]

I understand all of this but I don' t think it solves the problem (or at least, fortinet' s documentation doesn' t make clear whether it solves the problem, and I don' t want to take the server down for a maintenance window until I' m confident it will work). It sounds like you' re describing a traditional NAT setup for an outward-facing server with a public proxy IP (VIP in fortinet terms). My probem is that INTERNAL HOSTS MUST USE THE PUBLIC IP to talk to the server. This is important. If internal hosts must use the *private* IP to talk to the server, then the configuration does not meet our needs. I have not yet figured out a way to do what we want, other than to introduce another switch between the firewall and the uplink and put the server on it (which is what we' re currently doing). I' d much prefer to put the server on the WAN2 interface of the firewall.

[Delta]

A much simpler solution is to use an ip pool on your outgoing rules. Step 1. Create your VIP: Name External Interface Static nat External Address Internal Address Port forwarding if you' re restricting ports... Step 2 Create an ip pool Outgoing Users -> start ip - end ip Give this an external ip address DIFFERENT from the extenal address on your VIP Step 3 Create a policy from Wan -> Internal all - VIP Name - always - any - protection profile - accept Enable NAT if it' s not an smtp server Step 4 Create a policy from Internal -> Wan all users - any always any (unless you restrict outgoing ports) protection profile ... Click NAT and click DYNAMIC IP POOL and select the Outgoing Users pool. This makes your users use an ip address different from your external address. You do not need to bind this address - the Fortigate will figure it out. This allows access to the VIP external addy from any internal addy.

[#7]

Thank you, Delta. I don' t understand what the IP pool adds, or what it makes " simpler" , though. Currently, our firewall' s WAN1 interface has address pu.bl.ic.122, and all internal computers that talk to the Internet get NAT' ed to that address. If I create a VIP on, say, pu.bl.ic.123, that would be different from the IP that internal PCs get. Why add a pool, and how does it simplify things?

[UkWizard]

Not sure if i am missing the plot here, but whats wrong with just using vip/nat and having the server in the DMZ port using private ip range thats different to the private lan range? this is the normal setup, and i know of no reason why you shouldnt do that, unless there is some app on the server that insists on using the real public ip address, which is rare nowadays. Using this normal setup, the client pc' s would be able to access the server using the public IP OR the DMZ private ip address. Wheres the problem with that? sorry if i have misunderstood a post somewhere..

[#9]

You' re right, it would be possible to switch the server to a private IP and NAT it. For reasons I won' t go into here, it would be much much preferable to keep the server on its public IP.

[UkWizard]

I have installed hundreds of firewalls, and have only ever seen public ip addresses used in dmz' s once, as their isnt any point. the one i did see what an old old install that wasnt done right in the first place. if you use the traditional method you also have full logging functionality as the logs can distinguish both internal and external source ip connections. as no nat is needed inbound. good luck.

[Delta]

OK. Sorry cos, looks like I misunderstood something from the middle. You have WAN1 on pu.bl.ic.122 - Nat enabled. create your VIP with external addy of pu.bl.ic.123 - Nat enabled. (Do not bind this addy to the wan port). Plug your server into the lan side or the DMZ. Your outgoing users should be able to access the external addy of pu.bl.ic.123 without difficulty. Ours do. Your external users will see the server as tho it' s outside the firewall.