Skip to main content
A
Anonymous_User
Contributor
April 12, 2007
Question

How to put two ports on the same network?

  • April 12, 2007
  • 12 replies
  • 12596 views
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...

    12 replies

    doshbass
    doshbass
    New Member
    April 12, 2007
    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
    rwpatterson
    New Member
    April 12, 2007
    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
    A
    Anonymous_UserAuthor
    Contributor
    April 12, 2007
    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
    Delta
    New Member
    April 12, 2007
    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.
    A
    Anonymous_UserAuthor
    Contributor
    April 12, 2007
    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
    doshbass
    New Member
    April 13, 2007
    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
    doshbass
    New Member
    April 13, 2007
    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.
    A
    Anonymous_UserAuthor
    Contributor
    April 13, 2007
    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
    doshbass
    New Member
    April 13, 2007
    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.
    A
    Anonymous_UserAuthor
    Contributor
    April 14, 2007
    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.
    A
    Anonymous_UserAuthor
    Contributor
    April 17, 2007
    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
    rwpatterson
    New Member
    April 18, 2007
    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.
    Delta
    Delta
    New Member
    April 23, 2007
    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.
    A
    Anonymous_UserAuthor
    Contributor
    April 23, 2007
    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
    UkWizard
    New Member
    April 23, 2007
    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..
    A
    Anonymous_UserAuthor
    Contributor
    April 23, 2007
    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
    UkWizard
    New Member
    April 23, 2007
    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.
    Show more replies
    Terms & ConditionsAccessibility statement