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...

[doshbass]

Hi Cos, I don' t think you can achieve what you are trying to do. I believe (but not completely sure) that you can either have the whole unit in transparent mode or in NAT/Route mode. In transparent mode, all interfaces are on the same subnet. This is no good for your internal network. In NAT/Route mode all interfaces must be on seperate subnets. No good for your server/internet connection. However there are ways around it. By far your best option is to put your server on a new private address and use a VIP on the fortigate to map this to the required RIPE address. This is definately best practice for connecting machines to teh internet for public access. If for some reason you really can' t do this, you can create a new VDOM in transparent mode. In effect you then have two totally seperate firewalls, on can be used for the server and the other for the lan to server/intenet side. This method is complex and not really advised on a 50 due to memory limitations. Jon

[rwpatterson]

Why would you need another switch in the mix? After the T-1 is terminated to good old Ethernet, plug it into the FortiGate and go! Realistically, there is no need to map every PC to a RIPE/ARIN IP address. The Fortigate will NAT the outgoing traffic for you. Save those public IPs for future expansion. Once you have the T-1 plugged in (assuming to the WAN port), and the switch with all your devices as well (internal here), just create a virtual IP to map that ' public' server from a RIPE/ARIN IP to the internal IP address. Make sure in any policy that faces the Internet, you check off the NAT box, or you won' t get far. If the ' public' server is on a third subnet, stick it on the DMZ port, and move the virtual IP definition there instead. Good luck

[#4]

Jon: No good. The public server needs to be accessed from both inside and outside our office. If we put it on the internal network, it would get NATed, and people in the office would need to use a private IP to access it. A majority of them use laptops which they bring into and out of the office. A solution which forces them to change their DNS configuration every time they enter or leave the office, or frob /etc/hosts, or use a totally different set of bookmarks (with virtual web servers answering to the different names), is just too annoying. I want to rely on DNS to give the IP of the public server, and everyone to be able to use DNS to access it, regardless of whether they' re in or out of the office. Bob: Of course " there is no need to map every PC to a RIPE/ARIN IP address" - we just want to do this for *one* server. See my response to Jon, above, for why putting it on the internal net and NATing is not a good solution. Ideally, yes, a DMZ would be the right thing to do. Unfortunately our T1 ISP makes it difficult to split up our public IPs into more than one subnet, and we' d lose some support if we did that. And really the only reason we' d need a DMZ is to make it easier to configure the firewall; other than that, we don' t mind putting the public server on the front network.

[Delta]

Create a new Virtual Domain and put the public server on the lan side of that. The Fortigate will treat it as if it' s a completely separate physical box.

[#6]

I' m not sure how that solves the problem, but maybe that' s because I don' t quite understand virtual domains. If I do what you suggest, will PCs on the internal LAN and people out on the Internet both be able to access the public server using the SAME IP ADDRESS? Remember the LAN is using private IPs and NAT.

[doshbass]

I need to test this, but you can create a VIP on both the public and the LAn side that point to teh same address. Give me a hour or so to prove this.

[doshbass]

Yes that works, you can have the server on an RFC address and create theVIP for theexternal interface and a VIP for the LAN interface. That way anyone typing in the RIPE address for the server will get to it.

[#9]

That may be the best solution for us, thank you! I can' t test this right now because people are using the server, so I' ll have to try it overnight sometime. Does this work if the public server is on the *same* internal network as the PCs? That is, will PCs on the private net trying to reach the server by its public IP be able to reach the virtual IP and have their traffic forward (and double-NATed) back to the internal net? If not, I could put the public server on WAN2 on its own private address space, so either way it sounds like this could work, but I' m curious if you tried it in the above configuration.

[doshbass]

No it won' t VIP and NAT only happen once traffic passes through the FG, you need to set it up on a seperate network, and also for security you should do. Imagine a compromise of the server through some unknown means. If it is on your LAN you are wide open. This way you can be specific about what access is allowed back into teh LAN from your server and tie that down as well.