Re: route-to
Danny Kjærgaard <[EMAIL PROTECTED]> wrote : > I was wondering if route-to and reply-to would help me. I have a box > with 2 external nic hooked up with 2 dsl lines, with a default gateway > each, and one internal. On the inside i have aprox 100 users. Can i use > the route-to and reply-to to split up load? And how would the conf look > like, nat and route-to. Upgrade your system to OpenBSD-current and use load-balancing feature with pf. See this message http://marc.theaimsgroup.com/?l=openbsd-misc&m=103852811324894&w=2 from Ryan McBride for a complete explanation (section "BALANCING TWO INTERNET CONNECTIONS" for your configuration). Foxy. -- Laurent Cheylus <[EMAIL PROTECTED]> OpenPGP ID 0x5B766EC2
RE: wireless interface sharing same subnet as wired
Ok, let me start over. What I want to be able to do is share a single IP subnet between two private network interfaces. Client 1: ethernet cable. 192.168.1.50 / mask 255.255.255.0 Cleint 2: wireless 192.168.1.60 / mask 255.255.255.0 With a 3-interface OpenBSD firewall in between the two. The fireall would bridge the ethernet and wireless so that both clients could connect directly to each other (ping or otherwise). And both clients would NAT out the same common public interface. The wireless network would use enhanced WEP + mac filtering for security. Not perfect, but suitable for the intended application. Stephen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2003 11:51 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: wireless interface sharing same subnet as wired I think you will need to run DHCP for your wireless (or some other 'infrastructure'daemons) on your PRIVnet, filter these ports from the PUBnet - but then just treat the wi0 as part of your internal network for NAT - when you say bridge you don't mean 'transparent bridge' right? I don't think that works with NAT. um no. -Original Message- From: Stephen Gutknecht (OBSD-PF) [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2003 8:45 AM To: [EMAIL PROTECTED] Subject: wireless interface sharing same subnet as wired Hi, Is there a way with OpenBSD 3.2 to "bridge" the wireless and wired interface. I have a 3-leg firewall: wi0 - private wireless fxp0 - public interface fxp1 - private interface I have seen Linux and WinXP firewalls that allow you to bridge the private and wireless interface to allow a single IP subnet. Also need to NAT on the public interface for both private interfaces. Any suggestions on how to configure this with OpenBSD 3.2? Thank you.
Re: set loginterface
you just don't get it. It is entirely useless. EVERYBODY understands that, except for you. On Sun, Mar 09, 2003 at 05:49:41PM +0100, Cedric Berger wrote: > Henning Brauer wrote: > > >Obviously, nobody of you has thought through the consequences of collecting > >the stats on each interface. > > > How do you know such a thing? > As I said, I've a patch that did that in the past, for 3.0 > or 3.1. So obviously I know something about the > consequences on the code. > > However, I'm not saying we need to do it. I don't know. > You're raising some good points. Yor example, 'pfctl -si' > would clearly need to take an extra argument, like 'pfctl -si fxp0' > > Yes, this will make the kernel a bit more complicated, > but also note that it will make the userland simpler. i.e, > "set loginterface" end friend could can go AWAY. > > We can surely have a good discussion about the plus > and minuses of doing that, but with sentenses like > "I do not want this bloat in pf", it is difficult to have > a healthy discussion. > > Personally, I like orthogonality. If loginterface is useless, > why not killing it? if loginterface is useful, why restricting > to one interface? > > I guess the question we need to know is the how ppl > use that feature, and for what. I've no hard feeling about > implementing that or not, but if ppl find it useful, I don't > think it's impossible to implement cleanly. > Cedric > > >
Re: set loginterface
Henning Brauer wrote: Obviously, nobody of you has thought through the consequences of collecting the stats on each interface. How do you know such a thing? As I said, I've a patch that did that in the past, for 3.0 or 3.1. So obviously I know something about the consequences on the code. However, I'm not saying we need to do it. I don't know. You're raising some good points. Yor example, 'pfctl -si' would clearly need to take an extra argument, like 'pfctl -si fxp0' Yes, this will make the kernel a bit more complicated, but also note that it will make the userland simpler. i.e, "set loginterface" end friend could can go AWAY. We can surely have a good discussion about the plus and minuses of doing that, but with sentenses like "I do not want this bloat in pf", it is difficult to have a healthy discussion. Personally, I like orthogonality. If loginterface is useless, why not killing it? if loginterface is useful, why restricting to one interface? I guess the question we need to know is the how ppl use that feature, and for what. I've no hard feeling about implementing that or not, but if ppl find it useful, I don't think it's impossible to implement cleanly. Cedric
Re: Why isn't this port blocked?
* Peter Gorsuch <[EMAIL PROTECTED]> [08.03.2003 00:01]:
> pass in inet proto { tcp, udp } from any to any port 5899 <> 5911 keep state
> pass out inet proto { tcp, udp } from any to any port 5899 <> 5911 keep
> state
> pass in inet proto { tcp, udp } from any to any port 5799 <> 5811 keep state
> pass out inet proto { tcp, udp } from any to any port 5799 <> 5811 keep
> state
Just replace <> with ><.
ftp-proxy
Hi, I need to enable ftp in the following to machines across a PF box doing NAT but cant get my head around it at all :-( 130.177.x.x 10.25.x.x public network private network ftp server (10.25.10.10) I want people on the private network (130.177.x.x) to be able to ftp to the ftp server on 10.25.10.10 I guess I need to set up ftp-proxy for this ? I enabled ftp-proxy in inetd running on port 8081 and added the rdr rule from any to any as per the man page but I cant seem to get a data connection established, I can log in authenticate via ftp and when I do an ls it breaks Im sure im missing something realy obvious can someone point it out to me please ? Regards Dan
route-to
Hi I just saw the webcast from linuxforum 2003 where daniel spoke about pf. I said something about the route-to as a solution about obsd not supporting more then one default gateway. I was wondering if route-to and reply-to would help me. I have a box with 2 external nic hooked up with 2 dsl lines, with a default gateway each, and one internal. On the inside i have aprox 100 users. Can i use the route-to and reply-to to split up load? And how would the conf look like, nat and route-to. -Danny
Re: Log Tickets was >> RE: set loginterface
Since the tree is already locked for 3.3, this is a post-3.3 issue, so there's no reason to get agitated over it yet :) These counters are increased with every packet, and per-packet cost has the most impact on performance (as compared to per-connection), so this has to be efficient. Associating the right counters with a given interface pointer (struct ifnet *) in O(1) (constant time, independant of the number of interfaces) is therefore what we need. Traversing the list of interfaces linearly to find the right pointer is not good enough, and hashing a pointer into an array index seems overkill as well. A good solution would be to add a field to struct ifnet itself (either the counters themselves or a pointer to an optional sub-struct), then the access would be of constant time. We'd have to adjust the pf ioctl to fetch statistics for a specified interface and add some switch to pfctl so you can specify it on the command line. This part wouldn't be much of a problem. Let's postpone this after 3.3-release, when we have all the time we need to do it right :) Daniel
Re: Log Tickets was >> RE: set loginterface
On Sat, Mar 08, 2003 at 10:07:34PM -0700, [EMAIL PROTECTED] wrote: > but I am definitely taking notes!...about how many interfaces are there in a > (GENERIC) kernel? I hadn't even though about them.(ruff estimate's ok, a > specific answer would just be a wasted on me) ~=) too many. write a short loop tracersing the interface list and print oyt interface name and ifindex. you can steal the code from ifa_load in pfctl_parser.c. > A Question: is it of value for PF to log to pflog0 'ticket' activity - maybe > based on a switch in rc.conf? pf=[YES|NO|TICKET] ? I don't see why this would be of use. if at all it could make sense on pfsync0, but even that I doubt.
