Well, this sounds like a lot of work.

How deep down do you want to go?

It would take most of a lifetime to support all the different network cards, not including the ones that have binary proprietary firmware blobs that you can't just get working easily. That's months and months of reading documentation (where it's even available) and testing. If you use Linux existing network drivers that's all sorted for you though.

Once you support all the types of network card you want to support then you can move onto implementing a tcp stack and ip stack, and all the things on top.

You also have to consider you need an OS to load those drivers into, which you'll have to create if you're not using Linux or similar. Luckily you chose to implement on top of Linux so you'll not have to worry about that.

Implementing and ip stack with ipv4 and IPv6 is within realms of possibility and you could probably do this in a few weeks if you're a competent network programmer. Look into lwip and similar projects to see how this can be done. Similarly with iptables which is relatively simple really.

It's the stuff underneath that's the pain in the ass.

Good luck, you'll definitely need it!

Well, I understand it's a learning exercise, but if you try to do everything in userspace you open up a Pandora's box of security vulnerabilities and slowdowns (several context switches per package means you won't be getting gigabit speeds). That's why things like iptables are in the kernel in the first place.

That said, you can definitely do everything in userspace. Have you read and digested the Stevens opus? I do not believe there is a better work in the field.

You can open each network interface in the SOCK_RAW mode, which will give you raw network interface data.
You can also just do open() on each of the network interfaces (open("/dev/eth0") and whatnot)
Make sure that Linux does not care about those interfaces -- from Linux's point of view, those interfaces should be closed/down/unconfigured!
Because you will now be doing the job of ARP and ICMP and IP and UDP and TCP and the "route" command and the DHCP client and all the rest.
There are also various intermediate solutions. You might want to check out the results of "linux user space networking."

Another less intrusive option is to use the Linux TUN/TAP module to create a virtual ethernet network interface in which you receive raw ethernet packets and have to parse them, read their MAC addresses and route them, do ARP and all that. Then you just set up a bridge (or something) between your public-facing interface and that virtual interface and you can implement whatever logic you want. This is considerably harder than just making a virtual IP interface where you receive IP packets though.

There are different variants of Linux and Linux like OS's which would be more appropriate than generic Fedora or whatever. IPTables is just one system, something like OpenBSD might be more appropriate. Either way, you would still be fiddling with the OS networking additional to the programming. The old school way would be to use SNORT to read packet contents and make routing decisions. Personally if all you are doing is routing, and not value adding like building a firewall with a gui, I'd just use a routing specific variant of linux : https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributions

If you're brave and at least moderately comfortable with Linux, I recommend picking a minimal distro (or doing something like Linux From Scratch) and writing a kernel driver.

It isn't *that* hard and it's a great bit of practice in discipline and care, because your goofs won't just segfault - they'll panic and drop the entire machine :-)

You can start out doing a mod of ipchains or iptables or whatever flavor, and as you poke around and get comfortable with the APIs, start writing your own basic module that does something similar.