Re: HELP with reply-to
Zitiere "Alexey E. Suslikov" <[EMAIL PROTECTED]>: > the default route is to if2. as you see, the point is > to symmetrically route inbound dns traffic via if1. > > but strage things happens: i see incoming packet on if1, > state creation, outgoing packet on if3, dns reply incoming > on if3, and... nothing else, no outgoing packet neither on > if1 nor if2. > > if i add some rule like > > pass in quick on $if3 route-to ($if1 $if1_gw) inet \ > from $int_net to any Comparing your ruleset with the one used here (providing not dns but http) i see only one difference (that normally shouldn't matter): I filter on the inbound interface as well and keep state, so i have in my ruleset the equivalent of pass out quick on $if3 inet proto udp from any to $int_dns port dns keep state Have you tried to log all blocked packets and dump what gets blocked? Maybe the reply gets blocked somewhere. Clemens
Re: RDR for internal machine
Zitiere Darley Ware <[EMAIL PROTECTED]>: > 1. I have webserver on the internal LAN which listens on port 8000. I can > view the webserver internally by IP and by name (using LMHOST records). I > have not however been able to access the internal webserver from the > outside. I saw a post the weekend about name based virtualhosting on web > servers. This does not seem to apply to me as I have the server setup to > respond to IP and have no virtualdomains configured. So I guess my question > is do I have my redirect setup correctly, and if so where lies the problem? No, you're blocking the redirected request. Redirection happens before the evaluation of pass/block rules. So > rdr on dc0 proto tcp from any to (dc0) port 8000 -> 192.168.XX.71 port 8000 redirects the request to 192.168.xx.71:8000 on dc0, and > block in log all > pass in quick on $if_ext proto tcp from any to $if_ext/24 port = 8000 does not let it pass, because the destination for the request is not $if_ext but 192.168.XX.71. So if you change it to > pass in quick on $if_ext proto tcp from any to 192.168.XX.71 port = 8000 > keep state it should work. > 2. (and this one really is not that important) I can not seem to get a > response to ICMP to outside addresses. I can ping both directions from the > firewall and I believe my pings are getting out, but the responses to not > return to the internal clients. If i understand you correctly, pinging works from the firewall in all directions (inwards and outwards), but not from internal clients to servers outside the firewall. Add > pass in on $if_int inet proto icmp all icmp-type 8 code 0 keep state to your rules for your internal interface, and all should be fine. You're blocking the pings on your internal interface, if i'm not mistaken. > Thanks, > > Darley Hope to have helped, Clemens
Question about altq implementation in pf
I just took a look at the altq implementation in pf in -current (actually i just looked at the man page of pf.conf, so if that is outdated, my question would possibly be as well), and have to say, i really like it. I started to think about how to implement altq into our next firewall and ran across a problem: Is it possible to use pfs altq implementation with stateful filtering-rules and asymetric interfaces (e.g. ADSL-style ones)? If i understand it correctly, it is not, because 1. I can only assign one queue (two considering lowdelay) to one filtering rule. 2. One queue has only one bandwidth. 3. One statefull rule would match packets in two directions with different bandwidths. So i see a few possible solutions to this: 1. Do not use stateful filtering at all. I really like statefull filtering and wouldn't like to give it up. 2. Do not use altq on OpenBSD. That really would be shame, now it's implemented into pf in such a nice way. 3. Allow a queue to have two bandwidths I don't know too much about altq, but i think that would be very hard to implement, if not outright impossible. 4. Allow at least up to 4 queues assigned to one rule That would allow 2 queues each for traffic flowing in the same and in the opposite direction of the state-creating packet. The last solution seems to me the most viable. One could define queues for incoming and outgoing traffic with different bandwidths and assign these to the stateful rules. Is this right? Or am i missing something? Would it be hard to implement? Thanks, Clemens
Re: Very Annoying problem... blocks everything...
[EMAIL PROTECTED] wrote: http://www.iodamedia.net/pf.conf Go grab it.. and tell me what I'm doing wrong! -Shawn Your ruleset is quite large to debug it just by looking at it. But one error quickly sprang to my eyes: You're blocking the loopback interface, which is certainly a bad idea. Clemens
Re: Is it possible to apply 'route-to' rules to redirected packets?
(I sent this mail already 2 weeks ago, but it looks as if it was lost in ADSL-Nirvana :) ) Zitiere Daniel Hartmeier <[EMAIL PROTECTED]>: > On Mon, Sep 02, 2002 at 04:10:45PM +0200, Clemens Dumat wrote: > > > Great :) And as i said, i'm willing to help (if i can be of any help), > > if route-reply-to is to be implemented. > > Well, you can help test it :) It took me some days to set up a current-system to apply the patches against, but now the system runs smoothly for some days (aktually weeks by now :) with two 'reply-to' rules for now (this will definitely grow :) ). Thanks a lot! I'm not into the normal development-cycle of openbsd, so my question may be stupid: will these patches make it into the normal cvs-tree, and if so, will they be in time for 3.2-stable? Clemens
Re: Is it possible to apply 'route-to' rules to redirected packets?
Zitiere Daniel Hartmeier <[EMAIL PROTECTED]>: > rdr applying to outgoing connections has some ugly implications, apart > from just adding more complexity and bloat. I'm not enough into the architecture of pf to do intelligent suggestions about what could/should be done to achive a certain goal. Only seeing the rules and not knowing anything about the internals of pf i just preferred my ways :) > I see what you mean, but I don't think this is worth it. The new rdr semantics, > I mean, not route-reply-to itself. Great :) And as i said, i'm willing to help (if i can be of any help), if route-reply-to is to be implemented. Clemens
Re: Is it possible to apply 'route-to' rules to redirected packets?
Zitiere Daniel Hartmeier <[EMAIL PROTECTED]>: > On Mon, Sep 02, 2002 at 01:58:14PM +0200, Clemens Dumat wrote: > > > This is your proposal. Maybe this is the only one that would be > > sensible to do, but nevertheless i though about different ways of doing > > it :) The one thing that i don't really like in this solution is that i > > would have to open a private IP on the outer interface for this to work. > > But that's what you're actually doing, even in your two other proposals: > expose a local machine to the internet. Yup. But the latter two version expose only the translated IP, whereas your version also exposes the private, real IP of the local machine. > Or did I miss something? How are the latter two versions more > restrictive, such that they block any packet that the first version > doesn't? The latter two versions allow only packets on de0 directed to 195.200.200.201:80 through the firewall, because the redirection is done on the inner interface. The private address 192.168.0.100 is blocked on the outside. Your version would also allow packets directed to 192.168.0.100:80 (which were NOT translated by the rdr-rule on de0) through the firewall. These packets shouldn't be allowed, IMHO. These packets shouldn't arrive there, for sure, but i think, it would be safer this way. For example, with a scanner directly attached to the outer interface de0 it would be possible to find out about private IPs used in the DMZ (and that should not be possible, IMHO). But maybe it's me who misses something. Clemens
Re: Is it possible to apply 'route-to' rules to redirected packets?
Hi Daniel, thanks for your replies. With my newly gained knowledge about pf i tried to find a workable solution for my problem using 3.1-stable but failed (i think it was to be expected :). So i thought about how it could be done expanding the current pf (as i understand pf right now) and came up with 3 ways: 1) rdr on de0 inet proto tcp from any to 195.200.200.201 port http \ -> 192.168.0.100 port http pass in quick on de0 route-replies-to de0 inet proto tcp \ from any to 192.168.0.100 port http This is your proposal. Maybe this is the only one that would be sensible to do, but nevertheless i though about different ways of doing it :) The one thing that i don't really like in this solution is that i would have to open a private IP on the outer interface for this to work. 2) pass in quick on de0 route-into de1 inet proto tcp \ from any to 195.200.200.201 port http keep state rdr on de1 inet proto tcp from any to 195.200.200.201 port http \ -> 192.168.0.100 port http In this example, there would be a route-into, which should pass the packet INTO and not OUT-OF de1, as a route-to would do, so the rdr rule would be evaluated. But i'm not sure what would happen with the packet after it went into de1. I guess it would be evaluated by the kernel and get routed again out of de1. 3) pass in quick on de0 route-to de1 inet proto tcp \ from any to 195.200.200.201 port http keep state rdr-out on de1 inet proto tcp from any to 195.200.200.201 port http \ -> 192.168.0.100 port http The problem here is that rdr only works on incoming connections, so rdr rules doesn't apply. If there would be a rdr-out for outgoing connections translating the destination it should work. I prefer the third possibility, but i don't know the pf source (had a quick glance, but that is not enough to understand it :). > I'm not sure this is a common enough case to warrant the extention, > but it kind of makes sense to me. Any opinions? :) Is this really such a rare case? It should happen nearly always when you have two external interfaces and provide services to the world, which are not on the router/fw. Or is this easier doable and i try to accomplish things the hard way? If so, could someone please point me in the right direction? So if there would be a voting (ok, this is not a democracy but one can vote nevertheless :), here is the first vote for an extension of pf into this direction (preferably using the third alternative, but that is just a matter of taste). And if this extension is really seriously taken into consideration, how can i help? Thanks, Clemens
Is it possible to apply 'route-to' rules to redirected packets?
Hi all,
i'm trying to apply route-to rules to packets that have a state (because they
were redirected or came in by a 'keep|modulate state'-rule), but to no avail.
I'm using 3.1-stable.
The situation is as follows: I have a router with 3 interfaces:
de0: external, static IP (e.g. 195.200.200.201)
de1: internal, 192.168.0.1
tun0 (via de2): external, ADSL, IP via DHCP
When tun0 is up (almost always) the default gateway is reachable via tun0, else
via de0.
I want to provide services (smtp, http, more in the future) on static IPs of de0
(the standard or preferably aliased ones).
If i try to do a rdr or a binat on de0 to some private machines, the translation
works correct, but the packets gets routed back to tun0!
Example (Connection attempt from 1.2.3.4:2003 to 195.200.200.201:80):
1) on de0: 1.2.3.4:2003-> 195.200.200.201:80
2) on de1: 1.2.3.4:2003-> 192.168.0.100:80
3) on de1: 192.168.0.100:80-> 1.2.3.4:2003
4) on tun0:195.200.200.201:80 -> 1.2.3.4:2003
As you can see, the problem lies in the 4th step: The packet gets routed to the
default interface and not the one stated in the route-to rule.
I tried to apply a route-to on tun0 to get this packet to de0, but i can't get
it to work. Are 'route-to' pf-rules really treated differently than 'normal'
rules (as show in http://mniam.net/pf/pf.png), or are they treated just like any
other filter-rule and skipped when a state is applicable?
The important rules are:
pass in quick on de0 inet proto tcp from any to any port { http }
pass out quick on tun0 route-to de0:$WLANGate inet proto tcp \
from any port { http } to any
rdr on de0 proto tcp from any to 195.200.200.201 port 80 \
-> 192.168.0.100 port 80
A point that could confirm, that packets are treated the same, whether or not
they have a routing section like 'route-to' in them, is that incoming
connections aimed for the router (e.g. ssh) work with these rules (that is, when
there is no state), but only as long as i don't keep state on these incoming
connections!
Thanks in advance,
Clemens
