Re: RDR problem
On 2010-06-17, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi stuart. Thanks for the reply. Can you give me a valid example to understand this directive? Reading man pages and on the web I understand that with match directive, the quick keyword has no durable effect, and the match directive set on the fly the values e not after last rule match such as pass. True? It is a valid ruleset? match on $ext proto tcp from any to any port 80 rdr-to $dmz-host port 80 ... ... pass on $ext proto tcp from any to $hostweb port 80 synproxy state not valid, rdr-to needs a direction (in/out). also see this: Translation [...] Subsequent rules will see packets as they look after any addresses and ports have been translated. These rules will therefore have to filter based on the translated address and port number. so for the pass rule you probably want $dmz-host not $hostweb. pass on $ext proto tcp from any to any port 80 rdr-to $dmz-host port 80 I must not to put another filter rule for pass this service such as pf of openbsd4.5? you don't need a separate rule. you can either do it this way, with 'rdr-to' directly on the pass rule, or you can use separate match and pass rules, depending on what works best for you and your ruleset. Another question, in my example I want that my internal request for my internal site in dmz, are redirected versus dmz directly. Staying at my understandig, the ruleset must be: #redirect packet for http versus squid match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 # redirect packet for mydomain.ath.cd to dmz-host match in on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $dmz-host port 80 # pass all traffic for int network pass in on $int from $int:network to any than, if the $int network client sends a request for mydomain.ath.cx the first rule match, the second match and when the pass rule will be processed, settings take place and then redirected? from a quick read, i think so, but you can test this yourself much more easily than i can. thanks in advance Stuart Henderson wrote: match is a modifier. the settings are remembered and applied to the pass rule lower in the ruleset which permits the traffic to go through. On 2010-06-17, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi misc. I've a openbsd 4.7 firewall with 3 nic, one for lan, one for wan and one for dmz. On the same machine I've a squid proxy, and in dmz i've a web server. My problem is when I get a request for the web server on dmz by a lan client. In my ruleset I've this rdr rules for http request: match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 and it works fine for all requests. When I make from a $int:network client an http request like http://mydomain.ath.cx;, the proxy (working with rdr rule or browser config) give me the web managment of my router. Then I've tried a first set: match in quick on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $apache port 80 match in quick on $int proto tcp from $int:network to $int:0 port 3128 rdr-to $apache port 80 match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 but the behaviour is the same. I've tried to modify my rdr rules into (second set): pass in quick on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $apache port 80 pass in quick on $int proto tcp from $int:network to $int:0 port 3128 rdr-to $apache port 80 match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 and it works fine. I've tried third ruleset: match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 match in on $int proto tcp from any to mydomain.ath.cx port 80 rdr-to $apache port 80 but doesn't work. My question is about these three ruleset. Why in the first ruleset match in quick rules, the key quick does not affect the third rule of squid redirection? Why the pass rules works instead the match rules? Why in the third ruleset match in on $int...doesn't work? The rules parsing is the last match rule? thanks in advance
Re: RDR problem
Hi there. There were different errors on the last email. For the first rdr-to I have lost the direction, and for the second rule host specification, the same with different host. But today, reading these mail, I've another question: the rdr-to rules does not accept only inbound packet? thanks in advance Stuart Henderson wrote: On 2010-06-17, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi stuart. Thanks for the reply. Can you give me a valid example to understand this directive? Reading man pages and on the web I understand that with match directive, the quick keyword has no durable effect, and the match directive set on the fly the values e not after last rule match such as pass. True? It is a valid ruleset? match on $ext proto tcp from any to any port 80 rdr-to $dmz-host port 80 ... ... pass on $ext proto tcp from any to $hostweb port 80 synproxy state not valid, rdr-to needs a direction (in/out). also see this: Translation [...] Subsequent rules will see packets as they look after any addresses and ports have been translated. These rules will therefore have to filter based on the translated address and port number. so for the pass rule you probably want $dmz-host not $hostweb. pass on $ext proto tcp from any to any port 80 rdr-to $dmz-host port 80 I must not to put another filter rule for pass this service such as pf of openbsd4.5? you don't need a separate rule. you can either do it this way, with 'rdr-to' directly on the pass rule, or you can use separate match and pass rules, depending on what works best for you and your ruleset. Another question, in my example I want that my internal request for my internal site in dmz, are redirected versus dmz directly. Staying at my understandig, the ruleset must be: #redirect packet for http versus squid match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 # redirect packet for mydomain.ath.cd to dmz-host match in on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $dmz-host port 80 # pass all traffic for int network pass in on $int from $int:network to any than, if the $int network client sends a request for mydomain.ath.cx the first rule match, the second match and when the pass rule will be processed, settings take place and then redirected? from a quick read, i think so, but you can test this yourself much more easily than i can. thanks in advance Stuart Henderson wrote: match is a modifier. the settings are remembered and applied to the pass rule lower in the ruleset which permits the traffic to go through. On 2010-06-17, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi misc. I've a openbsd 4.7 firewall with 3 nic, one for lan, one for wan and one for dmz. On the same machine I've a squid proxy, and in dmz i've a web server. My problem is when I get a request for the web server on dmz by a lan client. In my ruleset I've this rdr rules for http request: match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 and it works fine for all requests. When I make from a $int:network client an http request like http://mydomain.ath.cx;, the proxy (working with rdr rule or browser config) give me the web managment of my router. Then I've tried a first set: match in quick on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $apache port 80 match in quick on $int proto tcp from $int:network to $int:0 port 3128 rdr-to $apache port 80 match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 but the behaviour is the same. I've tried to modify my rdr rules into (second set): pass in quick on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $apache port 80 pass in quick on $int proto tcp from $int:network to $int:0 port 3128 rdr-to $apache port 80 match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 and it works fine. I've tried third ruleset: match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 match in on $int proto tcp from any to mydomain.ath.cx port 80 rdr-to $apache port 80 but doesn't work. My question is about these three ruleset. Why in the first ruleset match in quick rules, the key quick does not affect the third rule of squid redirection? Why the pass rules works instead the match rules? Why in the third ruleset match in on $int...doesn't work? The rules parsing is the last match rule? thanks in advance
Re: RDR problem
match is a modifier. the settings are remembered and applied to the pass rule lower in the ruleset which permits the traffic to go through. On 2010-06-17, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi misc. I've a openbsd 4.7 firewall with 3 nic, one for lan, one for wan and one for dmz. On the same machine I've a squid proxy, and in dmz i've a web server. My problem is when I get a request for the web server on dmz by a lan client. In my ruleset I've this rdr rules for http request: match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 and it works fine for all requests. When I make from a $int:network client an http request like http://mydomain.ath.cx;, the proxy (working with rdr rule or browser config) give me the web managment of my router. Then I've tried a first set: match in quick on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $apache port 80 match in quick on $int proto tcp from $int:network to $int:0 port 3128 rdr-to $apache port 80 match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 but the behaviour is the same. I've tried to modify my rdr rules into (second set): pass in quick on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $apache port 80 pass in quick on $int proto tcp from $int:network to $int:0 port 3128 rdr-to $apache port 80 match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 and it works fine. I've tried third ruleset: match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 match in on $int proto tcp from any to mydomain.ath.cx port 80 rdr-to $apache port 80 but doesn't work. My question is about these three ruleset. Why in the first ruleset match in quick rules, the key quick does not affect the third rule of squid redirection? Why the pass rules works instead the match rules? Why in the third ruleset match in on $int...doesn't work? The rules parsing is the last match rule? thanks in advance
Re: RDR problem
Hi stuart. Thanks for the reply. Can you give me a valid example to understand this directive? Reading man pages and on the web I understand that with match directive, the quick keyword has no durable effect, and the match directive set on the fly the values e not after last rule match such as pass. True? It is a valid ruleset? match on $ext proto tcp from any to any port 80 rdr-to $dmz-host port 80 ... ... pass on $ext proto tcp from any to $hostweb port 80 synproxy state in this example when the pass rule will be matched from a packet, the settings of match rule will be applied, and then change the packet addr to $dmz-host? and if there is: pass on $ext proto tcp from any to any port 80 rdr-to $dmz-host port 80 I must not to put another filter rule for pass this service such as pf of openbsd4.5? Another question, in my example I want that my internal request for my internal site in dmz, are redirected versus dmz directly. Staying at my understandig, the ruleset must be: #redirect packet for http versus squid match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 # redirect packet for mydomain.ath.cd to dmz-host match in on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $dmz-host port 80 # pass all traffic for int network pass in on $int from $int:network to any than, if the $int network client sends a request for mydomain.ath.cx the first rule match, the second match and when the pass rule will be processed, settings take place and then redirected? thanks in advance Stuart Henderson wrote: match is a modifier. the settings are remembered and applied to the pass rule lower in the ruleset which permits the traffic to go through. On 2010-06-17, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi misc. I've a openbsd 4.7 firewall with 3 nic, one for lan, one for wan and one for dmz. On the same machine I've a squid proxy, and in dmz i've a web server. My problem is when I get a request for the web server on dmz by a lan client. In my ruleset I've this rdr rules for http request: match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 and it works fine for all requests. When I make from a $int:network client an http request like http://mydomain.ath.cx;, the proxy (working with rdr rule or browser config) give me the web managment of my router. Then I've tried a first set: match in quick on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $apache port 80 match in quick on $int proto tcp from $int:network to $int:0 port 3128 rdr-to $apache port 80 match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 but the behaviour is the same. I've tried to modify my rdr rules into (second set): pass in quick on $int proto tcp from $int:network to mydomain.ath.cx port 80 rdr-to $apache port 80 pass in quick on $int proto tcp from $int:network to $int:0 port 3128 rdr-to $apache port 80 match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 and it works fine. I've tried third ruleset: match in on $int proto tcp from $int:network to any port 80 rdr-to $int:0 port 3128 match in on $int proto tcp from any to mydomain.ath.cx port 80 rdr-to $apache port 80 but doesn't work. My question is about these three ruleset. Why in the first ruleset match in quick rules, the key quick does not affect the third rule of squid redirection? Why the pass rules works instead the match rules? Why in the third ruleset match in on $int...doesn't work? The rules parsing is the last match rule? thanks in advance
