IPFW Can IPFW be bypassed?

Can IPFW be bypassed? And if so what workaround do I need to fix that? Sorry if it has been asked before, a search of IPFW+bypass has few relevant results...

I haven't put any energy into installing IPFW before because my desktop is behind a firewall. But now, I'm configuring a new system which won't be behind a firewall that I control so adding one of FreeBSD's firewall ports would certainly be of big help. While experimenting with IPFW, I added rules so that I have DENY ALL INGOING/OUTGOING by default, and I add ALLOW for outgoing ports that I need one at a time. I use the SECURITY log to detect packets blocked by IPFW so I can adjust my rules.

I noticed that my VirtualBOX VMs aren't blocked by IPFW. These VMs use the network bridged adaptor so their IP4 address is in the same local network as my actual local network. However, I did consider these individual IP4 addresses when creating my rules. This setup is using FreeBSD 10.1. The other system is a FreeBSD 10.3, and it's the SSH trafic that bypass IPFW. I have very similar IPFW rules for that second system.

I do have:
allow ip from any to any via lo0
as the first rule. Would that one be my bypass issue?

Is there someting that would send the TCP/IP trafic to IPFW first, then the other subsystems?

Thanks!
Dominique.
 
A bridge works on the link layer. IPFW, as most packet filters / firewalls, operates on the internet layer. There's no way for it to see ethernet frames that do not use the internet layer of the host it is running on. If you want your own host to filter network traffic for your virtual machines, use routed networking.
 
Thanks SirDice! The link you posted is interesting. I didn't see any sysctl | grep net.link.ether.bridge entries as mentioned in the article so I guess VirtualBOX is using a different technique for their network bridged adaptor (maybe just adding a bunch of IP4 addresses to the ethernet adaptor...). However I did find a sysctl net.link.ether.ipfw entry to 0. I activated it to see what it does. My SECURITY log got filled with a bunch of :
Code:
ipfw: Deny MAC out via re0
ipfw: Deny MAC in via re0
I turned the feature back to off because I don't know what to do with those MAC packets, but at least the possibility is indeed there. For the time being, I'll just put my faith in the hand of my router/firewall (and closely monitor auth.log on my sshd system). ;-)

Dominique.
 
VirtualBox bridged adapter uses a "hack" where the ethernet frames just magically pass in and out of the selected interface on the host system, no bridge(4) involved.
 
Back
Top