how can a mirror all of the traffic on a network interface, to virtual interface

In your situation I think we can build out two design options that could likely work.

1. Run snort on the router directly.
2. Run snort on a separate box dedicated for this purpose.

Running on the Router

Since you have rolled your own Debian instance for your router, it would simply be a matter of installing, or compiling, the packages for your version/architecture. You could then configure snort to attach to either the inside or the outside interface, depending on which one you want to monitor, and let 'er rip.

This could be easy, would not require adding any more hardware, could be easily reconfigured to run in IDP mode, and would not require any potentially odd network configurations to make work. The biggest downside is going to be performance. Snort can consume an insane amount of resources. It could trivially eat up all the RAM and CPU in a system making your router unable to, you know, route.

Snort has gobs of configuration options. Not just turning on or off rules but whitelisting rules for certain hosts, adjusting the number of bytes of memory used for packet defragmentation, the number of packets to store in memory for TCP stream reassembly, etc. I generally recommend spending an insane amount of time tuning these parameters, and even after you get them set the way you want them to go back and do periodic reviews to see if anything needs to be tweaked.

Running a Dedicated Sensor

This is usually the recommended solution. It solves the network outage problem for resource competition. It allows you to use specially crafted hardware so you can make your sensor do exactly what you want. This will also free you up to add an extra hard-drive to run daemonlogger, or throw in some more RAM without having to deal with scheduling full network outages. It is also more scalable. Sure, I can get snort running on the Pentium 4 whitebox running pfSense at home, but there is no way I will get it to run on a Juniper EX-8216 at work. A purpose built sensor will run just as well in both environments.

The downside is that you're adding yet another system to manage, another box consuming power, more BTU to evacuate, etc. Depending on your network infrastructure it may or may not be easy to get the data into it. The major network vendors all have something to do this. Cisco calls it a SPAN session, Juniper calls it an Analyzer, Enterasys calls it a Mirror. It is possible to perform the same function with iptables using the TEE target, though I don't know any other host firewalls to say whether they can or how to do it. Failing all that you can use a network tap which is a physical device that electrically copies the data stream.

In any case, what you have to do is get a copy of the traffic from your network infrastructure to your sensor. The best way to do this, and the recommended method, is to have two NICs in your sensor: 1 for management and 1 for monitoring. The price of interfaces can vary widely, but unless you're talking about situations with links of greater than 1Gbps, or sustained throughput approaching 1Gbps, cards are pretty cheap. I've been recommending even a simple Intel Pro/1000 GT, the things are $30 and do everything you'll need!

It is possible to run on one interface, but I can't recommend it. You're most likely to run into odd inconsistencies with your monitoring, or potential network issues thanks to the problem of transmitting on a link that is normally expected (assumed?) to be receive only.

There's a fair bit of information available on the snort tag on our sister site for Information Security Professionals.

When I have run snort, I ran it on the router. This doesn't require an additional interface to send the traffic to. The risk is that if snort mishandles data and executes it, it will have easier access to the network than it would have otherwise.