Router – How to map the fixed external IP to the router

Because FTP is an awful protocol (there, I said it!):

[12:45:21] 227 Entering Passive Mode (173,14,245,129,6,64).
[12:45:21] Opening data connection to 173.14.245.129 Port: 1600
[12:45:21] LIST -aL
[12:45:34] 425 Can't open data connection.
[12:45:34] PORT 10,0,0,200,10,252
[12:45:34] 200 PORT command successful.
[12:45:34] LIST -aL
[12:45:34] 150 Opening ASCII mode data connection for /bin/ls.
[12:45:55] 425 Can't open data connection.

You see where your FTP client attempts to open a second connection to 173.14.245.129:1600? That's the 'data channel', which uses a seperate high-number port for return traffic/data. In Passive Mode, the server says "Please connect to x.x.x.x:y for the data channel."

You will have to configure a range of data channel port numbers to use in your FTP server and then allow them through the firewall. Active mode will probably not work unless you are allowing all outbound traffic.

Also, for the love of whatever computer Gods there may or may not be, please do not open NetBIOS and LDAP to the public internet and then post your IP address on ServerFault!

Whether to use a router or a switch at a service provider's edge is typically dictated by the manner in which the IP range will be delivered to you.

An address range which the provider gives you with an "upstream gateway", and no routing configuration at your end has to have a layer two connection to the gateway (or simulated as such; cf Proxy ARP) in order for the packets to flow. When a packet gets to the upstream router, it assumes that the destination address is on the local L2 segment, and will just ARP away for it. That means you need to have a switch (or other L2 network) for all of the consumers of the address space. That doesn't mean everything has to be directly connected, though -- if you place a router at your end and run Proxy ARP on it, you can still do L3 filtering (firewalling) on the traffic before it gets to the destination; you just have a more complicated and hard to debug network environment.

Since that can be quite an undertaking for a larger netblock, it only tends to happen for smaller blocks, or providers who don't know what they're doing. At the big end of town, you'll typically get a very small range (or even a point-to-point link) between the service provider's router and yours, and all additional netblocks will be routed to your router via that address.

For instance, if you've been assigned 192.0.2.0/25 as your big-chunk-of-IP-addresses, you'd also be given a smaller allocation (say 192.0.2.192/29) and be told, "the upstream gateway is 192.0.2.193. You then configure your routers (HA pair, natch) to have IP addresses 192.0.2.194 and 192.0.2.195, and configure 192.0.2.196 as the HA IP that one router of the pair will have "control" of at any given moment. You then tell the service provider, "please route my big-block-of-IPs to 192.0.2.196, and then either router can handle the traffic, depending on which one has the speaking stick at the time.

An additional useful benefit of this approach is that multiple blocks can be routed to the same IP, reducing the hassle factor of lots of fiddly network configs over the same L2 segment. You also don't have to waste the first and last addresses of the block on network and broadcast addresses, because you're not actually "subnetting" in that sense, merely routing chunks of address space.