Re: binat question
On May 12, 2008, at 2:32 PM, Christer Solskogen wrote:
If I do not use the binat-rule, connecting to games (in CoH) will
not work. But CoH also seems to be the only game with that kind of
problem.
IF the ports are right shouldn't this be enough?
CoH_ports = { 6112 , 9100 , 30260 }
rdr pass log on $ext_if proto { tcp, udp } from any to $ext_if port
$CoH_ports - $funshine
pass out all
You might also need to use the static-port option for udp nat rules:
nat pass log on $ext_if proto udp from $funshine port $COH_ports to
any - 85.200.10.151 static-port
An Xbox360 requires this to get full OPEN status, for instance. It's
related to the techniques they use to work through NAT when possible
(pf is too strict for them).
Re: Need stateless NAT
On Apr 8, 2008, at 11:59 PM, Adam Richards wrote: You're looking at creating 1:1 mappings from internal IPs to 150-500k public IPs. No. Sorry, I should've been clearer: 1:1 mappings between, say, a / 18 worth of public IP space to something like a /13 worth of possible private IP space. Okay. It's not 1:1 over the entire mathematical set, obviously, but rather 1:1 between (public, private) IP pairs for an arbitrarily defined duration. Maybe a requirement is that I'll never have more concurrent connections than I have public IPs? Yes. Given a /18 as your smallest address pool, you can have a max of ~~16k 1:1 mappings. Maybe this will change in the future to where I may need 1:n mapping? Note that 1:N requires flow tracking, even if it's only as granular as remote:internal/remote:external address pairs. However it is clear that in stateful NATing with your typical non- TE'd network, return traffic will always come back through the same NAT device irrespective of the internal server's network locality to the Internet. That is, the internal server (or VIP) may live closer, topologically, to Internet Feed B, whereas the NAT device may live closer to Internet Feed A. Thus depending on where internal services live, standard stateful NATing may inhibit return traffic from egressing the *nearest* exit. This is the opposite of what I want! But it's a requirement inherent in NAT itself; the traffic must go through the same mapping in both directions. It's not a matter of stateful vs stateless, it's a matter of where you do NAT. (I think we're on the same page but differing in use of state, see below.) * You want to distribute NAT by implementing it on or near each border. In order for anything bidirectional to function, the mappings must be consistent Yup. so that implies synchronizing state between them. Well, it depends on what we mean by synchronizing state. I'm using state in a general sense here, not in pf-specific terms. Static NAT is the kind of thing you'd set up on a simple rule-based engine, like a couple binat lines to map one block to another of the same size. I'd call this stateless. Dynamic NAT is what you get when you've got more addresses on one side than the other, and need to apply policy decisions to allocate and remove mappings. Since you have to keep track of the NAT mappings in use, I consider this stateful. Besides internal-external address mappings, pf's state engine also tracks remote address, protocol, TCP/UDP port numbers, and TCP connection state and sequence numbers. The TCP connection state and sequence checks are firewall operations, but the rest apply to NAT. This is just a matter of how much state is tracked, and determines how large N can be for 1:N scenarios. I want to have the same mapping information-base exist everywhere, but NAT state (ie, flow state matching) is NOT required nor needed. Just a simple unidirectional L3 translation and then move on our merry way. I say unidirectional to mean that the NAT device doesn't drop a packet if it results in a flow-matching miss. This is just the old style dumb nating from yesteryear... as a matter of fact, the same NAT which used to exist on the linux side of the house (and incidentally is being re-introduced; again, another part of the thread mentioned above http://kerneltrap.org/mailarchive/linux-netdev/2007/9/27/323772 ) As Ryan mentioned, pf isn't equipped for this. pf is designed as a firewall first, and happens to have NAT abilities as an easy bonus. As such, the rule-driven part of it expects to have a relatively small ruleset compared to the number of states to be tracked. The ruleset requires a linear scan and simply won't scale to very large numbers of rules, but does support partial matching, while the state engine is built to handle large numbers of exact matches. (That tends to be true of a lot of systems, including the iptables engine, hence the patch above to use a completely different method of specifying mappings. iptables can do it, it just can't scale.) In order to get pf doing what you want, you'll essentially have to cripple the state engine to first remove the firewalling logic, then scale back the amount of state tracked until it's as dumb as you want. Then add an interface to add entries to the state table itself, instead of using the ruleset. Or build your own engine based off of pf's state organization. Honestly, if that netfilter patch does what you want, I'd seriously consider using it. It'd be far easier than ripping apart pf. (It won't do 1:N, but I suspect you'll need a different approach for that anyway.) I would like preface my inline replies with stating what my original goal was, and still is, in starting this thread: I want to pursuade the pf community that stateless NAT is a desired feature and should be part of the core
Re: Need stateless NAT
Adam Richards wrote: I need to be able to create *stateless* nat rules for at least 150,000 entries, potentially to grow to 1/2million entries. The reason has to do with being able to work in an asymetric routing environment -- stateless nat must be used because traffic might not egress at the same location it ingressed. In other words I want to do a unidirectional translation and then fahgettaboutit. [...] there are some unique requirements this network brings which make public IP consumption unworkable. [...] table-management operations -- perhaps 10's of operations per second on a table of 500,000 entries/mappings. (operations, like inserts or deletes) Maybe for resilliency, or for ISP cost reasons, you want to take advantage of asymetric routing, or nearest-exit routing, in a unified multi-site network? That is, routing where no Traffic Engineering priciples are used. Clearly stateful tracking inhibits nearest-exit routing by nature. (Side note: to ensure TCP connections are maintained in a stateless enviornment you'd obviously need to enforce 1:1 binat mappings). I'm seeing mixed messages from the above quotes. It's your project, but consider this a friendly thought-check :) You're looking at creating 1:1 mappings from internal IPs to 150-500k public IPs. You talk about a high rate of mapping changes, so clearly you're managing entries dynamically, which is just another way of keeping state. You mention NAT being an impediment to asymmetric routing, but NAT is unrelated to routing, so I can infer some possibilities here: * You want to distribute NAT by implementing it on or near each border. In order for anything bidirectional to function, the mappings must be consistent, so that implies synchronizing state between them. You consider pf's stateful behavior to be ill-suited to this use case, so you're investigating stateless options. * You are implementing routing on the same device that runs pf, and you believe pf's state-keeping will prevent asymmetric routing from taking place. Are either of these correct? If you are trying to do distributed NAT, I would ask if that is actually a design requirement. It may be easier to place NAT near the internal devices instead. In a dynamic environment, it may reduce complexity and failure modes simply by avoiding the synchronization needed for distributed mappings.
Re: Network performance tool with little sized packets
On Dec 19, 2007, at 4:58 AM, Jordi Espasa Clofent wrote: I'm testing my FW with OpenBSD 4.2+pf in bridging mode. At present moment I've done test with iperf and netperf tools, using a 32/64/128K packets. *blinks* Is this ethernet? On non-jumbo-frames gear, the max ethernet frame size is 1518 bytes, which gives an IP MTU of 1500 bytes. Gig-e jumbo frames only go up to 9K or so. If you're just generating large IP payloads, you're not testing much network-wise, since it's just getting transformed into IP fragments before it goes out. But a simple sniffer in my production networks shows me that the packet size is very little: less or equal to 64 bytes (around 35% of total), between 64 and 128 bytes (around 35%) and between 1024 and 1518 bytes (the rest). For ethernet, the minimum frame size is 64 bytes, putting minimum payload at 46 bytes. Smaller payloads usually get padded by the NIC before it goes on the wire. So, I need a tool as iperf/netperf sytle, but capable to produce/manage a little packets. Iperf is certainly capable of generating small packets, but I think we need more information about what exactly you're testing and using as a sniffer before any answer will help.
Re: Network performance tool with little sized packets
On Dec 19, 2007, at 7:11 AM, Jordi Espasa Clofent wrote: The idea is put the FW, obviously, between the Cta6 wire and the main gigabit switch. because of that I buildup de FW as a bridge. Okay. So, I need to benchmark the FW with little size packets. The question is ¿Is there any tool which generates small packets traffic to benchmark the network performance as iperf or netperf does? Iperf can, it just won't automatically tune itself. It's been a while since I ran tests with it, but based on memory and the current docs for it... What you want to do is test using UDP packets (--udp), setting --length as appropriate (see below) and running tests with --bandwidth set to different levels. During each test run, pay attention to the loss reports. Under normal conditions there should be no loss at all; you'll start seeing minor loss as you approach the limits of what your equipment can handle, and then massive loss when you go past the limit. The report from the highest --bandwidth setting you can use with no loss is your benchmark. With these kinds of tests, the more interesting result tends to be packets per second rather than transferred data bandwidth. Because a lot of gear has trouble with high rates of small packets, even when they can handle massive amounts of bandwidth, you may need to get at least 2 machines on each side of the firewall running these tests at the same time. Otherwise you could end up benchmarking the test machines instead of the firewall :) Test without the firewall first to find their limits. For setting the UDP payload sizes, you need to know: Ethernet header: 18 bytes IP header: 20 bytes UDP header: 8 bytes Maximum ethernet frame size is 1518 bytes, so the highest --length to give iperf is 1472. For the minimum ethernet frame of 64, use --length 18. If I remember correctly, iperf has some lower limit on --length that won't let you use 18, so you may need to go a bit higher. As I said it's been a while though, so I don't remember what that limit is. I believe netperf has similar abilities, but I've never used it. Hope this helps.
Re: Borrow isn't borrowing much
On Monday, May 29, 2006, at 10:48 US/Pacific, Karl O. Pinc wrote: On 05/29/2006 07:02:40 AM, Steven Surdock wrote: I found that cbq didn't borrow as aggressively as I expected. Switching to the hfsc scheduler approached closer to what I wanted. That does seem to be better, but I clearly am not getting how hfsc uses the 'bandwidth' parameter as it seems to be using more bandwidth for a sub-queue than 'bandwidth' would allow. Perhaps I should be setting upperlimit as well HFSC is different enough that the bandwidth setting alone often doesn't make much sense. CBQ works in terms of bandwidth limits; HFSC works with bandwidth guarantees. You've got 3 options to play with: hfsc(realtime) is the minimum bandwidth for this queue. No matter what traffic comes along, a queue is guaranteed to get at least this much bandwidth. hfsc(upperlimit) is the maximum bandwidth for this queue. It will never get more than this. hfsc(linkshare) is what the bandwidth setting controls. It sets the weight of this queue (in relation to the others) for excess bandwidth on the interface, which is what is left over after the realtime guarantees have been satisfied for all queues. If you had 2 queues, each with a linkshare of 50% (or the equivalent bandwidth setting), and both queues were equally contending for the same bandwidth, they would each get 50% of the excess. If one queue wasn't in use at all, the other would get 100%. For a given queue, available bandwidth under HFSC is: realtime = (excess weighted by linkshare) = upperlimit
Re: Borrow isn't borrowing much
On Tuesday, May 30, 2006, at 08:22 US/Pacific, Karl O. Pinc wrote: On 05/29/2006 10:06:32 PM, Trevor Talbot wrote: hfsc(linkshare) is what the bandwidth setting controls. If hfc(linkshare) and bandwidth are the same thing, then what happens if you specify both? The hfsc(linkshare) value is used. Unless it's 0, in which case bandwidth is used.
Re: PF inadequacy: queue download
On Tuesday, May 2, 2006, at 19:52 US/Pacific, Lars Hansson wrote: On Wednesday 03 May 2006 00:15, Karl O. Pinc wrote: On 05/02/2006 02:22:33 AM, Lars Hansson wrote: The majority of users/developers has a separate firewall and then download queing is just a matter of doing it on the inside interface. To be fair, this only works if you've a single inside interface. No, it works with multiple. He means when you need a single limit shared among multiple internal clients -- and they're on different interfaces. Search the list archives for details on his network; he's posted about it before.
Re: PF inadequacy: queue download
On Saturday, Apr 29, 2006, at 08:58 US/Pacific, Daniel Hartmeier wrote: On Sat, Apr 29, 2006 at 05:10:40PM +0200, Stanislaw Halik wrote: I can speak for myself - I can't afford both the hardware and the electricity bill for a separate machine. Maybe downstream limiting isn't very robust, but IMO is the biggest thing pf/altq lacks. What I tried to express in the last paragraph of the referenced mail was that it's not pf that's lacking anything, but altq. There simply are no input queues with altq. If you added those queues to altq, you might not even have to change a single line in pf to get them used. Stock altq could put token buckets on input interfaces for rate limiting purposes, referred to as the traffic conditioner (CDNR). That capability was removed when the classifier was merged with pf. Old messages that might be relevant: http://www.benzedrine.cx/pf/msg02871.html http://www.benzedrine.cx/pf/msg07159.html (bottom)
Re: ALTQ, Dummynet, Dynamic Rules
On Friday, Mar 24, 2006, at 05:27 US/Pacific, Daniel Dias Gonçalves wrote: I use the following rules in the IPFW: $fwcmd add 100 pipe 13 ip from 192.168.0.0/24 to any in $fwcmd add 101 pipe 14 ip from any to 192.168.0.0/24 out $fwcmd pipe 13 config mask src-ip 0x00ff bw 150Kbit/s queue 12KBytes $fwcmd pipe 14 config mask dst-ip 0x00ff bw 150Kbit/s queue 12KBytes My question, it is possible to make the same with the PF+ALTQ? Sorry, not possible. For others: that creates a limiting queue for each IP (in 192.168.0.0/24, 256 total) in each direction (150kbit/s in, 150kbit/s out).
Re: Migration document for people coming from IPFilter?
On Sunday, Apr 2, 2006, at 00:26 US/Pacific, [EMAIL PROTECTED] wrote: Is there a document that describes how to translate common IPFilter constructs to pf? This would be helpful for people migrating (like me). Specifically, I'm looking for the pf equivalent of IPFilter's map $ext_if 192.168.10.0/24 - 1.2.3.4/32 proxy port 500 ipsec/udp map $ext_if 192.168.10.0/24 - 1.2.3.4/32 proxy port 1 ipsec/tcp map $ext_if 192.168.10.0/24 - 1.2.3.4/32 portmap tcp/udp 1025:65000 map $ext_if 192.168.10.0/24 - 1.2.3.4/32 The last two rules translate to: nat on $ext_if from 192.168.10.0/24 to any - 1.2.3.4 pf performs the equivalent of ipf's portmap for tcp and udp by default. You probably also want something like this in the filter rules: pass out on $ext_if from 1.2.3.4 to any keep state I'm not that familiar with ipsec, so someone else will have to respond to the first two rules. To help them: ipf contains things like ftp-proxy in kernel, and uses the proxy keyword in map rules to activate them. The goal is allowing multiple client machines to work with remote ipsec endpoints through outbound NAT. Jos, if you can explain the high level requirements here (do the client machines all need to talk to the _same_ remote endpoint?), it would help others answer.
Re: ACK priority and TCP flags
On Sunday, Feb 5, 2006, at 11:37 US/Pacific, Brad Waite wrote: pass out on $ext_if proto tcp from $ext_if to any flags S/SA \ keep state queue (q_def, q_pri) Both this page and the FAQ examples indicate that the above rule will assign ACKs to the higher priority queue, but I can't see how. The rule is only matched once, and then a state entry is created (due to keep state). That state entry is responsible for all future packets (regardless of TCP flags) that belong to the same connection, including ACKs. It also remembers the queue assignments and uses them appropriately. The TCP flags are chosen so that state is created only for a connection request, instead of having the rule match arbitrary packets that may or may not be part of a legitimate connection.
Re: Using state and routing inbound traffic
On Friday, Aug 5, 2005, at 15:18 US/Pacific, Karl O. Pinc wrote:
I was also hoping to get some comment from somebody who'd tried
queueing inbound traffic from a WAN link using a 2 port box to see how
successful they were in improving perceived bandwidth.
I have. It was a couple years ago and that configuration is no longer
in use, so most of this is from memory...
The goal was to make Quake 3 playable in the face of web and P2P
traffic. Quake 3 is an online First-Person Shooter game that uses UDP
as a transport, and is sensitive to both latency and dropped packets.
It includes a small onscreen network graph that reflects latency,
jitter, lost packets, and the status of the client side game prediction
engine in an easy-to-read format. It makes a decent network diagnostic
tool, actually...
The servers I played on had code to compensate for latency, so the most
important thing for my setup was getting _consistent_ latency. Lower
latency was preferable but not required. On an otherwise unused 320k
SDSL, latency was around 90ms.
-
altq on $int_if priq bandwidth 200Kb queue { q3_def, q3_pri }
queue q3_def priority 0 qlimit 1 priq(default)
queue q3_pri priority 7 qlimit 5
pass out on $int_if inet proto udp from any port 27959 27964 to
192.168.0.251 keep state queue q3_pri
pass in on $int_if inet proto udp from 192.168.0.251 to any port 27959
27964 keep state queue q3_pri
-
IIRC under full load the latency with this configuration was fairly
steady around 200ms, and I could play decent games.
Note that the bandwidth limit is 2/3 line capacity. I always disabled
this queue setup when I was done with the game, as keeping it active
was counterproductive. I didn't spend much time tuning this limit
though, so I don't know how much higher it could have gone and remained
acceptable.
The low queue limits are important. For Quake 3, dropped packets are
preferable to delayed ones; game engine interpolation can recover
drops, but inconsistent latency throws everything off. The limit of 5
is just to keep something in the queue for the priority engine to use.
For the other streams, I wanted them to drop quickly to more closely
reflect a bandwidth limit. Delaying them would give TCP the impression
that the link was simply high-latency, and the result would be bursty
traffic that leads to inconsistent latency for every other stream on
the pipe.
The problem with queue-based prioritization is that in order to have a
choice of things to prioritize, everything must be queued. The mere
act of queueing introduces latency, and for things like TCP, latency
decouples simulated bandwidth from real line capacity.
Stock altq (before the pf merge) contained a simple token bucket
rate-limiter for inbound flows. Were code written to combine it with
pf's state logic, it could be used to force bandwidth of other streams
below a certain limit only when states needing reserve bandwidth were
active. That assumes fixed reserve sizes though. A bonus would be
using smoothed historical flow statistics to predictively limit
bandwidth of all flows dynamically. This would avoid the latency
problem inherent in priority queueing. Implementing such a thing
efficiently would be an interesting project.
I threatened to do some work on the token bucket once, but ran out of
time to work on such a project. Sorry :(
Re: PF, Bridge, and IP on bridged interface [more]
On Friday, Feb 18, 2005, at 07:07 US/Pacific, Jim Fron wrote: As I mentioned before, using tcpdump on le0 and le2 shows traffic arriving and departing on the correct interfaces all of the time, regardless of bridge state. However, traffic appearing in pflog as matching rules from the wrong interface is due to the bridge: $ sudo brconfig bridge0 down $ sudo tcpdump -netttvvv -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0 Feb 18 09:51:51.949840 rule 2/0(match): pass in on le0: 192.168.1.9 192.168.1.1: icmp: echo request (id:19bc seq:0) (ttl 64, id 30421) Feb 18 09:51:51.950030 rule 4/0(match): pass out on le0: 192.168.1.1 192.168.1.9: icmp: echo reply (id:19bc seq:0) (ttl 255, id 25154) $ sudo brconfig bridge0 up $ sudo tcpdump -netttvvv -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0 Feb 18 09:52:29.459668 rule 3/0(match): pass in on le2: 192.168.1.9 192.168.1.1: icmp: echo request (id:19bd seq:0) (ttl 64, id 30487) Feb 18 09:52:29.459838 rule 4/0(match): pass out on le0: 192.168.1.1 192.168.1.9: icmp: echo reply (id:19bd seq:0) (ttl 255, id 21188) Apologies for not reading everything you've posted, but this thread may provide the clue you're looking for: http://www.benzedrine.cx/pf/msg03238.html Assuming I understand everything correctly, you won't have this problem in a pure bridging scenario -- where the IP destination or gateway is not this machine.
Re: Strange ? keep state behaviour
On Thursday, Jan 6, 2005, at 16:21 US/Pacific, Jason Murray wrote: If I understand things properly when the packet comes in on $ext_if it creates the state. Because the state is floating it should be picked up when the packet tries to go out on $uat_if. Since it is in the state table it should pass no problem. Though the state is floating with respect to interfaces, the _direction_ is still locked. It sees that out.side.add.ress sent a packet IN to in.side.web.server, and so will only match future packets with that address pair if they are also coming IN. (And packets OUT for the reverse address pair, of course.) The floating part just means it doesn't care what interface that happens on. This particular point seems to have gotten lost in the documentation since the if- and group-bound options were introduced.
Re: Keep State
On Sunday, Oct 17, 2004, at 14:15 US/Pacific, [EMAIL PROTECTED] wrote: On So, 17 Okt 2004, Oliver Humpage wrote: State only works on the interface on which it was created. You will need another keep state rule on the external interface allowing packets out. pf.conf(5) says that state is floating by default. So in my opinion it should not be necessary to add an additional pass out rule. States always match address pairs directionally. Even though floating is not physically tied to an interface, the packets on the external interface will be going the wrong way with respect to their addresses, and won't match state. This makes floating behave as if it were bound to an interface in most cases. The situations where floating vs if-bound matter tend to be subtle. While Oliver's statement may not be technically accurate, it's close enough for this scenario.
Re: Keep State
On Monday, Oct 18, 2004, at 02:38 US/Pacific, Oliver Humpage wrote: States always match address pairs directionally. Even though floating is not physically tied to an interface, the packets on the external interface will be going the wrong way with respect to their addresses, and won't match state. How do you mean wrong way? If state merely matches source and destination IPs and ports, that should stay the same whether the packet is entering or leaving the system (if there's no nat). As I said, they match _directionally_. If you receive a packet in on $int_if, and it has a src of 10.0.0.1 and a dst of 192.168.0.1, it would be rather silly to accept another packet in on $int_if with a src of 192.168.0.1 and a dst of 10.0.0.1. The point of state is also to allow replies, so if src is known to be 10.0.0.1 when the packet is inbound, then src must logically be 192.168.0.1 when it is outbound. Since this is the original packet (not a reply), and it's going out another interface ($ext_if), src is still 10.0.0.1 and won't match. And of course directionality must be known when NAT is involved, so the unified state table simply works the same way whether translation is being done or not.
Re: How do I change my firewall ports to stealth mode?
On Tuesday, Sep 28, 2004, at 09:47 US/Pacific, [EMAIL PROTECTED] wrote: Kevin writes: Many IRC servers will drop sessions if they cannot talk to an ident service on the originating end. If you don't want your users to be on IRC; this could be considered as a benefit of blocking TCP/113 ;) Doubtful with IRC servers today. Although I'm not privy to the details of IRC per se, I have set up a number of firewalls in my day and have perused a lot of sockets code, and frankly, I would be surprised if anyone one this forum found they needed ident working for anything, including irc. I seriously doubt this is true any more. It is. It's a mitigating mechanism for many types of worms/bots/whatever, since they aren't capable of poking holes in their computer owner's broadband NAT device.
Re: How do I change my firewall ports to stealth mode?
On Tuesday, Sep 28, 2004, at 16:34 US/Pacific, Daniel Hartmeier wrote: On Tue, Sep 28, 2004 at 04:23:43PM -0700, Trevor Talbot wrote: It is. It's a mitigating mechanism for many types of worms/bots/whatever, since they aren't capable of poking holes in their computer owner's broadband NAT device. That's what UPnP is for, isn't it? *grin* luckily they don't seem to have caught up with that... On Tuesday, Sep 28, 2004, at 16:39 US/Pacific, [EMAIL PROTECTED] wrote: Yea, sure. I've seen *many* bots with identd running happily joining command and control IRC servers. Those servers are almost always rogue servers that don't care if identd is running. Sure, there are always machines that aren't filtering identd, and of course the control servers won't care. I said it was a mitigating thing, not a prevention thing :) More of an issue are the things that attempt to spread, as those want to be on the big networks where everyone can see them. The average exploited cable/DSL machine also won't have identd enabled. Put two and two together, and it's useful. Another use is requiring shell providers to properly identify their customers for abuse control, lest they lose all connectivity to an IRC network. 'Course, that only works if it's a network their customers care about, and it's a bit away from the original identd/pf scenario under discussion. Anyway, IRC networks do still find ident useful and even require it at times.
Re:
On Sunday, May 2, 2004, at 14:33 US/Pacific, ali asad lotia wrote: http://midcom-p2p.sourceforge.net/ i get the following results when i run it RESULTS: Address translation: NAPT (Network Address and Port Translation) Consistent translation:NO (BAD for peer-to-peer) Unsolicited messages filtered: YES (GOOD for security) my knowledge of the subtleties of nat and packet filtering is far from extensive. is it possible to get consistent translation with pf? Adding the static-port option to your nat rule(s) should do it.
Re: Traffic shaping in two directions on bridge
On Saturday, Apr 24, 2004, at 15:12 US/Pacific, Per-Olov Sjöholm wrote: Henning Brauer said: * Per-Olov Sjöholm [EMAIL PROTECTED] [2004-04-23 23:21]: This is fact: * Queue on the outgoing interface * On a bridge it is according to the FAQ at OpenBSD STRONGLY recommended to filter on just ONE interface and pass everything on the other. (Have not read that much to take a debate on this...) but there's nor much relation between those two. you can filter on just one interface and queue on all. Yes I know... I think I could have choosen my words better. The reason for the question in the first place was that I have seen many bridge examples where people have followed the FAQ blindly, and done everything on the same interface (filter and queueing), and just pass on xxx all (with NO queueing) on the other. And this even though they queue in both directions. So... The queueing must be done on the outgoing interface, no matter if it's set up as a bridge or not. Right ? This means that over 90% of all bridge examples I have seen on the net where queueing takes place in two directions are wrong. Or did I mess something up here ? You missed what Henning said next: you just classify unsing pf, adding mbuf tags telling the queueing code (which lives much further down the chain) where to enqueue. wether you write the tag on the same interface as the queues lives on or not doesn't matter (except for the packets leave kernel land in between, aka ftp-proxy etc, obviously). The actual queues themselves (altq on ...) only apply to packets going out their interfaces, but pf can direct traffic to them (pass .. queue) from anywhere.
Re: PF flow picture
On Sunday, Apr 25, 2004, at 02:26 US/Pacific, Per-Olov Sjöholm wrote: Have anybody made a packet flow picture for PF like the one Darren Reed has for IP filter. http://mniam.net/pf/pf.png http://homepage.mac.com/quension/pf/flow.png Daniel has a collection of links (including these) on the bottom of http://www.benzedrine.cx/pf.html -- some interesting things there.
Re: packets with SYN and FIN set not discarded! what does scrub actually do ?
On Saturday, Jan 24, 2004, at 09:42 US/Pacific, Per-Olov Sjöholm wrote: A friend yesterday scanned my firewall with nessus. One thing he found was that nessus said: The remote host does not discard TCP SYN packet which have the FIN flag set. Depending on the kind of firewall you are using, an attacker may use this flaw to bypass its rules. I do however use: block log all scrub in on $INTERNET_INT all fragment reassemble And on all incoming TCP permit rules I use S/SA as the flag combination. I have earlier used rules like: block in log quick on $ALL_INTERFACES inet proto tcp from any to any flags UAPRSF/UAPRSF block in log quick on $ALL_INTERFACES inet proto tcp from any to any flags PUF/PUF But I removed these as I assumed that scrub would block all illegal flag combinations for me. SYN+FIN is not an illegal flag combination, just ambiguous in some cases. As one of scrub's jobs is to normalize the ambiguous, it simply strips FIN. Questions: * What does scrub actually do? Can't find much in the pf.conf man page. - Validates and reassembles/crops/drops IP fragments, dropping or stripping ambiguous DF bits in the process - Randomizes IP ID if appropriate - Enforces a minimum TTL if appropriate - For TCP flags: SF/SF - strips F SR/SR, /SAR, F/AF, P/AP, U/AU - drops strips U if no valid urgent data - Adjusts TCP MSS if appropriate - Modulates TCP timestamps if appropriate * Do I have to manually block all illegal flag combinations as I earlier used to do when I used ipfilter? No.
Re: Dual transparent bridge configuration problem with pf.
On Friday, Jan 23, 2004, at 13:45 US/Pacific, Mario Lopez wrote:
what I need to do is let pass anything that is comming from WIFI
Switch without restriction EXCEPT the traffic destined for several
machines in the WAN Switch
My configuration looks something like this:
|NAS DEVICE|--- xl2 -- BRIDGE-- fxp0 -- |WIFI_SWITCH|
wifi_ext_if = xl2
wifi_int_if = fxp0
#
# Pass all traffic from wifi_ext_if to wifi_int_if to filter in that
one.
#
pass in quick on $wifi_ext_if all
pass out quick on $wifi_ext_if all
pass in on $wifi_int_if all
pass out on $wifi_int_if all
servidores = { 1.2.3.4, 4.3.2.1, 1.2.3.5 }
block out log on $wifi_int_if proto tcp from any to $servidores port {
135, 137, 138, 139, 1443 }
block out log on $wifi_int_if proto udp from any to $servidores port {
135, 137, 138, 139 }
It sounds like you want these rules to be for $wifi_ext_if, or in the
other direction. If the wifi clients are trying to contact
$servidores, packets to $servidores will come in on $wifi_int_if and go
out on $wifi_ext_if.
Re: Problem with log for loopback address
On Monday, Jan 12, 2004, at 08:05 US/Pacific, Laurent Cheylus wrote: I have done some tests without 'scrub' rule (scrub in all in my pf.conf) but the incoming packets from 127.0.0.1 for my external address are not logged either. ip_input() drops packets with 127/8 in either address field when they appear on non-loopback interfaces. This happens before pf sees the packet.
Re: bridge, but when ?
On Wednesday, Jan 7, 2004, at 04:46 US/Pacific, Ed White wrote: On Wednesday 07 January 2004 00:27, Trevor Talbot wrote: On Tuesday, Jan 6, 2004, at 09:59 US/Pacific, Ed White wrote: I was playing with a 3-if firewall with static IP 10.* when I got a simple doubt: when is supposed to be used the bridge feature ? When you want a switch (smart hub) instead of a router. So what are the advantages of a bridge for a classic 3-if firewall ? No advantages, many disadvantages. I read somewhere that it speeds things up. Is it right ? Bridging might be slightly faster, but you'd have to benchmark to find out. There are other performance bottlenecks that have a much larger effect than bridging vs routing. If so, why it isn't advised on the FAQ to use it when there are 2+ if ? Bridging isn't conducive to IP firewalling. Think about it: does your switch pass only IP traffic? Using a bridge configuration in place of an IP routing firewall is something you do very carefully, and only to get very specific functionality (such as that 2-interface transparent filter you mentioned). Performance etc is mostly irrelevant.
Re: A very basic firewall
On Wednesday, Jan 7, 2004, at 08:33 US/Pacific, Bernard El-Hagin wrote: 1. Block *everything* coming in on my external interface (tun0) 2. Pass everything out of tun0 and keep state 3. Pass everything in and out on loopback lo0 The way I see it, this should be good enough to surf the net, irc, listen to net radio, and so on (thanks to keep state), but should keep out any traffic not initiated by me. And mostly it works that way, but from time to time things don't work as expected. For example, even though I can use IRC I can't send files via DCC. Or, when I surf the net resolving takes *ages* (ca. 2 minutes). When I disable the firewall everything starts to work as expected. DCC is similar to FTP in that it often requires the client to act as a server (accepting incoming connections). You'll need to configure a port range on the client and add a pass in rule for that range. Ident (TCP 113) is another common server case for IRC. DNS I can't guess at, but you can troubleshoot it yourself by adding log to your block rule, and running tcpdump -env pflog0 to see what packets are blocked.
Re: A very basic firewall
On Wednesday, Jan 7, 2004, at 17:14 US/Pacific, Tamas TEVESZ wrote: On Wed, 7 Jan 2004, Bernard El-Hagin wrote: 1. Block *everything* coming in on my external interface (tun0) do you think icmp is called a *control* protocol just because they couldn't come up with a better name? pf has this wonderful option called keep state. When used on an outbound rule, it allows relevant ICMP replies back in.
Re: bridge, but when ?
On Tuesday, Jan 6, 2004, at 09:59 US/Pacific, Ed White wrote: I was playing with a 3-if firewall with static IP 10.* when I got a simple doubt: when is supposed to be used the bridge feature ? When you want a switch (smart hub) instead of a router.
Re: interface improvements - help needed!
On Tuesday, Jan 6, 2004, at 18:00 US/Pacific, j knight wrote: Henning Brauer wrote: On Tue, Jan 06, 2004 at 03:48:36PM -0700, j knight wrote: Henning Brauer wrote: that is in practice true for 99% of you. the state key does not include the interface, but the direction. as long as routes do not change that is equivalent to beeing bound to the interface. Would you agree then that the behavior of non -current pf is the equivalent of if-bound? no, floating. The implimentation may be closer to floating but the actual behavior, as you pointed out, is more like if-bound. Would you agree? -stable's behavior is floating. Float isn't new in -current, it's just a way of describing what was already there, since there are now other new behaviors. In most cases, float will appear to be if-bound (but isn't really). Tricks like this are possible: http://www.benzedrine.cx/pf/msg01874.html
Re: HTTP/FTP Proxy not working
On Thursday, Jan 1, 2004, at 13:59 US/Pacific, James Cammarata wrote: I finally noticed that packets with destination 127.0.0.1 were being routed out my main external interface. Why? Don't ask me. So I added this rule: pass in quick on xl2 route-to lo0 from any to 127.0.0.1 keep state Maybe this has something to do with the fact that I've got two external interfaces (xl0 goes to our old frac. T1, xl1 goes to our new full T1). We use xl0 to service our WAN, with all the large traffic from our main support center going out xl1. Anyone have some forensic analysis as to why I had to add this rule? netstat -nrf inet can verify that the right interface is being used by the routing tables. But route-to bypasses that, so if you're using it in other pf rules, I would look there first. Perhaps you have something like pass in on xl2 route-to xl1 from $support to any?
Re: Impossible ftp-proxy problem
On Tuesday, Dec 30, 2003, at 14:25 US/Pacific, Ghazan Haider wrote: I am running OpenBSD 3.4 as firewall on one machine, and have tried for weeks to get ftp-proxy to run. Ive tried evey example in the howtos. I can use the ftp sites from the OpenBSD itself, but not from an internal computer. I dont get error messages except a rare pf nat lookup failed 127.0.0.1:48711 (No such file or directory), when ftp-proxy has -D3 and -V Ive tried tcpdumping.. and I see no port 21 connections leaving the ext_if but seen them come in from int_if. A telnet localhost 8021 connects then quickly disconnects, so ftp-proxy does exist. Heres my pf.conf: rdr on $int_if proto tcp from $internal_net to any port 21 - 127.0.0.1 port 8021 block in all # ftp proxy pass in on $int_if proto tcp from any to any port 21 keep state Have to keep in mind that filter rules happen after translation by nat/rdr. Thus, you need to reference port 8021 here.
Re: Tagging packets over the net
On Monday, Nov 24, 2003, at 13:51 US/Pacific, Kifah Abbad wrote: there is already some kind of tagging in IP: tos value. unfortunately, pf can not handle tos value for own purposes. from the other side, tos width is 4 bits only so it can not handle much of useful information (pf tags, for example). additionally, the way, the routers over the world can interpret tos value, is unpredictable. How about if i use IP-V6? would that give me more space? comparible to space i have using pf-tagging? (in comparison to the 4 bits given by TOS) IPv6 has a 20bit flow label. See http://zvon.org/tmRFC/RFC2460/Output/ sections 3, 6, and 9.
Re: rdr requires a pass?!
On Monday, Oct 13, 2003, at 11:43 US/Pacific, Jay Moore wrote: oh, where did I put that block diagram? :) The original: http://mniam.net/pf/pf.png My version: http://homepage.mac.com/quension/pf/flow.png
Re: FF - Frame Filter for OpenBSD
On Thursday, Sep 25, 2003, at 12:35 US/Pacific, Ste Jones wrote: The idea is - compare mac addresses and IP address (listed in a hash table for quick lookups) If there is no entry drop the frame... otherwise let the frame get decapusluted further up the stack well thats the idea... shouldn;t be too tricky (in theory haven;t looked at any code yet though) Example scenario one of my friends runs a dedicated hosting company the users have full root access to each box. the company wishes to tie IP addrs to mac addrs so that each box on the network can not allocate IP addresses to itself. the only way i can see this working is by doing MAC address filtering. On Thursday, Sep 25, 2003, at 13:30 US/Pacific, Ed White wrote: http://marc.theaimsgroup.com/?l=openbsd-pfm=106275731529071w=2 Bridge tagging doesn't scale to large numbers of hosts or pf rules very well, for the purpose of locking an IP to a specific MAC. I mean that in the rule management sense, not performance. If this is a routing configuration, one thing you could try is adding static permanent arp entries for the hosts. Even if undesired packets get passed inbound (and forwarded on), replies would go to the arp entry, not the original sender.
Re: pf with ethernet bridge and one ip
On Saturday, Sep 13, 2003, at 06:48 US/Pacific, Daniel Hartmeier wrote:
On Sat, Sep 13, 2003 at 03:35:30PM +0200, Torsten wrote:
(lan_A)-( if_A: noIP )-|bridge|-( if_B: ip_B )(lan_B)
IP datagram from (lan_A) to ip_B
First appearance of the ip datagram within pf is: IN if_B (!)
IP comes in a ethernet frame with dst mac for if_A and can only
arrive on if_A due cabling.
Why would the destination MAC be for if_A? Normal ARP should
respond with if_B's MAC over the bridge.
Sorry, i made a typo there. The dst MAC is the MAC of if_B
Why would a frame from lan_A (to anywhere) come in on if_B (and not,
first, on if_A)? That makes no sense, indeed. Either you were not
tcpdumping on if_A correctly, or you were seeing a reply in reverse
direction. A packet from a host on lan_A to ip_B should be seen only
incoming on if_A, then the stack on the bridge will notice that the
destination is itself (if the destination MAC address is that of
if_B), and consume it. There's no reason why it would pass if_B at all.
tcpdump will only see it on if_A, because the driver will bpf_mtap() it
there. L2 processing is where things get screwy. If only the stack
were really on the bridge...
Why is there no way for gettin the physical interface the packet
comes in? this is the *only* thing that ain't spoofable.. i would
love to filter that in the pf :)
If you update to -current, you can use tags for that. Either bridge or
pf can add a tag ('packet came in on interface fxp0'), and you can
filter based on that tag.
Bridge tagging won't work either; the bridge interface technically
never sees this packet.
The frame hits ether_input(), which notices the interface is a bridge
member, and kicks it to bridge_input(). bridge_input() realizes the
destination MAC is one of ours, so it resets m_pkthdr.rcvif to the
matching interface, and drops the packet back to ether_input(). Normal
processing from there.
The bridge filters never get hit until it's queued on a softnet for the
bridge interface itself, which will only happen for packets not to us.
Personally, I think the entire implementation of bridging in the BSDs
and Linux is an ugly hack. Microsoft's method makes a lot more sense:
the bridge interface supersedes L3 on the member interfaces, and gets
an address of its own. It's easier to follow logically.
Anyway, back to OpenBSD, this internal transit to the matching
interface makes sense from an L3 perspective (which is probably why
it's done, to keep the upper layers happy). Bypassing bridge ether
filtering on the real receive interface is a problem though.
Re: pf with ethernet bridge and one ip
On Thursday, Sep 11, 2003, at 16:40 US/Pacific, Torsten wrote: i have problems with pf on a openbsd 3.3-stable ethernet bridge. my setup: (lan_A)-( if_A: noIP )-|bridge|-( if_B: ip_B )(lan_B) IP datagram from (lan_A) to ip_B First appearance of the ip datagram within pf is: IN if_B (!) IP comes in a ethernet frame with dst mac for if_A and can only arrive on if_A due cabling. Why would the destination MAC be for if_A? Normal ARP should respond with if_B's MAC over the bridge. Inside pf i can't decide if the ip datagram has arrived on if_A or if_B it would be great if i can write pf rules depending on the interface the ip datagrams arrive as mac and ip adresses are spoofable ;) The bridge causes an internal transit to the interface matching the destination MAC address prior to filtering and upper-layer processing. I don't know of a way around this.
Re: reassemble tcp and SuSE clients woe
On Monday, Sep 8, 2003, at 13:12 US/Pacific, Sigfred Håversen wrote: Not sure if this should be reported as a bug or not, so please bear with me. A scrub on $ext_if reassemble tcp will deny some SuSE clients access to some Microsoft IIS webservers. This appears to be an issue with SuSE's latest kernel (2.4.20-100) only. tcpdump data would help, for both interfaces. You can either write a file (-w) or provide at least -vx output.
Re: Rule Numbers
On Saturday, Sep 6, 2003, at 10:20 US/Pacific, stefan wrote: Today i have tested first the output from the command pfctl -s rules On 3.2 @0 scrub in on xl0 all min-ttl 2 fragment reassemble @1 scrub ... On 3.3 scrub in on fxp0 all min-ttl 2 fragment reassemble scrub out ... It is possible to get under 3.3 a number how under 3.2? pfctl -vvs rules
Re: Help on PF 3.3
On Friday, Aug 29, 2003, at 06:19 US/Pacific, Roberto Jobet wrote: 14:54:46.727210 rule 0/0(match): block in on xl1: 172.31.0.1.15583 10.0.0.3.3306: P 0:5(5) ack 1 win 17376 nop,nop,timestamp 321901777 1961997906 (DF) [tos 0x8] even if there's a rule (# 21) that should let flow packets between both servers (...) That packet isn't a connection creating one (S/SA), so it won't match. Existing connection before the firewall rules were loaded?
Re: PF stress testing
On Friday, Aug 29, 2003, at 10:58 US/Pacific, Adam Getchell wrote: I'm looking stress test pf, to provide numbers for a possible UC Davis campus firewall based upon OpenBSD/pf. I can get access to a read-only log of UC Davis' entire incoming bandwidth. I'm looking to get it into tcpdump format, and then replay the traffic against the firewall. There's this: http://tcpreplay.sourceforge.net/ I haven't tried it, would be interested to know how well it works for you.
Re: blocking specific sized echo requsts.
On Wednesday, Aug 27, 2003, at 20:13 US/Pacific, Nick Buraglio wrote: Is is possible to block specific sized icmp echo requests (specifically 92 byte echo requests) with pf? pf doesn't have any packet/payload length matching abilities.
Re: Config file weirdness
On Tuesday, Aug 26, 2003, at 16:15 US/Pacific, Greg Dickinson wrote:
I'm rather new to pf :-) having just upgraded our firewall from obsd
3.9 to 3.2. The firewall was configured by a previous admin with five
interfaces, one each to the Internet, web server, student quarters,
administrative LAN, and proxy server - all the public addresses are
bound to the fxp0 (internet) interface and are rdr'd and/or natted to
the outside world.
# web server segment - fxp3
block in quick on fxp3 from !172.16.3.4/30 to any
pass in quick on fxp3 proto { tcp, udp } from 172.16.3.6 to 10.10.1.2
port = 53 keep state
pass out quick on fxp3 proto { tcp, udp } from any to 172.16.3.6 port
= 137 keep state
pass out quick on fxp3 proto { tcp, udp } from any to 172.16.3.6 port
= 138 keep state
pass out quick on fxp3 proto { tcp, udp } from any to 172.16.3.6 port
= 139 keep state
pass out quick on fxp3 proto { tcp, udp } from any to 172.16.3.6 port
= 80 keep state
pass out quick on fxp3 proto { tcp, udp } from any to 172.16.3.6 port
= 445 keep state
pass in quick on fxp3 proto tcp from 172.16.3.6 to 172.16.1.6 port =
3128 flags S/SA keep state
pass in quick on fxp3 proto tcp from 172.16.3.6 to any port = 25 flags
S/SA keep state
# block in quick on fxp3 all
However, if I uncomment the last line (block in quick...) then all
traffic to this segment stops. I'm specifically allowing in traffic
from the internal LAN on ports 137-139, but it won't go through if I
have a default deny rule in the bottom of the interface section, or
at the bottom of the config file. What have I missed?
You can add log to that rule, and use tcpdump -eni pflog0 to see
which packets are being blocked. Maybe they aren't covered by the
above rules. pfctl -vsr to get the list of rules with numbers.
(BTW - I'm willing to post or e-mail the full config file, if that
helps...)
It would, along with info on the packets being incorrectly blocked.
Re: NAT+Gnomemeeting
On Monday, Aug 18, 2003, at 12:47 US/Pacific, Joey Lamonthe wrote: Hello folks from pf, and Damien from gnomemeeting (I don't want to wrote 2 e-mails..) SPECS OF MY SYSTEM: OpenBSD 3.3, stable release. This is a gateway with NAT and RDR rules (You can see rules below) Sometime it's work... After investiguation, I found the real problem. my machine use the SAME port to send/receive video(or audio) data (this is an UDP packet). Here the graphic to exlpain: WHEN I SEND DATA: SRC PORT: 5001 DST PORT: 49910 mymachine.5001 --- 49910.gateway.5001 49910.myfriend WHEN I RECEIVE DATA: SRC PORT: 49910 DST PORT: 5001 myfriend.49910 --- 5001.gateway.49910 --- 5001.mymachine The problem is, when I use the same port for send/receive with UDP packet (never tried with TCP), it's simply does'nt work via gateway. In fact, it's does not redirect from gateway to my machine, but I can send data to my friend. For standard NAT operation, pf rewrites the source port. In the session you posted tcpdump files for, the translation went like this: yourmachine:5002 --- 49606 [gateway] 1234 --- 49606:yourfriend Since port numbers are exchanged by the application, the RTP stream comes back from yourfriend:49606 to gateway:5002. The gateway wants to create a mapping for this incoming data (you:5002 - 5002 - 49606:friend), but a mapping already exists for those same ports (you:5002 - 1234 - 49606:friend). Since both can't exist at the same time, the incoming RTP stream is dropped. You can tell pf not to rewrite the source port by using the static-port option for your nat rules.
Re: SecureRemote
On Monday, Aug 18, 2003, at 15:50 US/Pacific, [EMAIL PROTECTED] wrote: I'm having some problems using Pf in 3.3 current ( i386 )with securemote. This thread may help: http://www.benzedrine.cx/pf/msg01436.html
Re: Ruleset Rdr Problem
On Monday, Aug 11, 2003, at 18:35 US/Pacific, Scott Sipe wrote:
OpenBSD pf firewall for small network, adsl in, doing nat. I want to
rdr certain ports on the firewall to an internal server. My rdr and
pass lines work fine for some services (http [80], rsync [873], etc)
but two services DON'T work--MS RDP (Remote Desktop) which runs on
port 3389 on the windows boxes. I'm rdring ports 4001 and 4002 to two
different computers. This works if I take out the line block all
and doesn't work when I do block all--http and rsync work regardless.
tcp_in = { 22, 80, 873, 4001, 4002 }
rdr on $ext_if proto tcp from any to any port 4001 - $comp1 port 3389
rdr on $ext_if proto tcp from any to any port 4002 - $comp2 port 3389
pass in quick on $ext_if inet proto tcp from any to any port $tcp_in
flags S/SA modulate state
Keep in mind the filter rules are applied _after_ translation, which
affects the port numbers. $tcp_in should include 3389 instead of 4001
and 4002.
Re: packet filtering
On Sunday, Aug 3, 2003, at 14:30 US/Pacific, Mark Bojara wrote: When I only have a pass log rule and telnet to 196.4.160.2 53 I get this: 23:18:54.694500 opium.co.za.4774 apollo.is.co.za.domain: S 4194577793:4194577793(0) win 65535 mss 1460,nop,wscale 0,[|tcp] (DF) [tos 0x10] Forgot to mention: use -e with tcpdump on pflog0 and it will show the interface it's going through. Sorry about that. When I use the below filter rules I get the blocked matches on pflog0 that i sent in my previous email. block in log 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 keep state If I would swop the pass out rule so that it is on fxp0 it will work fine but that defeats the purpose I need it for. Any ideas? If 196.4.160.2 is attached to fxp0, and you're blocking all traffic in (except tcp 22, which isn't used), then there's no way it can respond to connection requests from 196.34.165.210. The pass out rule's keep state option would take care of that.
Re: Payload inspection
On Friday, Aug 1, 2003, at 13:59 US/Pacific, Adam Coyne wrote: I'd like to pass or block certain packets based on an inspection of the payload after scrubbing. It might be fun if pf were able to use a bpf-style expression like 'protocol[offset:size] = x' to create rules which look at the data in the packet, but it seems more practical to do it in a separate program. Is it possible for me to create rules to somehow hand off selected packets to a different program? I'm thinking of something along the lines of a FreeBSD divert socket, although I'm certainly open to better suggestions. You could probably put something together with tun. There aren't any mechanisms that work directly with the filter like divert does. Note that scrub, at best, can piece together IP fragments. It cannot handle TCP segments, or do anything approaching snort's stream reassembly. I'm curious what this would be useful for (in terms of pass/block decisions), since there are a lot of caveats in actually getting the data.
Re: pf and altq couple: before and after merge
On Monday, Aug 4, 2003, at 13:35 US/Pacific, Alexey E. Suslikov wrote: BEFORE MERGE: ok, assume what we have some already keepstated tcp connection. everybody knows: once keepstated, such connection has ability to pass any interface and any direction without necessity in the additional pass rules. next, assume what we need to shape packets, members of our example keepstated connection. this is easy as the source/destination addresses and port numbers are known: only thing we need to do is the filter value within the altq's class. it is important to note: we have ability to assign our connection's in and out packets into DIFFERENT queues, because of the matching criteria. remember? the criteria is in the source and destination address/netmask, source and destination port, protocol number combination. more than this! we have ability to shape each connection's packet on ANY interface: just define one more scheduler with one more class's filter with the same host, port and protocol values. so the resume for this section: you have ability to catch any keepstated connection's packet on any direction and on any interface independently. Only outbound. ALTQ didn't tag packets for other interfaces, AFAIK. AFTER MERGE: as the queue is simply attached to pf's keepstated rule, the criteria is the connection's state. ok, lets think: what packets are matching this state? they are: in and out packets on any interface. in other words, any packet of the connection. so, what is the point of example? we are unable to match in and out packets to shape them separately (remember, the state is the matching criteria) and we are unable to shape same packets on the different interfaces (the state is the matching criteria). oops, all connection's packets forcedly placed to one queue and we have no ability to control traffic within this STATEFUL QUEUE. The ability to tag packets inbound for a queue that exists on another interface is a gain from pf, even though you're restricted to the same tag as outbound. ALTQ could only filter on outbound. The state entries are keyed by address pair and direction, so for most intents and purposes, you can simply create state on another interface to get queueing there. You can also create queues with the same name on other interfaces. If a state entry on an outbound interface does queue tagging, that tag will override all others from inbound interfaces. The two major losses from ALTQ are the traffic conditioner, and fine-grained classification on an interface using translation. There is indeed a loss in classification flexibility within state in general, but I don't think any of your points address it. DiffServ codepoint classification is one such loss.
Re: pf and altq couple: before and after merge
I wrote: The two major losses from ALTQ are the traffic conditioner, and fine-grained classification on an interface using translation. Whoops. The translation loss was still present before the merge. Scratch that one :)
Re: pflog question
On Thursday, Jul 31, 2003, at 12:09 US/Pacific, Georg Wendenburg wrote: On an OBSD 3.2, on the pflog i have seen something like: some date . rule 6/0(match): block in on rl0: xx.xx.xx.xx.pp yy.yy.yy.yy.1424: udp 376 [ttl 1] it's obvious this is a scan of the MS-SQL Worm, but i don't understant that the ip (yy.yy.yy.yy) its not the ip of my server, and the ip (xx.xx.xx.xx) is an ip of a computer on the same subnet. if the destination ip is not my server ip, how can my server block it ? pf will drop any traffic it sees, if you tell it to. Your server did receive that packet in on rl0. It may not have routed it anyway, just ignored it, but pf got to see it first and chose to drop it. As for why it was received, perhaps rl0 is a shared link, and that was sent as a broadcast packet for the link? A cable line might behave that way.
Re: passive ftp
On Sunday, Jul 27, 2003, at 22:28 US/Pacific, Mark Bojara wrote: How can I allow passive ftp to certain hosts? I know that you can do it by allowing ports 49152-65535 to the host but that isnt very secure, is there a better way? ftp-proxy is capable of handling it. There's also a 'reverse diff' floating around to enable it to proxy servers (instead of clients). The list archives should have a few discussions on this.
Re: packet filtering
On Wednesday, Jul 30, 2003, at 16:24 US/Pacific, Mark Bojara wrote: 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 mss 1380,nop,nop,timestamp[|tcp] 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 mss 1380,nop,nop,timestamp[|tcp] (DF) that is what i am getting when i try and telnet to 196.4.160.2 53 from 196.34.165.210 The second filter rule must be a block rule that affects fxp0? Daniel's suggestion was for a single pass log-all rule, with no other rules. That way you can follow all packets in both directions through all interfaces pf sees. It should be easy to build a ruleset after that.
Re: Fix pf(4) nat proxy port allocation for manually specified ranges... perhaps?
On Saturday, Jul 26, 2003, at 19:55 US/Pacific, Melameth, Daniel D. wrote: Newbie running 3.3 stable with pf, dhcpd and isakmpd... ...recently upgraded to stable in the hopes of curing some ill that I have... and now I ask for peer review... The following snippets DO NOT work fine under 3.3 stable (on similar machine): nat on $ext inet proto udp from $ipp port = 5004 to $ipc - $ext port 5004 nat on $ext inet proto udp from $ipp port = 5567 to $ipc - $ext port 5567 # pfctl -s all ... nat on ep1 inet proto udp from 172.30.0.127 port = 5004 to 191.255.255.1 - 223.255.255.1 port 5004:35859 nat on ep1 inet proto udp from 172.30.0.127 port = 5567 to 191.255.255.1 - 223.255.255.1 port 5567:48917 Did you upgrade pfctl too? It had a bug that caused it to set the second port incorrectly. For what you're doing, using the static-port option instead of a specific port should also work.
Re: Nat ports
On Saturday, Jul 26, 2003, at 20:29 US/Pacific, Bryan Irvine wrote: Is there a way to get pf to never use specific ports? For example a client on my LAN might send a request for a certain webpage which gets sent to the gateway from a certain port we'll say, 43101. The Request hits the gateway and then get's changed to another source port like 12754. The problem is that 12754 will trigger a false postive in snort that someone is scanning for a ddos mstream client handler. Bad admin. How (if possible) can you create a list of ports than will never be used by pf? PF doesn't look at anything other than the nat rule and existing states when choosing a port. You could change the nat rule to use a range that doesn't have any undesired ports in it, but that's all I can think of at the moment.
Re: virtual interface
On Thursday, Jul 24, 2003, at 10:59 US/Pacific, Mark Bojara wrote: Ive just been thinking of a possible solution to my problem on previous thread. How about I create vlan's and bridge them together. So that it forms something like: fxp0--altq--virtual interface--altq--dc?--host The vlan interfaces won't work, because they require 802.1q tags to actually see any traffic. You might be able to cook something up with lo1 and binat.
Re: stateful filters affect queue filters
On Tuesday, Jul 22, 2003, at 23:46 US/Pacific, Mark Bojara wrote: Thanks for the advice, Ive tried to have one rule to catch both directions but if it is outgoing traffic then the keepstate will automatically allocate the incoming packets that are comming back to the same queue. But if the request originated from a incoming request there is no way possible that the same outgoing queue will work for that traffic. When a state entry is created, it saves an internal queue ID tag. Every packet that matches the state gets tagged with that queue ID, no matter which direction it's going. Later, when the packet is about to physically travel out of an interface, ALTQ retrieves the tag and looks for a matching queue on that interface. If it finds one, the packet goes there; if not, it goes in the default queue. The last tag applied is the one ALTQ sees. So, for a given packet, it has two potential tag points: -- [IN tag] ---[ forward ]--- [OUT tag] --[ altq ]-- If it's tagged in the OUT slot, that's the one ALTQ sees, whether it was tagged on the IN slot or not. In your setup, this is what you want to happen every time. It's also possible to tag it on the IN slot, for a queue that actually resides on the OUT interface. You don't do this (and don't need to, from what I see), but it's possible. Anyway, the tagging in the state entry happens no matter which direction the packet is traveling. Thus, when you create a state on an inbound packet, the queue tag will only matter for reply packets (going back out on that interface). The inbound packets will still be tagged, but the tags don't match any queue on the interface they go out on, so nothing happens. Meanwhile, you also have a rule to create state out on that other interface, and that queue tag does apply. You should keep the one-rule-per-interface setup, i.e. pass in on $i01, pass out on $i03. You should also set each rule to use the appropriate queue on that same interface, no matter which direction the rule is for. Does that make sense? On Tue, 22 Jul 2003, Trevor Talbot wrote: On Tuesday, Jul 22, 2003, at 06:43 US/Pacific, Henning Brauer wrote: On Tue, Jul 22, 2003 at 02:55:47AM -0700, Trevor Talbot wrote: Also note that most of your rules are a bit loose as far as TCP goes. The upside is that they'll pick up existing connections when you reboot/reconfigure the firewall, but you may want to get more control over which direction connections are initiated from by using flags S/SA with all of them. It depends on your situation; this is just a heads up. I consider this flags filtering stupid. Well true, if you aren't using modulate state, there isn't much point. Mark's situation could be handled with just rule reorganization. He currently has rules that catch both directions, and my impression is that he didn't really want connections being initiated in both directions. So I ended up suggesting that, instead of realizing both rules aren't necessary now that keep state is present.
Re: stateful filters affect queue filters
On Wednesday, Jul 23, 2003, at 03:36 US/Pacific, Mark Bojara wrote: I understand what you mean but this is only for a outgoing connection with keepstated incoming. If another completely different incoming connection gets established then since it did not orignate as a outgoing connection the keep state will not apply. I don't follow. If all of your rules specify queues, then the queues will apply. Is there a case where you don't want to specify queues that I missed? On Wed, 23 Jul 2003, Trevor Talbot wrote: On Tuesday, Jul 22, 2003, at 23:46 US/Pacific, Mark Bojara wrote: Thanks for the advice, Ive tried to have one rule to catch both directions but if it is outgoing traffic then the keepstate will automatically allocate the incoming packets that are comming back to the same queue. But if the request originated from a incoming request there is no way possible that the same outgoing queue will work for that traffic. Anyway, the tagging in the state entry happens no matter which direction the packet is traveling. Thus, when you create a state on an inbound packet, the queue tag will only matter for reply packets (going back out on that interface). The inbound packets will still be tagged, but the tags don't match any queue on the interface they go out on, so nothing happens. Meanwhile, you also have a rule to create state out on that other interface, and that queue tag does apply. You should keep the one-rule-per-interface setup, i.e. pass in on $i01, pass out on $i03. You should also set each rule to use the appropriate queue on that same interface, no matter which direction the rule is for.
Re: incoming outgoing queue on single interface/queue
On Wednesday, Jul 23, 2003, at 10:21 US/Pacific, Mark Bojara wrote: I was wondering if its possible to either set up one queue on a single interface to do both incoming and outgoing traffic? No, not at present. Or maybe possibly having it on split interface's but assigned to one queue. eg: pass out on dc1 from za to 196.34.165.210 keep state queue opium_01_l pass in on fxp0 from za to 196.34.165.210 keep state queue opium_01_l A queue must be tied to an interface; it can't be floating for use with any flow. One thing you can do is specify queues with the same name on different interfaces (this ties in with the IN tagging I mentioned in the last thread), but this probably isn't what you're after.
Re: incoming outgoing queue on single interface/queue
On Wednesday, Jul 23, 2003, at 13:04 US/Pacific, Mark Bojara wrote: Basically why I want them to have the same name is because there are multiple interfaces on this server were clients are connected too, So if I want borrowing (HFSC) to work overall for everybody it has to be assigned under a single parent. Oh, management of inbound traffic on your uplink is the goal? There aren't any mechanisms to do that at present. Queueing would not be effective for that purpose anyway, as Henning mentions. One point is that it's impossible to guarantee full use of the inbound pipe; you can't prioritize or drop traffic you never see (because the pipe was saturated and the other end couldn't send it). Another point is that in order to prioritize packets, the queues must be partially full. In order to fill the queues, you need to delay the packets. Since the packets are already here, on the other side of the bottleneck, delaying them serves little purpose. The only mechanism that's generally effective for inbound traffic is simple rate limiting, where traffic exceeding the limit is dropped. While the ALTQ framework does have that capability, it isn't exposed in PF. It lacks the flexibility that most people would want anyway (rough approximation of sharing, per-host limits, etc). On Wed, 23 Jul 2003, Trevor Talbot wrote: On Wednesday, Jul 23, 2003, at 10:21 US/Pacific, Mark Bojara wrote: I was wondering if its possible to either set up one queue on a single interface to do both incoming and outgoing traffic? No, not at present. Or maybe possibly having it on split interface's but assigned to one queue. eg: pass out on dc1 from za to 196.34.165.210 keep state queue opium_01_l pass in on fxp0 from za to 196.34.165.210 keep state queue opium_01_l A queue must be tied to an interface; it can't be floating for use with any flow. One thing you can do is specify queues with the same name on different interfaces (this ties in with the IN tagging I mentioned in the last thread), but this probably isn't what you're after.
Re: incoming outgoing queue on single interface/queue
On Wednesday, Jul 23, 2003, at 16:28 US/Pacific, matthew j weaver wrote: On Wed, Jul 23, 2003 at 03:18:05PM -0700, Trevor Talbot wrote: simple rate limiting, where traffic exceeding the limit is dropped. While the ALTQ framework does have that capability, it isn't exposed in PF. It lacks the flexibility that most people would want anyway (rough approximation of sharing, per-host limits, etc). You could absolutely define many conditioners on an interface with ALTQ, and match to those conditioners by host -- effectively making crude per-host limits. I meant in automatic terms. There have been requests for things like all hosts in this netblock have a limit of N kb/s each. This can be solved with a bit of scripting, but some of the resulting rules that have been posted have been scary in length :) Losing this feature in the pf-altq mashup was unfortunate, it was an excellent, pragmatic solution for controlling inbound bandwidth usage. PF opens up some neat possibilities for future work on the conditioner, since it no longer makes sense to tie it directly to an interface. With the state engine recognizing flows, dynamic things are easier to do.
Re: Unreachable SSH / rdr problems
On Friday, Jul 18, 2003, at 17:13 US/Pacific, Ritz, Bruno wrote: since i have setup pf if cannot reach the local ssh server anymore. the rules i have are pretty simple: - if_ext=xl0 if_srv=xl1 if_users=xl2 ip_ext=w.x.y.z ip_http=192.168.0.2 ip_user1=192.168.1.2 rdr on $if_ext proto tcp from any to $ip_ext port 80 - $ip_http rdr on $if_ext proto udp from any to $ip_ext port 6502 - $ip_user1 nat on $if_ext from 192.168.1.0/24 to ! 192.168.1.0/24 - $ip_ext block in on $if_ext pass on $if_users pass on $if_srv pass on lo0 pass in on $if_ext proto tcp from any to $ip_ext port 22 keep state traffic (surfing etc.) from the internal network ($if_users) works fine. but when i try to connect to the sshd daemon on the firewall, it does not respond. the incoming traffic (port 80/tcp and port 6502/udp) does not pass the firewall. You don't have any pass rules for those. The rdr rules handle translation, but the block in on $if_ext rule drops the packets afterward. the ssh deamon is up and running, listening on port 22/tcp. i have 4 ips assigned to the external interface ($if_ext). I don't see anything obvious about this, but is sshd listening on the right IP (or everything)? Those rules as written can't deal with all 4 IPs at once.
Re: pf configuration - OpenBSD gateway
On Friday, Jul 18, 2003, at 13:26 US/Pacific, Angel Todorov wrote: I use the following pf.conf file for an internal network that passes through the openbsd gateway box then goes its way to the external firewall - then outside The problem is that often packets are dropped, for ex. pingging google.com from an internal network's hosts results in almost 40-50 % of the packets dropped... Do you know anything that may be the cause of the problem (i.e pf timeout settings, queue design errors, passing packets errors, kernel options, etc?) Can narrow it down real quick with tcpdump. Use it on both the internal and external interfaces, and make sure the packets appear on both. If they appear on one but not the other, then the machine isn't passing them for some reason. To figure out if it's pf, just disable it (pfctl -d) and see what happens. If it is pf, add log to all of your block rules, and apply tcpdump (use -e) to pflog0. Use pfctl -vvsq to watch the drop counts in the queues. If it isn't pf, the packets not forwardable counter in netstat -p ip will at least tell you if the kernel doesn't like routing them. Keep an eye on /var/log/messages for general errors, especially from network hardware.
Re: ALTQ help request
On Friday, Jul 18, 2003, at 21:03 US/Pacific, Mark Fordham wrote: I'm trying to get ALTQ working with the following setup without much success. To test I'm doing a simultaneous FTP upload and download from a Windows box on the internal network. The upload is being limited to 100Kb as expected but the download drops off rapidly after starting the upload. OpenBSD 3.3 snapshot 2003-06-06 ADSL 512/128 using PPPoE A performance/bugfix patch for tun(4) was added Jun 12: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/ if_tun.c.diff?r1=1.47r2=1.48 Volker's tests and commentary may help: http://secspace.de/altq_on_tun.html Your rules look fine.
Re: stateful filters affect queue filters
On Monday, Jul 21, 2003, at 23:48 US/Pacific, Mark Bojara wrote: I am running OpenBSD 3.3-current with HFSC queueing and stateful filters. If I enable my stateful filters anything defined via those filters does not go through my queue filters and gets unlimited bandwidth. Below is my pf.conf file, When I access 196.34.165.210 via ftp my bandwidth is limited but as soon as I access it via port 80 I have unlimited bandwidth. Assuming you're on fxp0, in the za table, and that by enable you mean adding keep state to rules you used before, this rule is the problem: pass in on fxp0 proto tcp from any to 196.34.165.210 port 80 keep state The best way to think of the state engine is as an entry that saves the important parts of the rule, and sits on that interface handling all future traffic for that connection, no matter which direction it goes in. There can only be one state entry for that connection on that interface. Since that rule doesn't assign a queue, those packets traveling through fxp0 will never be tagged for queueing, whether they're coming in or going out. I think the most important change to your rules is that all of them need to specify the queue (if any) that should be used on their associated interface, since they now control both directions on that interface. The queue assignment won't have any effect on the inbound traffic, only the outbound. Also note that most of your rules are a bit loose as far as TCP goes. The upside is that they'll pick up existing connections when you reboot/reconfigure the firewall, but you may want to get more control over which direction connections are initiated from by using flags S/SA with all of them. It depends on your situation; this is just a heads up.
Re: stateful filters affect queue filters
On Tuesday, Jul 22, 2003, at 06:43 US/Pacific, Henning Brauer wrote: On Tue, Jul 22, 2003 at 02:55:47AM -0700, Trevor Talbot wrote: Also note that most of your rules are a bit loose as far as TCP goes. The upside is that they'll pick up existing connections when you reboot/reconfigure the firewall, but you may want to get more control over which direction connections are initiated from by using flags S/SA with all of them. It depends on your situation; this is just a heads up. I consider this flags filtering stupid. Well true, if you aren't using modulate state, there isn't much point. Mark's situation could be handled with just rule reorganization. He currently has rules that catch both directions, and my impression is that he didn't really want connections being initiated in both directions. So I ended up suggesting that, instead of realizing both rules aren't necessary now that keep state is present.
Re: stateful filters affect queue filters
I wrote: On Tuesday, Jul 22, 2003, at 06:43 US/Pacific, Henning Brauer wrote: On Tue, Jul 22, 2003 at 02:55:47AM -0700, Trevor Talbot wrote: Also note that most of your rules are a bit loose as far as TCP goes. The upside is that they'll pick up existing connections when you reboot/reconfigure the firewall, but you may want to get more control over which direction connections are initiated from by using flags S/SA with all of them. It depends on your situation; this is just a heads up. I consider this flags filtering stupid. Well true, if you aren't using modulate state, there isn't much point. Er, after putting a bit more thought into this .. can't it be used to solicit responses from a host when you might not want responses given (default drop policy)?
Re: stateful filters affect queue filters
I wrote (again): On Tuesday, Jul 22, 2003, at 06:43 US/Pacific, Henning Brauer wrote: On Tue, Jul 22, 2003 at 02:55:47AM -0700, Trevor Talbot wrote: Also note that most of your rules are a bit loose as far as TCP goes. The upside is that they'll pick up existing connections when you reboot/reconfigure the firewall, but you may want to get more control over which direction connections are initiated from by using flags S/SA with all of them. It depends on your situation; this is just a heads up. I consider this flags filtering stupid. Well true, if you aren't using modulate state, there isn't much point. Er, after putting a bit more thought into this .. can't it be used to solicit responses from a host when you might not want responses given (default drop policy)? ...No. I'm confusing a couple different issues; there is no gain from filtering on flags in this context. (I still have 4 minutes; shall I try for a third reply to myself within an hour?)
Re: stateful filters affect queue filters
On Tuesday, Jul 22, 2003, at 15:27 US/Pacific, Alejandro G. Belluscio wrote: Basically, I think he refers to the use of 'flags' as being no effective to block attacks. I don't think he refers to stateful filtering. Which are very related but don't need to actually be used together (think). Depends on what you're doing and why. If you use modulate state, flags S/SA is recommended to avoid strange behavior between two hosts with existing connections when the firewall is restarted. Beyond that, the combination doesn't seem to have much practical use. http://marc.theaimsgroup.com/?l=openbsd-pfm=103962333222121w=2 The scrub code deals with these (and a few other combinations). If you're scrubbing and need to know if a packet is initiating a connection, S/SA is all you need to check. Explicit block rules aren't necessary for avoiding bogus traffic.
Re: Fragment Reassembly and Wormhole Routing for pf
On Monday, Jul 14, 2003, at 17:47 US/Pacific, Damien Miller wrote: Aaron Suen wrote: Currently, there are two major ways to handle fragmented IP datagrams in pf: fragment reassembly, and those other ones. I say those other ones because fragment reassembly is [seems to be] the recommended method of handling fragments, since only a fully reassembled fragment is guaranteed to contain enough header information to filter properly. For instance, nmap has a command line option that will chop packets up into ridiculously small fragments, not one of which contains enough header information to sufficiently filter. So if you demand high security, you have to use fragment reassemble, right? No - you just drop these tiny fragments. Fragments too short to contain a L3 header are invalid and should never be generated by legitimate applications. You might mean the _first_ fragment must contain an entire L4 header to be legitimate, but that doesn't extend to all fragments. Fragment reassebly is a normalisation technique, not a filtering requirement. It's a prerequisite for L4 filtering. You can't filter on data you don't have, and you can't know you have that data unless you're tracking fragments. Aaron is basically describing fragment crop with the addition of guaranteed L4 header reassembly, which is something that the man page suggests is intended for the future.
Re: Stupid Question
On Saturday, Jul 12, 2003, at 09:41 US/Pacific, Aaron Suen wrote: home LANs. My concern is that viruses are smart enough to spread through the insecure MS netowork protocols, which can't be disabled normally under various versions of Windows. I have Kerio firewall (It looks like a hacked-up version of the old Tiny, before they went commercial) on most machines, but I'm fairly sure it's nothing more than a SYN filter. I'm just concerned as to whether smarter virus writers are going to slip around these firewalls and spread through my LAN. Also, I'm not sure I can trust my users 100%. Yeah, Tiny sold their version 2 code to Kerio just before they started on v3. Kerio and similar filters should actually handle the MS protocols just fine on filtering alone, as far as IP goes. You can completely unload any non-IP protocols on the adapter. Some malware writers are installing drivers anyway. Tiny's v3 stuff and a few other commercial products claim to protect against this, but it's always going to be a leapfrog race. If the machine is compromised, it's compromised... Actually, from what I've seen of both 9x and NT networking stacks, it looks to me more like they exist entirely within driverland, which is neither kernel-land nor userland, really. The network drivers for an ethernet card collect layer 2 packets and send them up through a layer or two more of driver space before hitting the kernel. At least, this seems to explain why the same firewall software works in pretty much the same way between different versions of Windows. Also, dial-up and ethernet connections are handled differently, so firewalls need to know a lot about both to work for Windows (though I'm only interested in ethernet). So one need (theoretically) only insert a sort of driver between the network abstraction level of Windows (which reassembles IP and manages things like ARP) and the physical device driver (which simply captures and sends packets on the interface). The Windows network architecture is extremely layered. That was one of the reasons for my time and willingness comment -- anyone familiar only with BSD-style network stacks is in for culture shock. But yes, the NDIS layer has a couple slots for filtering, and is roughly in that spot. My comment about userland pf filtration is just the idea of some rather strange uses of pf. Since there is only one pf running on a machine at a time, and it can only be controlled by root, it can't be used for anything but filtering real packets on real interfaces. There may be a reason somebody wants to separate a series of networks, and perform filtration on some channels at a reduced priviledge level (e.g. so a regular user can control filtration, or to prevent leakage between networks). So one could use userland tunneling applications and a userland pf. For instance, one could modify a pptp userland daemon to spit packets through a unix-domain socket instead of a tun driver. Chain two of these together with a userland pf in between, and the user now has a filtering pptp proxy, using the ultra-powerful pf engine, which the admin of that machine doesn't have to maintain or worry about. The user running this proxy could administer it as a normal user, without needing any kind of priviledge escalation. So you could use your OpenBSD server to run a VPN that you don't want to actually be connected to. Something like this would probably fit the bill: http://www.tel.fer.hr/zec/vimage/ I haven't heard any rumors about that happening for OpenBSD though. It would certainly be fun to play with.
Re: Stupid Question
On Thursday, Jul 10, 2003, at 18:38 US/Pacific, Aaron Suen wrote: Does anybody forsee a port, of some sorts, of pf for Windows? Yeah, it sounds a little wild, but I could really use something like this. I have a bunch of Windows clients on my home LAN, and you can never really trust the LAN (even though it's firewalled) since these are Windows (a.k.a. virus-laden) machines. So I want to install software firewalls on every machine to provide secondary protection against threats on the LAN. The big problem is that there are no good free firewalls for Windows. Of course, everybody will recommend the same things, such as ZoneAlarm, and similar types of programs, but all I need is something that can do fragment reassembly, stateful inspection, and block certain ports (135, 137-139, 445, 1025-1027, 5000) while leaving everything else open by default. Every free firewall I've seen is missing something. ZoneAlarm is too aggressive, blocks everything by default and asks the user questions all the time (I want to set it up and forget it). Rule-based firewalls like the ones based on Tiny's codebase all seem to lack some reassembly and stateful inspection capabilities; they're basically just SYN filters. In my experience, recent Windows' IP stacks aren't _that_ bad at handling unexpected IP-level data. Most of the threat these days is at the application level, which is primarily what things like Zone Alarm and Tiny target. And as far as things like session interception go on LANs, you'll have a tough time guarding against that anyway. Especially when your attackers are armed with CAT5 and building keys. NT has always had a rudimentary IP filter if all you want to do is filter ports. Recent versions are slightly more capable: http://www.hsc.fr/ressources/outils/pktfilter/ At least Tiny - and probably ZA too judging by its behavior - mostly watch a fairly high level in the driver stack, where they actually get explicit notification of new connections. That's why both seem to be stateful by default -- they're using the OS's stack. It's probably also why they both suck at handling ICS. Actually, it would be pretty nice to have a userland application that does what the pf engine does. One could use it, for instance, to filter traffic that goes through other userland applications (such as ppp using tun*). I'm confused about this part. Windows doesn't typically send wire network data through user space (though I suppose you could argue the distinction on 9x, but that's another topic). For the BSDs, why? The kernel filtering would typically work better anyway, and it can already filter on tun. I'd like to know how feasible this Windows port idea would be. Doable, yes, but I suspect there's a shortage of people with time and willingness to get familiar with both systems.
Re: Passive FTP Proxy?
On Thursday, Jul 10, 2003, at 19:44 US/Pacific, Jason Dixon wrote: Is there any way to ftp-proxy an outgoing passive ftp connection through a default block policy on the internal interface? The man page suggests that if you don't use -n, ftp-proxy will proxy passive connections. You could filter based on ftp-proxy's user account then. I haven't tried this.
Re: Filter question
On Monday, Jul 7, 2003, at 23:12 US/Pacific, Tom Forbes wrote: This may sound very basic, but I don't understand why pf is behaving in the following manner. To wit, I have a pf.conf file that has two lines: block in on fxp0 all block out on fxp0 all fxp0 is my external interface. I noticed this morning that despite having been configured with these two lines, I was still able to use AIM. I could not access web-related or smtp-related services on the outside, however (which is what I would expect). But I don't understand why AIM should be accessible. The state table is always checked before any existing rules. So, if that ruleset was loaded after a state for AIM was created, the AIM connection would still hold. You can check the state table with pfctl -ss.
Re: Exchange server traffic shaping using pf/altq
On Monday, Jul 7, 2003, at 12:47 US/Pacific, ALEX POPOV wrote: Here's the problem: Company has several branches, connected over VPN and a centr al Exchange server. Because of the slow connections to the internet and large nu mber of branches/users email is increadibly slow especially during morning hours . I was wondering if somebody have any ideas how altq could be used allocate bandw idth for email in this scenario. I can split the bandwidth for branches based on subnet addresses, but this will not separate exchange related trafic from, let' s say http or file transfer. Does anyone know which ports are used by Exchange or have any other ideas on thi s. A quick search revealed these two MSKB articles: http://support.microsoft.com/?kbid=155831 http://support.microsoft.com/?kbid=176466 Summary: POP3 and IMAP4 clients are easy, static ports; Outlook clients are a problem, due to dynamic ports. Exchange can be set to use a specific range of ports, and you can have pf/altq use those. Is there any reason you can't just use the Exchange server's IP address? It would be simpler (and more accurate) than chasing dynamic ports.
Re: Transparent Proxy Help
On Sunday, Jul 6, 2003, at 07:55 US/Pacific, Elijah Savage wrote: When I try to use a rdr on the $int_if nothing works is this possible with squid on the same internal network as the pf internal interface? If Not that easily. See http://www.openbsd.org/faq/pf/rdr.html#reflect
Re: state insert failed: tree_ext_gwy
On Wednesday, Jul 2, 2003, at 14:35 US/Pacific, Daniel Williams wrote: Trevor Talbot wrote: On Tuesday, Jul 1, 2003, at 23:53 US/Pacific, Daniel Hartmeier wrote: On Tue, Jul 01, 2003 at 09:22:02PM -0700, Daniel Williams wrote: /bsd: pf: state insert failed: tree_ext_gwy lan: 192.168.1.250:43445 gwy: #externalIP#:47566 ext: #externalHOST#:8080 There was a bug in the proxy port selection code in 3.3-release which resulted in proxy ports not making use of the entire range and potentially re-using an already used proxy port, which then results in the error message you quoted. Can you update to -stable (or -current) and retry? -stable doesn't have Ryan McBride's byte order fixes: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/ pf.c.diff?r1=1.361r2=1.362 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/ pfvar.h.diff?r1=1.154r2=1.155 http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/ parse.y.diff?r1=1.389r2=1.390 http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/ pfctl_parser.c.diff?r1=1.161r2=1.162 Still seeing the errors after recompiling the kernel(-stable) with nmbclusters 8192. I'm not so sure I want to go -current on this machine...I am leaning towards building a 3.2 -stable machine. Thoughts? Even with the 4 additional patches? Perhaps this is another problem. As far as 3.2 goes, if you don't need any of the 3.3 pf additions, sure.
Re: Only one PF table for all connections?
Probably not the best time to bring this up, but... On Thursday, Jul 3, 2003, at 13:37 US/Pacific, Henning Brauer wrote: [ on the NATLOOK ioctl ] changing anything like that becomes less and less acceptable. pf is widely deployed nowadays, and there are more 3rd party apps using the interfaces than we know of. compatibility becomes a major issue. If it's time to go ahead with something like this, it might not be a bad idea to go farther and break everything at once. Two changes I'd like to see: - Much more abstraction. Currently most of the ioctl interface is tied directly to the kernel structures, which are less than fun to work with. pf_ioctl.c has to specifically NULLify pointers for example, in case userland touches them. (Speaking of which, DIOCADDSTATE is trouble in -current -- it violates the rule.ptr assumptions). Figuring out how to use the interface is hard as well, since the structures have all this kernel data, and one has to dig through it all to figure out what needs to be filled in and what doesn't. Storing things like anchor, queue and tag names in the kernel on a per-rule basis is kind of silly. Right now it makes sense, but it's still silly, since the kernel uses the faster redundant forms anyway (pointer, id). Using a completely different structure for the ioctl interface would take care of most of this. It would also insulate some kernel changes from userland, such as additions to pf_state that only have meaning to the kernel. - Better error reporting. Witness the recent messages involving DIOCADDALTQ: Invalid argument. Even if it's just an addition to ioctl-specific structs, having pf(4) report something more specific like too many queues would be a help. I'd be willing to do some of the work if it's wanted.
Re: state insert failed: tree_ext_gwy
On Tuesday, Jul 1, 2003, at 23:53 US/Pacific, Daniel Hartmeier wrote: On Tue, Jul 01, 2003 at 09:22:02PM -0700, Daniel Williams wrote: /bsd: pf: state insert failed: tree_ext_gwy lan: 192.168.1.250:43445 gwy: #externalIP#:47566 ext: #externalHOST#:8080 There was a bug in the proxy port selection code in 3.3-release which resulted in proxy ports not making use of the entire range and potentially re-using an already used proxy port, which then results in the error message you quoted. Can you update to -stable (or -current) and retry? -stable doesn't have Ryan McBride's byte order fixes: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/ pf.c.diff?r1=1.361r2=1.362 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/ pfvar.h.diff?r1=1.154r2=1.155 http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/ parse.y.diff?r1=1.389r2=1.390 http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/ pfctl_parser.c.diff?r1=1.161r2=1.162
Re: What am I doing wrong, queuing
On Wednesday, Jul 2, 2003, at 03:08 US/Pacific, Richard P. Matthews wrote: queue std_ext bandwidth 128Kb priority 3 cbq(default borrow) queue game_ext_misc priority 2 cbq(default) It's probably complaining about this. Only one queue can be the default (it's used for all packets not assigned to a queue in the filter rules). You can see for sure by using: pfctl -vAf /etc/pf.conf
Re: RTSP
On Wednesday, Jul 2, 2003, at 10:53 US/Pacific, Morten Norby Larsen wrote: we have a three-legged firewall (internal, external, dmz) which seems to block/somehow kill RTSP connections (or, more correctly, the RTP part of an RTSP connection) from the internal network to the outer world. I have not been able to get a simple description of RTSP/RTP, but it is my understanding that all connections initiate with the client, and that there is no issue with server-initiated connections as there is with ftp. Am I missing something here? (wrong place, to ask, I know) RTP typically uses UDP streams, from the server to the client. The listening ports are chosen by the client during RTSP setup. My question is therefore whether there is some specific issue with pf's NAT implementation or if there is some blatant problem with the following (admittedly amateurish) configuration: No issues specific to pf. RTSP has problems with any setup where inbound traffic is filtered. Since you're doing NAT, I'd try to find a reasonable proxy. rtsp.org should point to some, and apparently Apple's Darwin Streaming Server can also function as a proxy.
Re: What am I doing wrong, queuing
On Wednesday, Jul 2, 2003, at 13:47 US/Pacific, Richard P. Matthews wrote: Actually I was attempting to setup subqueueing under game_ext. There are two queues under there game_ext_www and game_ext_misc. I am attempting to make game_ext_misc the default subqueue in the game_ext queue. That's the thing -- the default is used only for packets pf doesn't assign to a queue (any queue). If you have two defaults, and a packet travels through the filter rules without hitting a queue foo option, which one should be used? You'll have to explicitly assign packets to game_ext_misc. The default doesn't need to be in a specific place (such as the root level); it just needs to exist. -Original Message- From: Trevor Talbot [mailto:[EMAIL PROTECTED] On Wednesday, Jul 2, 2003, at 03:08 US/Pacific, Richard P. Matthews wrote: queue std_ext bandwidth 128Kb priority 3 cbq(default borrow) queue game_ext_misc priority 2 cbq(default) It's probably complaining about this. Only one queue can be the default (it's used for all packets not assigned to a queue in the filter rules). You can see for sure by using: pfctl -vAf /etc/pf.conf
Re: Maximum amount of ALTQL/PF rules?
On Tuesday, Jul 1, 2003, at 00:32 US/Pacific, Philip Olsson wrote: We want to bandwidth limit a subnet with cbq. So I need 2 queues and 2 rules per IP to limit the users speed. I Have changed MAX_CBQ_CLASSES to 1024 but that didnt help. When I try to load the rules I get pfctl: socket: Too many open files This problem in pfctl has been fixed in -current: http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/ pfctl_altq.c.diff?r1=1.72r2=1.73
Re: hfsc vs. cbq
I haven't tested any of this, but from what I understand... On Saturday, Jun 28, 2003, at 00:23 US/Pacific, jared r r spiegel wrote: does this imply that with hfsc, bandwith must be distributed among all child queues such that the total bandwidth among them at that level of the tree cannot exceed 100%? The sum of the children's service curves cannot exceed the parent's SC. i know that sounds like stupid easy math, but then what manner of linkshare/realtime/ upperlimit options could i impose upon those child queues such that if queues q2, q3 and q4 were not receiving packets, q1 could receive up to 100% of the interface bandwidth? as in, on a four client lan, the queues are assigned to machines 192.168.1.1 - 192.168.1.4 ; let's say the machine running pf is 192.168.1.100... if 192.168.1.1 is downloading from 192.168.1.100, and the other hosts on the lan are inactive, can hfsc be setup to allow 192.168.1.1 to receive all of the 100Mb bandwidth of the altq declaration; but if all four hosts are downloading equally from the 192.168.1.100, the bandwidth would be split fairly among them? Setting the bandwidth on each queue to 25% should do that. HFSC isn't documented real well, but the bandwidth option is used to set the linkshare curve. That curve is used as a weight for bandwidth distribution, not as a hard limit. So a 25% linkshare for each should distribute available bandwidth equally among those wanting it. The hfsc(upperlimit) option would do hard bandwidth limiting.
Re: Limit Bandwidth
I wrote:
On Wednesday, Jun 25, 2003, at 02:21 US/Pacific, Ganbaa wrote:
I'm trying to do. I installed OpenBSD 3.3 and configured pf on the
our LAN.
OpenBSD box has 2 network cards (Internal and External). The purpose
is
testing to limit bandwidth for each hosts on the LAN. LAN has more
than 30
hosts. I divided into several groups those hosts. Example: developers,
marketing, servicing e.g
The problem is all traffic is going only one default queue (std queue
) on
the external interface. I attached pf.conf file and debug message. So
Could
The issue is the use of NAT on the external interface:
nat on $ext_if from $internal_net to any - ($ext_if)
Translation happens before filtering, so by the time the packet gets to
pass out on $ext_if from { developers } to any keep state queue
developers_ex
the source address has already been changed from developers to
($ext_if).
The setup already uses queues on the internal interface, so tagging for
external queues can't happen there.
There's another possibility I missed: name the queues the same. Instead
of developers_in and developers_ex, just have both be developers.
That way you can do everything with filter rules on $int_if, and not
worry about $ext_if.
Re: Limit Bandwidth
[ Dual response, Ganbaa sent me details in private. ]
On Wednesday, Jun 25, 2003, at 02:21 US/Pacific, Ganbaa wrote:
I'm trying to do. I installed OpenBSD 3.3 and configured pf on the our
LAN.
OpenBSD box has 2 network cards (Internal and External). The purpose is
testing to limit bandwidth for each hosts on the LAN. LAN has more
than 30
hosts. I divided into several groups those hosts. Example: developers,
marketing, servicing e.g
The problem is all traffic is going only one default queue (std queue
) on
the external interface. I attached pf.conf file and debug message. So
Could
The issue is the use of NAT on the external interface:
nat on $ext_if from $internal_net to any - ($ext_if)
Translation happens before filtering, so by the time the packet gets to
pass out on $ext_if from { developers } to any keep state queue
developers_ex
the source address has already been changed from developers to
($ext_if).
The setup already uses queues on the internal interface, so tagging for
external queues can't happen there.
OpenBSD -current has a tagging feature that could be used here, if you
want to try that (keeping up with -current is a bit of work though, and
it's hard to justify in a production environment). It would look like:
pass in on $int_if from developers to any keep state queue
developers_in tag developers
pass out on $ext_if all keep state tagged developers queue
developers_ex
The only other workaround I can think of is broken in 3.3. It's also
fixed in -current, but hasn't been kicked back to -stable yet. The
idea is to use the source port range for decisions:
nat on $ext_if inet from developers to any - ($ext_if) port
45001:5
nat on $ext_if inet from servicing to any - ($ext_if) port
50001:55000
...
pass out on $ext_if proto { tcp, udp } from any port 4500050001 to
any queue developers_ex
Unfortunately it's useless for protocols other than TCP and UDP.
Anyone have suggestions I missed?
Re: throttling outgoing bandwidth
On Sunday, Jun 22, 2003, at 17:41 US/Pacific, Tony Faoro wrote:
altq on $ext_if cbq bandwidth 240Kb queue { std_out, audio }
queue std_out cbq(default)
queue audio bandwidth 135Kb cbq
CBQ works on the basis of limits, rather than guarantees. At the
least, you should add a priority to the audio queue, but if all
you want is for audio traffic to override everything else, priq
may be more appropriate than cbq.
Re: OpenBSD 3.3 pf gre problem
On Sunday, Jun 22, 2003, at 16:04 US/Pacific, Damian McGuckin wrote:
[ VPN stuff concerning 3.3's NAT with ESP/AH ]
However, from one of these sites, you can use RDP, i.e. Terminal
Services,
over the VPN cleanly. But from another, we cannot, i.e.
A - 3.1 using RDP over VPN - OK
A - 3.3 using RDP over VPN - OK
B - 3.1 using RDP over VPN - OK
B - 3.3 using RDP over VPN - FAILURE!!
But B can ping the W2K machine behind 3.3, and vica versa.
This the second posting I've seen about RDP over a VPN traveling
through a 3.3 box. Can you verify that it's actually using the
tunnel, and not somehow skipping around it? Or is there any unusal
traffic you notice from it?
Does anybody have any cute TCPDUMP commands on how I watch the VPN
traffic? I use effectively
Tunnel activity can be seen with basic tcpdumping on an interface:
tcpdump -nvi tun0
You could add a host one.vpn.endpoint.address at the end of that
to limit what it shows.
Traffic inside an ESP tunnel can't be viewed from anywhere but the
endpoints.
pass out log quick on $EXTERNALINTERFACE proto { udp, tcp, icmp } all
pass out log quick on $EXTERNALINTERFACE all
The packets pf passes will show up via tcpdump -eni pflog0
but they should be the same as what's going over the external
interface.
Enabling misc debugging for pf (pfctl -xm) and watching
/var/log/messages may be of use, but probably not. -xn to turn
it off.
Experimental queueing
I'm playing with pf/altq code for a project of mine, and some of it may
be of interest to people here. The diffs are for -current only.
http://homepage.mac.com/quension/pf/qexp0.diff
The first diff gives pf DiffServ and ECN awareness (IP level; TCP level
ECN is already present). The undocumented tos filter option is
removed and replaced with dscp, which matches the DiffServ codepoint
of the IPv4 TOS field and IPv6 TC field. TOS_LOWDELAY matching (ssh
interactive) is fixed for ECN-enabled sessions, and priority queueing
is enabled for IPv6.
dscp = dscp ( string | number [ / number ] )
For valid strings, read the diff, which maps strings to predefined
codepoint value/mask pairs. You can also specify the codepoint value
manually, with an optional mask. Default mask is 0x3f (all 6 bits).
The predefined value/mask pairs make up a weird mix of 2 obsolete
standards and 2 current standards.
http://homepage.mac.com/quension/pf/qexp1.diff
The second diff builds on the first by adding DiffServ-based queueing
that works within state. You define a dsqueue that maps various
DiffServ values to specific queues, then use that dsqueue in a rule.
This change relegates the priority queues to handling TCP ACKs only;
dsqueue mappings replace the old internal TOS_LOWDELAY match.
The pfctl changes in this diff are somewhat cobbled together: the syntax
isn't great, pfctl doesn't watch for duplicate dsqueue definitions
(kernel merges) or dscp mappings (kernel uses first), doesn't echo
dsqueue definitions in verbose mode, displays no debug information, etc.
The intent was to get only basic functionality, as my own project
doesn't require pfctl.
For an example, I'll just dump the configuration I did basic testing
with:
[ Side note: HFSC would be better suited to this level of traffic ]
[ management, but I'm having a surprising amount of difficulty in ]
[ wrapping my head around HFSC theory, and so far pfctl doesn't ]
[ like what I'm feeding it. I haven't yet decided if pfctl is]
[ yelling at me for good reason ;)]
# Queue theory:
# standard default for non-testing traffic
# explicit root for testing traffic, capped at 50mbit/s
# TCP ACKs at high priority, 10% bandwidth cap
# tos-lowdelay (ssh interactive) packets at next-highest priority,
# 20% bandwidth assignment, free to use excess bandwidth
# tos-throughput (ssh file) packets at low priority, 50% bandwidth
# assignment, option to use excess bandwidth, and a larger queue
# to avoid drops
altq on $int_if cbq queue { f_def, t_def }
queue f_def cbq( default )
queue t_def bandwidth 50Mb { t_l4sq, t_lowdelay, t_throughput }
queue t_l4sq priority 7 bandwidth 10%
queue t_lowdelay priority 6 bandwidth 20% cbq(borrow)
queue t_throughput qlimit 100 bandwidth 50% priority 2 cbq(borrow)
# DiffServ Queue map theory:
# tos-lowdelay to a separate queue, bundle TCP ACKs with it, since
#they aren't critical to maintaining incoming datastream
#(assumption is burst-patterned traffic, not sustained)
# tos-throughput to a separate queue, but put TCP ACKs in a priority
#queue to maintain incoming streams
dsqueue test { \
dscp tos-lowdelay queue t_lowdelay, \
dscp tos-throughput queue(t_throughput, t_l4sq) \
}
# Rule queue theory:
# default to explicit test root queue, with TCP ACKs in the priority
#queue (assuming mostly sustained streams, rather than bursts)
# use dsqueue mappings when appropriate
pass out on $int_if from 192.168.0.1 to 192.168.0.50 keep state \
queue(t_def, t_l4sq) dsqueue test
Re: ESP protocol and Transparent bridge w/ PF
On Friday, Jun 20, 2003, at 06:59 US/Pacific, David Chubb wrote: However to connect to a remote RDP (Remote Desktop Client) connection I have to disable the Packet filter before it will allow the connection to go through. The remote site looks at the logs and it shows the incoming connection (via TCP) but the connection it builds back (via the ESP protocol) dies before it gets back to the client machine. If I disable packet filtering it will connect fine. As far as I know, RDP doesn't touch ESP on its own; is the remote site configured with a mandatory IPsec policy or something? Something like that. The remote site is a mortgage company that we are doing remote software testing for. We connect through to a Cisco VPN server, then start the Remote Desktop Client. VPN connects fine and I can do other things (like get webpages, SSH into other machines, etc.) But the RDP connections still don't connect. Here is what I have opened for the connection. (Some of the ports are for other VPN clients.) My real question is that if the connection for RDP is tunneled through Cisco VPN software why is PF seeing the packets at all? Or is PF strong enough to peek inside encrypted packets? All pf should see is ESP between the tunnel endpoints in that case. If it's seeing other traffic, then the tunnel is broken (or at least not being used for that traffic).
Re: Linux virtual server competition
On Friday, Jun 20, 2003, at 10:07 US/Pacific, Stefan Sonnenberg-Carstens wrote: I think you would not have to blow up the pf code itself too much. Simply put, take a look at the packet in ip_input.c. Look, if it should be destinated to some of your real server. Calculate the next real server to give to packet to based on some infos (connections, load, etc). Create a (temporary) pf-nat rule. Actually, if you're going to dig in there, you might as well do it within pf itself. That way you get a few things for free, including pf's classification code. Simple round-robin is already there; extending it to WRR looks fairly straightforward. A couple other useful mechanisms are present, source-hash and random, but they currently only apply to single CIDR blocks. You could extend them to handle lists, like RR. Least-connection would probably be similar to WRR. There are people maintaining ports of pf for the other BSDs, so it needn't be a total waste of effort as far as portability goes...
Re: Queing on ADSL ACK's
On Thursday, Jun 19, 2003, at 06:30 US/Pacific, Elijah Savage wrote: I tried to setup queing based on the faq and website. But I just can't get it to work. Downloading is great but as soon as I start to upload my speed drops way down to about the same speed as the upload. I have played around with the queue statements and bandwidth settings but no luck. I am on adsl link of 1.5down/768 up, using different ftp sites to test throughput it seems I get about 1330down/605up. Maybe I have my rules out of place or something I am at a lost. Use pfctl -vvsq and watch the packet counts, to make sure traffic is actually ending up in the right queues. pass in on $ext_if inet proto tcp from any to $ext_if port $tcp_services flags S/SA keep state This rule should be marked queue(q_def, q_pri). pass in on $ext_if proto tcp from any to $ext_if flags S/SA keep state queue (q_def, q_pri) You probably don't want this one, since you have the more-selective rule above.
Re: ESP protocol and Transparent bridge w/ PF
On Monday, Jun 16, 2003, at 13:16 US/Pacific, David Chubb wrote: I have set net.inet.esp.enable=1 in the sysctl.conf (and rebooted to make sure the changes took). This is just to enable support on the box itself. It doesn't affect packet passing. However to connect to a remote RDP (Remote Desktop Client) connection I have to disable the Packet filter before it will allow the connection to go through. The remote site looks at the logs and it shows the incoming connection (via TCP) but the connection it builds back (via the ESP protocol) dies before it gets back to the client machine. If I disable packet filtering it will connect fine. As far as I know, RDP doesn't touch ESP on its own; is the remote site configured with a mandatory IPsec policy or something? I did add the following rules to the pf.conf and reloaded them, however they do no good. pass out on $ext proto esp from $ournet to any pass in on $ext proto esp from any to any That should be all you need as far as ESP goes. If IPsec is negotiating with IKE, you'll need UDP port 500 open as well. Make sure your block rules are using the log option, and run tcpdump -eni pflog0 That'll show you what's being blocked and by what rule.
Re: Queing on ADSL ACK's
On Thursday, Jun 19, 2003, at 17:14 US/Pacific, David Le Corfec wrote: On Thursday 19 June 2003 23:21, Trevor Talbot wrote: pass in on $ext_if proto tcp from any to $ext_if flags S/SA keep state queue (q_def, q_pri) You probably don't want this one, since you have the more-selective rule above. Isn't it just unneeded to add queuing rules for inbound packets anyway ? Note that queueing is only useful for packets in the /outbound/ direction. (http://openbsd.org/faq/pf/queueing.html) keep state will cause packets to be tagged even when they're going in the opposite direction (outbound) -- in this case, the primary concern is TCP ACKs.
Re: Source-hash limitations for multiple servers on a subnet
On Thursday, Jun 12, 2003, at 22:48 US/Pacific, Roland Chan wrote: As I understand the source hash option, it will redirect the packet to one of a set of IPs based on a hash of the source address. This is dandy in a 'sticky load balancing' situation, when you have a power of two number of servers, and they are all running. However, if I had 4 destination IPs 1.2.3.8 1.2.3.9 1.2.3.10 1.2.3.11 and I was load balancing across the set as 1.2.3.8/30, what could I do if 1.2.3.9 was no longer available? As I understand it, all I could do would be to load balance across 1.2.3.10/31 at best? Correct; source-hash is limited to a single CIDR block. This seems a bit limiting. Would it not be more appropriate to use the source address to work out which of the listed IP address (after expanding CIDR notation) should be chosen? That way no memory of the previous choice would be required. Admittedly, if the number of destinations in the rule changed, connections would be routed differently, but that would seem to be the case anyway. I'm not sure what you're thinking of in this case. Source-hash has no IP memory as it is; that's one of its strong points. A hash of the source address is created, then masked according to the CIDR boundary to get the redirection address. The same key is used for each hash, hence the sticky behavior. It sounds like you want this extended in syntax similar to round-robin: accepting lists of addresses (possibly in CIDR format) to map to. Is this correct?
Re: pf rdr on requests originating from firewall box itself
On Saturday, Jun 14, 2003, at 13:52 US/Pacific, Michael Purcaro wrote: I've been using OpenBSD 3.3 release with great success to do redirection from external and internal IPs to internal IPs. I've been using TCP proxying as noted in the FAQ. The only thing I haven't been able to figure out is how to correctly redirect requests from the firewall box ITSELF. i.e., while working on the firewall box, # telnet my.domain.name 80 Trying a.b.c.d... Telnet can never connect. Doing the same thing on a computer in the internal network works fine. Of course, using the internal IP also works perfectly. I have played a bit with additional rdr rules in pf.conf, but I haven't found the right one yet. I guess it is an issue with my pf.conf rules and the way things are ordered on the TCP stack (and the interface being used)? Any hints would be greatly appreciated! :) Yes, this can get a bit complicated. There's a flow diagram at http://mniam.net/pf/pf.png Since routing is handled mainly by the usual kernel processing, it's already too late for that when it's heading out on an interface. But, if all you want is that domain name to work, why not just add an entry to /etc/hosts on the box?
Re: altq vs pppoe
On Tuesday, Jun 10, 2003, at 05:07 US/Pacific, Tobias Wigand wrote: same here, works great with a saturated link. i can upload with full speed and it doesn´t slow down my downloads at all! Great! okay, surfing around while uploading is slower than normal, but thats something we have to live with, right? The outgoing connection setup and page requests have to compete with your uploads. You could experiment with a rule that puts everything out to tcp port 80 in a priority queue. Just don't do any HTTP uploads :)
altq vs pppoe
Here's the story on pf/altq with ppp/pppoe.
Good traffic discipline requires fine-grained control, which means
getting
as close to the wire as possible. Otherwise, lots of buffering tends to
get in the way. For ALTQ, the external interface is the best place to
set
up on, hence the recommendations for queueing on the ethernet interface
instead of tun0.
Queue tagging must happen on tun0, since IP is only visible there. Once
past tun0, it gets wrapped in PPPoE headers, so pf can't decode it on
the
ethernet interface.
Unfortunately, the only option on OpenBSD appears to be userland ppp
with
pppoe. As tun0 is an interface to userland, the kernel packet tags get
lost as soon as the packet gets pulled off by ppp. ppp feeds it to
pppoe,
which wraps it and puts it back on the ethernet interface.
Modifications
to get the tags through userland would probably break more things than
they would fix. So, as things stand now, queueing on the external
interface is impossible, since the queue tags can't get there.
Kernel PPPoE would be much better.
That leaves queueing on tun0, which seems to be troublesome. As Primo
Gabrijeli commented:
If I activate this with 4 download clients (totaling approx 40 KB/s)
and 4
upload clients (totaling approx 18 KB/s) - IOW in unsaturated
conditions -
the pppoe %CPU rockets skyhigh. Minimal value is 23% but I have
observed
values as high as 75%. If pppoe CPU percentage rises too high (don't
know
exact figures here), the download and upload speed starts to drop.
I did some playing around and discovered something. It seems that
someone
forgot to fully ALTQify tun0. Specifically, select() always returns
read-
ready if there's any data in the internal queue, whether ALTQ's
discipline
is ready to release it or not.
The theory is that when the queues start filling, ppp's non-blocking I/O
loop starts spinning on tun0, trying to pull packets off when they
aren't
ready. Once it starts spinning, pppoe will be adversely affected and
lose throughput.
As I don't have a PPPoE setup to work with, I did my own testing with
just
tun0, and saw the spin effect. Below is a patch for if_tun.c, which
fixed
the problem I observed. I'd like to know if it fixes pppoe queueing for
anyone brave enough to try patches from me. I've been known to make
things
explode.
--- sys/net/if_tun.cTue Jan 7 01:00:34 2003
+++ sys/net/if_tun.cFri Jun 6 23:03:25 2003
@@ -433,6 +433,7 @@
int unit, s;
struct tun_softc *tp;
struct tuninfo *tunp;
+ struct mbuf *m;
if ((unit = minor(dev)) = ntun)
return (ENXIO);
@@ -494,8 +495,9 @@
tp-tun_flags = ~TUN_ASYNC;
break;
case FIONREAD:
- if (tp-tun_if.if_snd.ifq_head)
- *(int *)data = tp-tun_if.if_snd.ifq_head-m_pkthdr.len;
+ IFQ_POLL(tp-tun_if.if_snd, m);
+ if (m)
+ *(int *)data = m-m_pkthdr.len;
else
*(int *)data = 0;
break;
@@ -731,6 +733,7 @@
int unit, s;
struct tun_softc *tp;
struct ifnet*ifp;
+ struct mbuf *m;
if ((unit = minor(dev)) = ntun)
return (ENXIO);
@@ -742,7 +745,8 @@
switch (rw) {
case FREAD:
- if (ifp-if_snd.ifq_len 0) {
+ IFQ_POLL(ifp-if_snd, m);
+ if (m != NULL) {
splx(s);
TUNDEBUG((%s: tunselect q=%d\n, ifp-if_xname,
ifp-if_snd.ifq_len));
Re: Was: No buffer space available
On Thursday, Jun 5, 2003, at 03:14 US/Pacific, Uwe Dippel wrote: Fresh install of 3.3 along FAQ, first reboot, nothing but bringing up PPPoE: ifconfig up xl0 route -n flush ppp -ddial pppoe You' re right, it disconnects, but how ! When I remove the phone cable: nothing happens, route stays, tun0 - config remains, pfctl remains. To a 'down' interface. Only after I reconnect the cable will ADSL-modem start to negotiate for a new address; still at the 'old' route; the PF at the 'old' (tun0), because it's still configured. After (!!) negociation of a new identity (IP) will the tunnel device be reconfigured, followed by PF and route. The 'clean' approach is doubtless: ppp detects link down, takes out the route and deconfigures; followed by PF removing the NAT address. A re-negotiation for a new identity *must* only start after tearing down the previous states; followed logically by (re-)configuring the tunnel device (IP), adding the new route and adopting the new IP in PF. No 'overlap' of former and current states, ids, configuration must be permitted. Any undefined state is an invitation to exploits. Personally, I perceive dead routes lying around as very annoying. So my previous comment about ppp handling linkdown is off base. It sounds as though either ppp or pppoe isn't handling linkdown the way you expect. I don't have a way to test that here. As far as previous state/dead routes go, it depends on the situation. If nothing is actually being sent out (and it shouldn't be, until pppoe renegotiates and starts encapsulating traffic again), then it is actually in-line with typical network behavior. If you have a static default route to a typical ethernet interface, and the cable is unplugged, nothing happens to that route. The packets just don't go anywhere until you plug the cable back in. To keep this on topic, what exactly are you seeing pf do in this case? Is it working correctly after re-negotiation? How are you checking pf's status? NAT-ing and routing to an IP that by then might belong to someone else is nothing I'd expect to see in OpenBSD. I wouldn't expect that either. But unless it's actually doing that, and not just dropping the packets, it's not an issue. OTOH, there should be feedback of some kind to the clients, such as ICMP dest-unreach messages, while the link is down. That would be handled by the kernel's normal forwarding process. If that isn't happening, then I tend to agree that there's something wrong with ppp/pppoe. pf itself should be working as expected based on the feedback it gets from the rest of the system.
Re: Loading Blance in OpenBSD 3.3 with pf
On Thursday, Jun 5, 2003, at 07:22 US/Pacific, ghost wrote: Now, My ICQ Client and Ftp client seems work fine. Glad to hear it. But,My ftp client can use two ADSL to download files. If I can do something that I can download files with two ADSL both at the same time? Not from the same site. But, there's another approach you could try for different sites. route add 0.0.0.0 -netmask 0.0.0.1 gateway1.ip route add 0.0.0.1 -netmask 0.0.0.1 gateway2.ip Then see how things work. In theory, this should load balance based on whether the dest address is odd or even. This should let you use both lines for different sites. To undo it, use those same commands but with delete instead of add. Note that if you look at the routing table with route or netstat, the entries won't make sense, because of how netstat and route try to interpret it. It's only cosmetic; the routes are actually there. If that works for FTP, you could use the same address-binding principle for other traffic by removing the route-to statements, if you want to. If the other applications handle the route-to rules as-is, it's probably better to keep using them, since they're more likely to balance than kernel routes are. ICQ may or may not work correctly. If it doesn't, use a route-to rule for it again.
