RDR/NAT/BINAT order again
I read some articles which mention about RDR/NAT/BINAT order . According to http://mniam.net/pf/pf.png , the order would be : incoming: RDR->BINAT outgoing: BINAT->NAT combination => RDR->BINAT->NAT for this order, if i have the following situation, then the new order RDR->NAT->BINAT will be better. Internet | v fxp0 (211.1.1.1, 211.1.1.2, 211.1.1.3 ) PF box fxp1 (192.168.1.254) | v LAN (server: 192.168.1.1 ) if i have the following requirement: 211.1.1.1 port 80 redirect to 192.168.1.1 : 80, 211.1.1.2 port 21 redirect to 192.168.1.1 : 21 192.168.1.1 outgoing traffic will be nated src to 211.1.1.2 211.1.1.3 mapping to 192.168.1.1 then , the pf nat rule will be the following: rdr on fxp0 inet proto tcp from any to 211.1.1.1 port 80 -> 192.168.1.1 port 80 rdr on fxp0 inet proto tcp from any to 211.1.1.1 port 21 -> 192.168.1.1 port 21 nat on fxp0 inet from 192.168.1.1 to any -> 211.1.1.2 binat on fxp0 inet from 192.168.1.1 to any -> 211.1.1.3 unfortunelly, the outgoing traffic is processed by BINAT->NAT , then the rule " nat on fxp0 inet from 192.168.1.1 to any -> 211.1.1.2 " will never be matched!! BUT if the outgoing traffic is processed by NAT->BINAT, then the NAT rule will be matched. Imaging that ftp client (active mode) connect to 211.1.1.2 port 21, but the data port is initialized from 211.1.1.3 port 20 because of binat rule, that will break the ftp data connection Do i make mistake? If you change the order to RDR->NAT->BINAT order, will this break other pf mechanism? Norton
Re: packet filtering
Hello Daniel, Here is my tcpdump of pflog0: Jul 31 01:23:48.272259 rule 1/0(match): block in on fxp0: 196.4.160.2.53 > 196.34.165.210.1588: S 1318784553:1318784553(0) ack 1889327994 win 65535 Jul 31 01:23:56.876904 rule 1/0(match): block in on fxp0: 196.4.160.2.53 > 196.34.165.210.1589: S 1764338029:1764338029(0) ack 4153205723 win 65535 (DF) that is what i am getting when i try and telnet to 196.4.160.2 53 from 196.34.165.210 Regards Mark These shoes look like Frankenstein's hand-me-downs. On Thu, 31 Jul 2003, Daniel Hartmeier wrote: >On Thu, Jul 31, 2003 at 12:40:53AM +0200, Mark Bojara wrote: > >> The packets get blocked after fxp0 and do not reach vlan1. Basically I >> want to do incoming filtering on one interface and outgoing filtering on >> another interface, reason being that i will eventually use it for queue's >> to shape incoming/outgoing on top of that. > >So try the suggested rule. It will tell you what packets get filtered on >which interfaces, then we know what rules you'll need to pass what you >want... > >BTW, packets can get sent to bpf for an interface even though pf is not >invoked to filter them there, at least theoretically. > >Daniel >
Re: packet filtering
On Thu, Jul 31, 2003 at 12:26:21AM +0200, Daniel Hartmeier wrote: > I'm not entirely sure, but the assumption that the same packet will be > filtered both on the real and the vlan interface (in both directions) > might just be wrong. My experience is that the packet will appear on one interface or the other, but not both. IE if it is tagged with a vlan id which is associated with a vlan interface, it will not appear on the physical interface. -Ryan
Re: packet filtering
On Thu, Jul 31, 2003 at 12:42:10AM +0200, Mark Bojara wrote: > fxp0 is the uplink interface and xl0 is the interface that the vlan is > connected too. If i tcpdump xl0 I can see traffic from all the vlan's on > it. pf and BPF aren't in the same place in packet flow. tcpdump gets packets much earlier on, and sees stuff that pf never gets, such as arp traffic, etc. This is why Daniel suggested testing with a 'pass log all' rule to see wheich interface pf was handling the traffic on, rather than looking with tcpdump. -Ryan
Re: packet filtering
On Thu, Jul 31, 2003 at 12:40:53AM +0200, Mark Bojara wrote: > The packets get blocked after fxp0 and do not reach vlan1. Basically I > want to do incoming filtering on one interface and outgoing filtering on > another interface, reason being that i will eventually use it for queue's > to shape incoming/outgoing on top of that. So try the suggested rule. It will tell you what packets get filtered on which interfaces, then we know what rules you'll need to pass what you want... BTW, packets can get sent to bpf for an interface even though pf is not invoked to filter them there, at least theoretically. Daniel
Re: packet filtering
Hello Ryan, fxp0 is the uplink interface and xl0 is the interface that the vlan is connected too. If i tcpdump xl0 I can see traffic from all the vlan's on it. Regards Mark Universe is a big place... perhaps the biggest On Wed, 30 Jul 2003, Ryan McBride wrote: >On Thu, Jul 31, 2003 at 12:26:21AM +0200, Daniel Hartmeier wrote: >> I'm not entirely sure, but the assumption that the same packet will be >> filtered both on the real and the vlan interface (in both directions) >> might just be wrong. > >My experience is that the packet will appear on one interface or the >other, but not both. IE if it is tagged with a vlan id which is >associated with a vlan interface, it will not appear on the physical >interface. > >-Ryan >
Re: packet filtering
Hello Daniel, The packets get blocked after fxp0 and do not reach vlan1. Basically I want to do incoming filtering on one interface and outgoing filtering on another interface, reason being that i will eventually use it for queue's to shape incoming/outgoing on top of that. Regards Mark Confucius say: Those who quote me are fools. On Thu, 31 Jul 2003, Daniel Hartmeier wrote: >On Wed, Jul 30, 2003 at 11:58:32PM +0200, Mark Bojara wrote: > >> block out on vlan1 from any to 196.34.165.210 >> pass out on vlan1 proto tcp from any to 196.34.165.210 port 22 >> pass out on fxp0 from 196.34.165.210 to any keep state > >I'm not entirely sure, but the assumption that the same packet will be >filtered both on the real and the vlan interface (in both directions) >might just be wrong. > >When you use just this ruleset > > pass log all > >and ping through the vlan interface, do you see the echo requests and >replies getting logged on both interfaces? > >Daniel >
Re: packet filtering
On Wed, Jul 30, 2003 at 11:58:32PM +0200, Mark Bojara wrote: > block out on vlan1 from any to 196.34.165.210 > pass out on vlan1 proto tcp from any to 196.34.165.210 port 22 > pass out on fxp0 from 196.34.165.210 to any keep state I'm not entirely sure, but the assumption that the same packet will be filtered both on the real and the vlan interface (in both directions) might just be wrong. When you use just this ruleset pass log all and ping through the vlan interface, do you see the echo requests and replies getting logged on both interfaces? Daniel
packet filtering
please ignore all previous thread.. let me write out a proper description of the problem.. Ive disabled all queue'ing this is only simple packet filtering.. rules: block out on vlan1 from any to 196.34.165.210 pass out on vlan1 proto tcp from any to 196.34.165.210 port 22 pass out on fxp0 from 196.34.165.210 to any keep state This basically blocks all incoming access besides ssh wich is what I want but then it should allow all outgoing access but it doesnt allow it. I then tried it the other way around: block in on fxp0 from any to 196.34.165.210 pass in on fxp0 proto tcp from any to 196.34.165.210 port 22 pass out on vlan1 from 196.34.165.210 to any results where the same as above.. Does anybody have any suggestions? Thanks Mark Don't ask me, I'm making this up as I go! On Wed, 30 Jul 2003, Mark Bojara wrote: >ive tried all possible combinations for > >pass in on vlan1 from to any keep state queue opium_d_l >but it does not work i think i will have to do something else.. any >idea's? however > >pass out on fxp0 from to any keep state queue opium_u_l >works fine but this is for outgoing traffic > >thanks > > >Guns don't kill people..., I KILL PEOPLE! > >On Wed, 30 Jul 2003, Mark Bojara wrote: > >>Hello Daniel, >> >>Sorry my mistake, The packets are being tagged. However I do not have any >>incoming or outgoing access. This is probably a error with my filters. Do >>you have any advice on what i could try? >> >>Thanks >>Mark >> >> >> >>(A)bort, (R)etry, (F)orget It! >> >>On Wed, 30 Jul 2003, Daniel Hartmeier wrote: >> >>>First, check whether your rules match: >>> >>> $ pfctl -vsr | grep -A 1 queue >>> >>>If they do, check whether tagged packets get queued: >>> >>> $ pfctl -vsq >>> >>>Daniel >>> >> >> > >
Re: altq with vlan
ive tried all possible combinations for pass in on vlan1 from to any keep state queue opium_d_l but it does not work i think i will have to do something else.. any idea's? however pass out on fxp0 from to any keep state queue opium_u_l works fine but this is for outgoing traffic thanks Guns don't kill people..., I KILL PEOPLE! On Wed, 30 Jul 2003, Mark Bojara wrote: >Hello Daniel, > >Sorry my mistake, The packets are being tagged. However I do not have any >incoming or outgoing access. This is probably a error with my filters. Do >you have any advice on what i could try? > >Thanks >Mark > > > >(A)bort, (R)etry, (F)orget It! > >On Wed, 30 Jul 2003, Daniel Hartmeier wrote: > >>First, check whether your rules match: >> >> $ pfctl -vsr | grep -A 1 queue >> >>If they do, check whether tagged packets get queued: >> >> $ pfctl -vsq >> >>Daniel >> > >
Re: Packets with bad opt dropped
Hello Julian, Wednesday, July 30, 2003, 3:04:38 PM, you wrote: Julian> I really need these packets to get through, is there any way of doing this? Julian> no I cannot modify the application (it's Chekpoint Secure Remote client). You could change it, thou ;-) Or use IPSec. -- Best regards, Alejandro Belluscio
Re: Packets with bad opt dropped
On Wed, Jul 30, 2003 at 03:04:38PM -0300, Julian Escaglia wrote: > I really need these packets to get through, is there any way of doing this? > no I cannot modify the application (it's Chekpoint Secure Remote client). Add 'allow-opts' at the end of both pass rules, see pf.conf(5) for details. Daniel
Packets with bad opt dropped
I'm having the following problem: I configured pf.conf with pass in all and pass out all. I start tcpdump on the internal and external nics to see whats going through both. In the internal interface I get packets with <[bad opt]> flags but they never appear at the external interface. If I stop pf with pfctl -d the packets start showing up. I really need these packets to get through, is there any way of doing this? no I cannot modify the application (it's Chekpoint Secure Remote client). Thanks _ Charla con tus amigos en línea mediante MSN Messenger: http://messenger.yupimsn.com/
Re: altq with vlan
Hello Daniel, Sorry my mistake, The packets are being tagged. However I do not have any incoming or outgoing access. This is probably a error with my filters. Do you have any advice on what i could try? Thanks Mark (A)bort, (R)etry, (F)orget It! On Wed, 30 Jul 2003, Daniel Hartmeier wrote: >First, check whether your rules match: > > $ pfctl -vsr | grep -A 1 queue > >If they do, check whether tagged packets get queued: > > $ pfctl -vsq > >Daniel >
Re: Fix pf(4) nat proxy port allocation for manually specified ranges... perhaps?
On Sun, Jul 27, 2003 at 01:48:13AM -0700, Trevor Talbot wrote: > Ah, turns out this is a different bug. It's been fixed in -current, > but hasn't reached -stable. Yet. Again. Does someone not like Ryan > McBride's patches? :) > > http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/ > parse.y.diff?r1=1.373&r2=1.374 Does Ryan submit his patches for -stable commit? :) This one is clearly non-controversial (bugfix, small, unlikely to break something), so I don't see how it could be refused. But it has to be submitted (repeatedly, if ignored, until it goes through), and that's primarily the burden of whoever commited it to -current. So, harrass Ryan until it's in ;) Daniel
Re: rdr to internal ftp
On Mon, Jul 28, 2003 at 03:11:28AM -0500, Scircuit wrote: > rdr on $ExtIF proto tcp from any to any port -> $FtpServer > > pass in on $ExtIF inet proto tcp from any to $ExtIF port $tcp_allow \ > flags S/SA modulate state Translation occurs before filtering. The incoming connection will first have its destination address replaced with $FtpServer by the redirection rule. Then the filter rules are evaluated. Since you specify 'to $ExtIF', the rule doesn't match (the destination address is no longer $ExtIF, but $FtpServer). > If I change the rule to not use variables, the rule is the following: > > pass in on $ExtIF inet proto tcp from any to any port 7778 flags S/SA modulate state Here, you don't restrict the destination address at all, hence the rule applies, and the control connection works. > Is there an error in the rules that prevent me from listing directories on the ftp > server? FTP is a tricky protocol, and you need to understand how it works to solve this. The FTP client opens the control connection to the FTP server (this is probably the only connection you were aware of before). Through this connection, the client sends commands (like LS /) and the server sends status messages. When you transfer a file or list a directory, that data is not sent over the control connection. Instead, a separate data connection is established between client and server, and the data is sent through that connection. The control connection remains open, so you can issue other commands, etc. There's two ways to open the data connections: a) passive mode: the server choses a port where it listens on, and the client connects to the server b) active mode: the client choses a port where it listens on, and the server connects back to the client In both cases, the port is usually chosen randomly, unless you configure specific ports. In your case, it should be obvious that passive mode will not work without further hassle. The client would connect to your external address, and that connection would never get forwarded to the server. Active mode, however, should work. Though if the client is behind its own NAT gateway, it can't do active mode, for the same reason (your connection back would not reach it). If you want to make passive mode work, you can a) Configure the FTP server to use a specific range of ports for the data connections, and forward those with an addition rdr. Since the server tells the client not just what port to connect to, but also what IP address, you'll also have to make sure the FTP server pretends to have the external address. Several FTP daemons have such options. b) Use a proxy on the gateway that intercepts the control connections, modifies the replies containing IP addresses and ports so that the client will connect to the proxy on the gateway, and then proxies those connections to the FTP server. ftp-proxy(8) with the 'reverse proxy patch' (search the mailing list archive) can do that. Daniel
Re: altq with vlan
First, check whether your rules match: $ pfctl -vsr | grep -A 1 queue If they do, check whether tagged packets get queued: $ pfctl -vsq Daniel
Re: Does pf become faster (states take less space) if INET6 support removed from kernel
On Wed, Jul 30, 2003 at 11:17:30PM +0800, Yusuf Goolamabbas wrote: > If I remove INET6 support from an OpenBSD 3.3-RELEASE kernel, would this > help pf become faster and states take lesser memory or do I have to > rebuild the world for this Neither will reduce the memory size of a state entry, which is defined large enough to hold either type of addresses, no matter whether support for INET6 is compiled in or not. This could be changed, of course, but would make the code more complex. In the best case, you could reduce the size of a state entry to 25%, and handle four times the number of states with the same amount of RAM. If you're operating exactly within that 100-400% range where it matters, adding RAM is the cheapest solution. > I am looking to do lots of DNS queries from a set of machines behind an > OpenBSD bridging firewall and was wondering whether using stateful rules > would cause a lot of memory pressure and if I could alleviate it by > removing INET6 support from the kernel If you end up with several hundred thousand concurrent state entries for DNS queries/replies, and run out of memory, you might want to consider passing UDP DNS traffic statelessly. If by 'lots' you mean merely a couple of thousand concurrent states at any time, that won't be a problem, anyway. Daniel
altq with vlan
Hello,
I have set up vlan's on my 3com switch with vlan devices on my openbsd
server to accomodate my altq properly. However I can not seem to tag any
packets on vlan1 or xl0 (parent interface). The prupose is to do both
incoming/outgoing queue's on normal interface's my setup works fine. How
can get around this for vlan setup?
I am running 3.3-current the latest cvsup version.
Thanks in advance
Mark
Beware of Geeks bearing gifs.
table { 196.34.165.210 }
set timeout { interval 30, frag 10 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set limit { states 100, frags 15 }
set loginterface none
set optimization normal
set block-policy drop
set require-order yes
scrub in on fxp0 all random-id no-df fragment reassemble
altq on fxp0 bandwidth 10Mb hfsc queue { std_u, local_u }
queue std_u bandwidth 32Kb hfsc(default upperlimit 768Kb) # change this
queue local_u bandwidth 768Kb hfsc(upperlimit 768Kb) { \
opium_u_l \
}
queue opium_u_l bandwidth 32Kb hfsc(upperlimit 32Kb)
altq on xl0 bandwidth 100Mb hfsc queue { mics, std_d, local_d }
queue std_d bandwidth 32Kb hfsc(default upperlimit 768Kb) # change this
queue mics bandwidth 2Mb
# Downstream - Local Bandwidth
queue local_d bandwidth 768Kb hfsc(upperlimit 768Kb) { \
opium_d_l \
}
queue opium_d_l bandwidth 32Kb hfsc(upperlimit 32Kb)
pass in on fxp0 from any to keep state queue opium_u_l
pass in on vlan1 from to any keep state queue opium_d_l
block in on fxp0 from any to
Does pf become faster (states take less space) if INET6 support removed from kernel
If I remove INET6 support from an OpenBSD 3.3-RELEASE kernel, would this help pf become faster and states take lesser memory or do I have to rebuild the world for this I am looking to do lots of DNS queries from a set of machines behind an OpenBSD bridging firewall and was wondering whether using stateful rules would cause a lot of memory pressure and if I could alleviate it by removing INET6 support from the kernel Thanks, Yusuf -- If you're not using Firebird, you're not surfing the web you're suffering it http://www.mozilla.org/products/firebird/why/
Re[2]: Download Bandwith Shaping :: Idea
Tuesday, July 29, 2003, 11:42:31 PM, Ed White wrote: > On Tuesday 29 July 2003 17:22, Alexey E. Suslikov wrote: >> >slowing down the outgoing tcp acks etc slows down usual downloads tho. > Exact. > The trick explained works perfectly and does exactly what is described to do. > The target was to shape _download_bandwidth_ and it can be done pretty well > working on upload filtering rules . >> :) of course not. the goal of my example is to show, "how >> priorizing of incoming traffic not work" :) > Wrong. > I suggested to work on _upload_ queque for each box. > [download queque] internet ---> box > [upload queque] internet <--- box i have got your example, but you don't want to get my :) ok, you have outbound mapped to appropriate queues accordingly to host based model. and yes, your shaper will work. but such incoming traffic was initiated by outbound from your side, so your box know how to shape. my example shows different case: we also have incoming, but initiated from outside of your box. how to shape in this case? and it is not about normal tcp connection, which can be slowed down by delaying ACKs or by ECN. this is about flooding, for example, by SYN-flood coming to you on the full width of your pipe. your pf is safe, thanks to state limit or adaptive timeouts. but your box is still have this junk on physical interface. all what i want to know "how to shape this"... so, Ed, there is no doubt about your trick: it is correct. i just want to show what "not any incoming traffic can be shaped" due protocol implementation limits, because we don't have ability to tell uplink's hardware or software "xxx.xxx.xxx.xxx/x are DDoSing me! so block them out!" :)
