# transparent proxy without firewall



## kilgor (Aug 10, 2013)

Hello folks!

I want to set up transparent proxying functionality on some FreeBSD system, but i'm not sure what facility should *I* choose to forward packets to the proxy port.

I don't want to recompile the GENERIC kernel (so *I* can't use ipfw forwarding), so *I* hope maybe there is another appropriate way to deal with this task.


----------



## storvi_net (Aug 10, 2013)

Hey kilgor,

ipfw is loadable as module. See ipfw in FreeBSD Handbook for further information.
You CAN compile it inside the system (statically), but you do not need to.



> ... IPFW is included in the basic FreeBSD install as a run time loadable module. The system will dynamically load the kernel module when rc.conf contains the statement firewall_enable="YES".  ...



Regards
Markus


----------



## kilgor (Aug 11, 2013)

No, sir!

You sure can use ipfw without recompiling the kernel, but you can't use the `ipfw fwd` statement. To do this you must recompile the kernel with the option IPFIREWALL_FORWARD. And after that `dmesg` will show you the desired 'rule-based forwarding enable' and `ipfw fwd` will work.

I heard pf can do forwarding without recompiling the kernel, but *I* am not sure if it wise to use two firewalls simultaneously.

I hope there is a more proper solution.


----------



## kilgor (Aug 11, 2013)

DutchDaemon said:
			
		

> DutchDaemon; Yesterday at 19:06. Reason: Several fixes, but mostly: I is good, i is very bad: http://en.wikipedia.org/wiki/Capitalization#Pronouns




Thanks, DutchDaemon! I get it! But I can't find how to edit own messages to fix my last one! Sorry for that!


----------



## wblock@ (Aug 11, 2013)

Why not just use pf(4)?


----------



## storvi_net (Aug 11, 2013)

@kilgor: Sorry I missed it. Then I would also recommend pf.

Regards
Markus


----------



## kilgor (Aug 12, 2013)

Thanks for the participation, guys!



			
				wblock@ said:
			
		

> Why not just use pf(4)?



I can't for some reasons (there other people working with this box and all of us have been stuck with ipfw(4) for years. plus there is a slightly complicated firewall config so I am a little afraid to rewrite it for pf(4)). I can add pf(4) to an existing system (as an addition to ipfw(4)), but I am not sure how this going to work exactly. Is it a reliable way to do such things?

So I really hoped there should be another, simple way to forward few HTTP packets to the proxy port. Now I guess it is not so simple, huh?


----------



## kpa (Aug 12, 2013)

Forwarding to a proxy always involves a NAT of some sort and for that you need a NAT engine. PF is just one of the easiest ones to configure, hence the recommendation.


----------



## kilgor (Aug 19, 2013)

I'm sorry about the absence, guys!

I clearly get the point about pf(4). But as I mentioned I'm stuck with ipfw(4) and can't recompile kernel. So would it be reliable and painless to run two firewalls (second - pf(4) - just for forwarding) simultaneously? And what do you guys think about such things as, for example, `rinetd` and `portfwd`. Would they match my needs?


----------



## throAU (Aug 19, 2013)

kilgor said:
			
		

> So would it be reliable and painless to run two firewalls (second - pf(4) - just for forwarding) simultaneously?



You're worried about migrating from `ipfw` to `pf`, yet you're willing to entertain the prospect of complicating things way more by running multiple firewall engines on the same box?

I suspect performance would be heavily impacted (your packets will be run through both engines), and who knows if default behaviour will change in a future release (which engine sees packets first for example - which may potentially break your rule-sets).  I.e., you are setting yourself up to be one of the obscure, poorly regression-tested edge cases that break unexpectedly at some point in the future during an update.

The only options I'd personally consider would be a kernel recompile or re-education of the `ipfw` guys.  No it's not the answer you want, but it is the only sane solution.  Running through 2 firewall engines on the same box is just begging for future problems and performance degradation IMHO.

So no, I personally don't believe it will be either reliable or painless, let alone both.

2c: Don't go there.


----------

