Re: Off-topic venting of frustration (was: fully transparent ftp-proxy and other stories...)
> Oh well, having just learnt the astonishing truth that OpenBSD CD > images aren't available for download, the (probably unrealistic) > possiblity of deploying an OpenBSD based firewall this Saturday rather > than the planned Linux deployment has just dropped to precisely 0%. This is the funniest thing I have heard in a while. If you were planning on downloading the IMAGE and burning it to a CD, what exactly is preventing you from downloading the tarfiles and burning THEM to a CD? IT'S THE SAME FRIGGIN THING! > Sorry to complain, just feel the need to vent my frustration at the > fact that it appears I can't get hold of a copy of OpenBSD at short > notice... In fact, it is EASIER to download a few 10's of megs worth of .tgz files than it is to download a 640M iso image. I can pull them down, burn the cd, and have the firewall installed in the time it takes be to pull down a single RedHat ISO. -kj
Re: Off-topic venting of frustration (was: fully transparent ftp-proxy and other stories...)
On Fri, Nov 08, 2002 at 03:14:58AM +, Roy Badami wrote: > Sorry to complain, just feel the need to vent my frustration at the > fact that it appears I can't get hold of a copy of OpenBSD at short > notice... Excuse me? Of course you can. You just grab a few tarballs and do an install via any one of myriad ways, though preferably via a network mechanism. Piece of cake. Despite having CD media available, I, and many others, have done *hundreds* of installs precisely this way, on production machines. What is so difficult about this? Might not have inet access? Who cares?! Since this would presumably be a firewall for other networked machines, why can't you just install via one of them? Please don't complain. Many have gone before. jsyn
Re: fully transparent ftp-proxy and other stories...
Check out the Hut project. It's a FreeBSD implementation of the VRRP
protocol, including Load Balancing via VIP's. There has been a port to
OpenBSD as well (no personal experience).
Looks interesting, but it's not what I'm after.
What I need to be able to do is the equivalent of:
nat on fxp1 from $NET_INTERNAL to any -> { 1.1.1.1, 2.2.2.1 }
So that half the internally originated traffic will appear to come
from one address, and half from the other. The two addresses are from
different providers, and policy routing in the cisco routers will
ensure they're routed out of the correct leased line.
-roy
Re: Off-topic venting of frustration (was: fully transparentftp-proxy and other stories...)
On Thu, 2002-11-07 at 22:14, Roy Badami wrote: > Probably for the best anyway, I guess building a firewall on an > unfamiliar OS in a hurry is not the best idea in the world... Without question. -J.
Off-topic venting of frustration (was: fully transparent ftp-proxy and other stories...)
Oh well, having just learnt the astonishing truth that OpenBSD CD images aren't available for download, the (probably unrealistic) possiblity of deploying an OpenBSD based firewall this Saturday rather than the planned Linux deployment has just dropped to precisely 0%. Maybe I'll just play with an FTP install, and delay deployment to a future date, but there's no way I can deploy critical infrastructure without install media (particularly in the case of a piece of infrastucture the failure of which would take out my net access). Probably for the best anyway, I guess building a firewall on an unfamiliar OS in a hurry is not the best idea in the world... Sorry to complain, just feel the need to vent my frustration at the fact that it appears I can't get hold of a copy of OpenBSD at short notice... -roy
Re: fully transparent ftp-proxy and other stories...
On Thu, 2002-11-07 at 21:45, Roy Badami wrote: > Unfortunately (or in reality, fortunately), the prospects of being > multihomed are looking at least possible in the near future, and so > there's a significant chance I'm going to want to do load balancing > NAT, for which I believe netfilter/iptables is pretty much my only > option at present (short of shelling out lots of cash :) > > It's quite tempting to use OpenBSD as my firewall and Linux as my load > balancer, but that's an extra machine and an extra point of failure, > not to mention significant extra complexity... :( Check out the Hut project. It's a FreeBSD implementation of the VRRP protocol, including Load Balancing via VIP's. There has been a port to OpenBSD as well (no personal experience). http://www.bsdshell.net/hut_vrrpimpl.html http://www.backwatcher.com/~matheny/ -J.
Re: Bridging and NAT
> This is one of those cases where it's easier to try than to speculate :) > > Daniel > I've tried a similar setup, on a box with a 4 port nic and 2 on the motherboard. It does work. My setup: fxp0 = external interface fxp1 = internal nat interface dc0-dc3 = bridged. I had a crossover cable from one of the bridged interfaces to fxp1. It all worked. ~Kirk
3.2 pf bridge patch?
on the errata page for 3.2, a patch was released yesterday for pf running in bridge mode with scrubbing enabled. I am currently running a 3.1 system with the latest refrag patch. Does that have the same problem? if so, will the supplied patch apply cleanly? Or should I make the changes by hand? -- Paul B. Henson | (909) 869-3781 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768
Re: Bridging and NAT
On Thu, Nov 07, 2002 at 07:35:31AM -0500, Jason Dixon wrote: > The responder quickly flamed him for bridging and NAT'g at the same > time, but I think he was having a brain fart. Isn't it conceivable to > support a configuration like this, where you'd want to filter incoming > traffic across a transparent bridge, while also NAT'g for your internal > network? Or am I just too damn tired and missing something? I don't see why the setup he suggested wouldn't work out of the box. As long as both the external interface and the internal one for the NATed clients have IP addresses assigned, IP forwarding is enabled, default gateways set on clients and firewall, etc. it should just work. He's not suggesting adding that internal interface to the bridge, after all. And if the external interface has an IP address assigned, it will work as expected, even if it is part of a bridge. The bridge detects packets directed to the bridge itself, and hands them to the stack. This is one of those cases where it's easier to try than to speculate :) Daniel
Bridging and NAT
Someone on the misc@ list had an interesting question, but he got quickly trounced by someone, for no discernable reason, IMHO. This guy has a box with bridging between fxp0 and fxp1, and NAT from his internal network on fxp2 to the address on fxp0. The responder quickly flamed him for bridging and NAT'g at the same time, but I think he was having a brain fart. Isn't it conceivable to support a configuration like this, where you'd want to filter incoming traffic across a transparent bridge, while also NAT'g for your internal network? Or am I just too damn tired and missing something? TIA, J.
Re: pf and altq
On Thu, Nov 07, 2002 at 12:50:08PM +0100, Stefan Sonnenberg-Carstens wrote: > Read about the effort to migrate pf and altq in the CURRENT changes, > so how will it look like ? you will have to wait. but it looks cool '-) I hope to have the initial version ready within a week. i'm close to that.
pf and altq
Read about the effort to migrate pf and altq in the CURRENT changes, so how will it look like ? Stefan Sonnenberg-CarstensRHCE & System-/Netzwerkadministrator-CoolSpot AGAm Albertussee 1 D-40549 DüsseldorfTel +211 50 66 1-0 Fax +211 50 66 1-11http://www.coolspot.de- Vorstand: Roland Bongartz Aufsichtsrat:Dr. jur. Marco Picozzi (Vorsitzender),Prof. Dr.-Ing. Karl Friedrich Triebold,Heiko Hubertz Amtsgericht Düsseldorf HRB 37696
Re: dDoS attacks
Han Boetes wrote: Not so much as a direct reply but more as to share what happened when I was ddossed a few month ago. The thing that brought my pc to it's knees was pflog trying to log it all. Once I found that out I disabled logging and Then I hardly had a connection because my upload caused by the replies of my return-rst firewall stuffed the upload. After that I disabled return-rst I got a continous stream of 50kb/s and I barely noticed I was ddossed. So my suggestion would be to put in triggers in pf that would go of at certain levels that would indicate a ddos, after which logging and return-rst is disabled. Perhaps pflog could go in another mode that gathers much less detailed info. one could accomplish such a thing without any changes to pf - just a small daemon (perhaps a script) which monitors some statistic (eg.g. denied packets) and switches rulesets if it is exceeded. -d
