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
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
