Electrical – Put firewall hardware with ethernet ports between serial ports

At least three reasons, probably:

1. In the era when RS-232 ports were common, it so by far the most common means of bit-at-a-time communication, so much so that the term "serial port" became synonymous with "RS-232 port"; using the term "serial" in connection with anything else would add confusion. Note that USB avoids such confusion mainly because it seldom referred to as "Universal Serial Bus", so the existence of the word "serial" in its long-form name is a non-issue.
2. In nearly all cases, RS-232 ports their logic-level equivalents transmit individual bytes as they are received from software, and individual incoming bytes available to software as they are received. By contrast, most Ethernet devices will wait until software has supplied an entire packet (between 64 and 1536 bytes) before they begin transmission, and will wait until they have received and validated an entire packet before they make any of it available to software. Although bits and bytes might be sent over the wire serially, software neither knows nor cares. It just knows that some short time after one controller is fed a packet and told to send it, another controller will report that a packet is available, and allow software to read it.
3. A "serial port" is guaranteed to transmit bytes of data in the chronological sequence that software supplies them, and make them available to software in the chronological sequence they are received; it would be rather useless if it did not. All Ethernet and Internet systems guarantee that when a packet is sent from one node to another the arrangement of bytes made available to the recipient will match the arrangement of bytes supplied by the sender, but there is no common specification requiring that the chronological order in which data are transmitted have any relation to their arrangement within a packet. Further, there only guarantees that can be made with regard to chronological sequencing of packets relative to each other are highly vague. If packet X is delivered Sunday at 11:47am and packet Y is delivered the next day at 3:28pm, one can safely assume that Y was sent after X. On the other hand, if X is delivered at 1:47:12 and Y is delivered at 1:47:15, it's entirely possible that Y was sent first but X took longer to arrive.

Incidentally, a 10-base-T Ethernet connection sends individual bits in sequence, but higher-speed cabling often uses various signalling methods to send multiple bits at once.

This should be achievable with the UNO and the Ethernet shield. For extra serial comms ports the software serial library works well, but you shouldn't need it to begin with as the arduino communicates with the Ethernet shield via spi. The mega has hardware uarts and more memory, which is useful as memory can run out quite quickly as your code grows.

Without spoiling the fun of working it out, try setting up the arduino as a server with a fixed ip. Then use software on the pc such as hyper terminal or putty to connect to that IP address. The arduino Ethernet library page has good code examples. E.g. http://arduino.cc/en/Reference/ServerConstructor