Hello Matt, Matthew Dillon wrote: ..
You can then treat the TAP interface as a local IP space (or even bridge it if you want). If you treat it as a local IP space you can then use something like PF to NAT it to the outside world and control the bandwidth usage.
thanks a lot for the hint. After playing with both variants, I think I'll stick with the 'local IP space' setup which is connected via NAT to the outside world.
However, I've noticed a minor problem in combination with PF: since the tap interface gets created AFTER vknetd is run, enabling PF in /etc/rc.conf doesn't work in case filtering is also done on the tap interface (unknown interfaces give a parsing errror...). I suppose think it would be a good idea to add an option for vknetd to rc/rc.conf, in order to ensure that the tap interface is already created when PF starts (this further requires the kernel module for the tap interface to be enabled in /boot/loader.conf -- perhaps a comment in the rc.conf man page would help...). Basically the same problem applies to the bridging setup. What do you think?
regards, Andreas
