Re: double NOT in rules is not working as expected
On Fri, Apr 08, 2011 at 01:19:59PM +0300, Bojidara Marinchovska wrote:
Hello,
netif=netif
test1=1.2.3.4
test2=2.3.4.5
block in quick on $netif from {!$test1, !$test2} to x.x.x.x - blocks
the access from the IPs from test1 and test2 macros, BUT it should
block all other EXCEPT this ones
--
block in quick on $netif from {$test1, $test2} to x.x.x.x - this
rule works as expected
--
block in quick on $netif from {!$test1, $test2} to x.x.x.x - this
rule works as expected
This is complex for
block in quick on $netif from {!$test1} to x.x.x.x
--
block in quick on $netif from {$test1, !$test2} to x.x.x.x - this
rule works as expected
This is again complex for
block in quick on $netif from {!$test2} to x.x.x.x
I know example rule :
block in quick on $netif from {!$test1, !$test2} to x.x.x.x
can be replaced with:
pass in quick on $netif from {$test1, $test2} to x.x.x.x
block in quick on $netif from any to x.x.x.x
This is wrong. It is expanded to:
block in quick on $netif from {!$test1} to x.x.x.x
block in quick on $netif from {!$test2} to x.x.x.x
and this is just a simple
block in quick on $netif to x.x.x.x
The {foo, bar} notation results in a OR operation so
foo || bar. Now !foo || !bar with foo != bar is always true.
In the example I used macors, also tried with tables or direct
inserting IP addresses instead of using macros or tables, but it
does not work as expected
So it is possible to use {$test, $test1}, but isn't double
negation as following: {!$test1, !$test2} ?
--
:wq Claudio
Re: PF ruleset stymying my PPPoE testing, or am I just confused?
On Thu, Dec 30, 2010 at 09:48:52PM -0800, Jonathan Rogers wrote: Trying to set up a new telco fiber connection on my OpenBSD router/ firewall (this is an OLD box with OpenBSD 3.8 on it...sorry). I can't put the new telco connection live as the default yet, because it will affect all users, and I need to do some testing first. But I'm not quite sure I (a) understand if I've got PPPoE set up correctly, or (b) if I do but my existing pf firewall rules are affecting the test. In any case, I can't get it to work. pppoe0: flags=8850POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492 dev: xl2 state: session sid: 0xa2e9 PADI retries: 1 PADR retries: 0 time: 00:00:27 groups: pppoe inet 215.34.235.30 -- 0.0.0.1 netmask 0x Your pppoe0 is not functional. It did not correctly negotiate a session and is not UP. Did you check with ifconfig pppoe0 debug that the IPCP phase of ppp was successful? Normaly 0.0.0.1 should be changed to the real destination IP when the connection is established also the interface should be UP-ed by pppoe(4). There were quite a few fixes in pppoe(4) and sppp(4) over the last 5 years. -- :wq Claudio
Re: pf corrupting packet checksums?
On Wed, Dec 29, 2010 at 10:40:58AM +, Stuart Henderson wrote: On 2010/12/29 08:51, Johan Helsingius wrote: Running pf on openbsd 4.8 (i386), I find something very strange going on. Looking at the log: Dec 28 22:23:37.772604 rule 4/(match) [uid 0, pid 28161] pass in on xl2: xxx.yyy.zzz.aaa.51717 foo.bar.www: S [tcp sum ok] 3754046362:3754046362(0) win 4095 mss 1200 (DF) (ttl 64, id 23285, len 44) Dec 28 22:23:37.772690 rule 17/(match) [uid 0, pid 28161] pass out on rl0: xxx.yyy.zzz.aaa.51717 foo.bar.www: S [tcp sum ok] 3754046362:3754046362(0) win 4095 mss 1200 (DF) (ttl 63, id 23285, len 44, bad cksum 7c0b! differs by 100) So the packet is OK going into the firewall, but has a bad checksum going out? Julf You are probably offloading checksums to the NIC hardware. If so, it is normal that tcpdump does this. This is because of delayed checksum calculation in ip_output. Between the two pf_test() calls ip_forward() decrements the TTL but does not fix the cksum. pf log call on outbound rules will almost always report bad checksums, ip_output() will calculate the checksum a bit later unless HW support is available. -- :wq Claudio
Re: pf protection against spoofed [source addr] packets
On Wed, Oct 20, 2010 at 04:50:49AM +0300, Nerius Landys wrote: I then tried to use nemesis to change the spoofed source address from 64.156.193.115 to 127.0.0.1 or 192.168.0.x, but nemesis wasn't able to do this with the error message ERROR: Incomplete packet injection. Only wrote -1 bytes. Sorry my mistake. I _was_ able to spoof a source address such as 192.168.0.1, but _not_ 127.0.0.1. Wondering why; I'd like to see how my service reacts when I send a UDP packet with a spoofed source address of 127.0.0.1, but don't know how to do it. At least on OpenBSD the network stack has logic that never allows 127.0.0.1 to appear on the wire and IIRC they are not accepted as well. You need to use bpf(4) to inject such packets. -- :wq Claudio
Re: New pf install on Freebsd seem to be a slow starter.
On Wed, Jul 09, 2008 at 07:25:18PM +0200, Leslie Jensen wrote:
Hello
When I boot the machine where pf is installed, every thing I can see looks
ok. It's hard to read the text scrolling on the screen and the information
concerning pf is not to be found in /var/log/messages.
Anyway I have one PC on the inside and it takes some time before it's able
to reach the outside world.
I can speed up the process by making a change to pf.conf and then use the
command pfctl -f /etc/pf.conf.
Another thing I see is that for example I add log (all) to one of my
filters and do pfctl -f /etc/pf.conf, then later I remove it again and do
pfctl -f /etc/pf.conf. The output from tcpdump -n -e -ttt -i pflog0 still
shows packages as if it had not refreshed and still have the log (all)
active.
I know my problems is a little bit unclear but I hope someone will help my
solving this behaviour in the right way.
# macros
int_if=xl0
ext_if=bfe0
tcp_services={ 22 }
tcp_priv_services={ 389, 443 }
icmp_types=echoreq
# tables
table goodguys { something.somewhere.com, somethingelse.somewhere.com,
xxx.yyy.zzz.qqq }
While loading the pf ruleset pf needs to resolve these domains. This will
not work in some cases and may cause long delays.
# options
set block-policy return
set loginterface $ext_if
set skip on lo0
# scrub
scrub in
# ext_if IP address could be dynamic, hence ($ext_if)
nat on $ext_if from !($ext_if) to any - ($ext_if)
# filter rules
block in log (all) on $ext_if
pass out keep state
# Let the goodguys access the machine from the outside
pass in on $ext_if inet proto tcp from goodguys to ($ext_if) \
port $tcp_services flags S/SA keep state
# ICMP traffic needs to be passed:
pass inet proto icmp all icmp-type $icmp_types keep state
# traffic must be passed to and from the internal network
pass in quick on $int_if
--
:wq Claudio
Re: arpresolve: can't allocate llinfo
On Tue, Feb 27, 2007 at 04:37:27PM -0600, Travis H. wrote: I am not sure if this is pf-related, but has anyone seen this error message, and what condition actually causes it? Incomplete arp table? Out of memory? Something else? Something else normaly. Most probably trying to attach a arp entry to a non clonable route. -- :wq Claudio
Re: PF Table Size - Sanity Check
On Tue, Nov 07, 2006 at 08:28:00PM +0100, Daniel Hartmeier wrote: On Tue, Nov 07, 2006 at 06:08:52PM +, Paul Pruett wrote: A nominal i386 computer with only a meg of ram without limit changes would not load it. Neither would a stock GENERIC kernel on any architecture. The reason is that those 600+MB of table entries are allocated from kernel memory. And the kernel only gets a fraction of the physical RAM installed. You'll have to try, but I doubt you'll end up with more than half a gig of kernel memory even if you put in 4+GB of RAM. And, no, I don't know if it's possible to tune that or how ;) The opposite is obviously true, i.e. if you have less than 600MB of physical RAM, there is no way you can load 600+MB of table entries. Actually adding more RAM to a box may reduce the ammount of memory usable to pf. This comes from the fact that the kernel has a fixed virtual memory size but adding more RAM increases the static allocations (page table, buffer cache, etc.). So in the end you have suddenly less memory left. .. and no I don't know where the break even is. -- :wq Claudio
Re: OpenBGPD PF
On Thu, Jan 05, 2006 at 06:46:54AM -0500, jared r r spiegel wrote: On Thu, Jan 05, 2006 at 03:18:22AM +0100, Sylwester S. Biernacki wrote: On Thursday, January 5, 2006, at 01:15:00, jared r r spiegel wrote: - establish session with A and learn about 1.2.3.4/30; 1.2.3.4/30 is written to pftable IX - establish session with B and learn about 1.2.3.4/30; 1.2.3.4/30 is written to pftable IX, but it's already there, who cares; or maybe it isn't written because it's already there either way, pftable IX still has 1.2.3.4/30 in it. In both cases above no prefixes shouldn't deleted from pftable IX nod was just additions up to that point - A loses its route for 1.2.3.4/30 and thus you lose it out of the session. with A, bgpd removes 1.2.3.4/30 from pftable IX it's still valid via B, but it got removed when A lost it. It may be - however command to remove prefix from pftable comes from bgpd not pf, right ? i think so; pftable.c (bgpd) has ioctl functions that seem to be named such that they imply they do just what i think they would G. bgpd has (should have?) enough info from its config to know if it should send an addr_remove (i think this is the one) to pf based upon what addr it is thinking about removing, what table it is removing it from, and whether another peer who writes to that table has already put that addr in the same pftable - but the actual behaviour might be hard to get Just Right. The main problem with the using one pftable over mutliple sessions is that bgpd does not track what is added or removed. The idea is to dump all prefixes of a neighbor into one table. In the end the pf table and the routes of that neighbor are in sync. If you are using multiple neighbors as source for a table it is easy to get out of sync. What I'm wondering is why to use a pftable in that case. It is far easier to use a route label and let pf decide on the route label. The route label tracks the current active routes and so never gets out of sync. Instead of pass in from IX ... you can use pass in from route IX and use something like in bgpd.conf match from group IX set rtlabel IX -- :wq Claudio
Re: pf pauses in sending traffic
On Tue, Sep 14, 2004 at 12:51:26PM +0200, Marco Matarazzo wrote: Hi Matthew, I've the same problem here with 3.4 (and had the same problem with 3.3). The 'hole' in communication is always just 20 seconds. In the beginning I thought about a Spanning Tree issue, but after careful inspection, everything seems fine. Also tried to swap switches, network cards (all fxp tough) etc. The same things also happen with pf disabled, and happen only on the trunk interface, the management interface is fine. Tried a netstat -w 1, and in those 20 seconds, traffic arrives at fxp0, but not a single packet exits. The server just quits routing on the trunk interface, and all vlans. At the time that happend, I simply didn't have the time to troubleshoot it (since I began noticing it when VoIP customers came in... and that REALLY disrupts VoIP!), and now have an old Cisco that routes that. But the question still remains... The only other thing running at the time was Zebra with full bgp tables (and it was before the explosion of the tables that rendered the old kernels unusable with full bgp peer). I can try to reproduce the problems if it helps the community! I think you got hit by a fxp bug that was fixed after 3.5. The problem was that somehow the fxp card did no longer generate an interrupt and so the watchdog timer reseted the card after 20 seconds. This only happened on havily loaded links (many interrupts). -- :wq Claudio
Re: a trick
On Wed, Mar 10, 2004 at 06:43:33PM +1100, Damien Miller wrote: On Tue, 9 Mar 2004, Claudio Jeker wrote: The best sollution is to have a full view (with no default route) via bgp and use no-route. So you get a auto-update bogon filter. It is more accurate than those lists because it is live and knows about the not announced but IANA allocated blocks. How does that help? Abusers use BGP to advertise reachability to those blocks in the first place, so they are in the routing table. And, BGP doesn't include WHOIS information to determine a given block's allocation status. If abusers use BGP to advertise reachability your in big trouble because then your list wont help you neither. If you can advertise a non allocated block you can also advertise a allocated but not announced block. There are many companies that own public IP blocks but don't announce then. -- :wq Claudio
Re: a trick
On Tue, Mar 09, 2004 at 09:15:11AM -0800, Brian Keefer wrote: On Tue, 2004-03-09 at 07:06, Todd T. Fries wrote: Not when you're working on a system that is being attacked with packets with source ip's in the list. In my opinion anyway. Well, as long as you're using anti-spoof packets can't bounce through to your internal network segments using your own address space, so that's the most important part... filtering out bogons is really just to cut down on chaff a little bit. Henning is right, though: unless you're updating regularly it's a Bad Thing(tm) because IANA can and does allocate those IPs (last time was in January). Team Cymru specifically updates their list often, which is why I wrote my script (it will remove IPs from my bogon table if they've been allocated). The best sollution is to have a full view (with no default route) via bgp and use no-route. So you get a auto-update bogon filter. It is more accurate than those lists because it is live and knows about the not announced but IANA allocated blocks. I know not everybody has a bgp session running on the firewall. -- :wq Claudio
skip states and tables
Hi all, is there a known problem with skip states and tables in 3.3-stable? I have multiple rules of the form: pass in on fxp1 from any to table_a keep state queue a pass in on fxp1 from any to table_b keep state queue b pass in on fxp1 from any to table_c keep state queue c pass in on fxp1 from any to table_d keep state queue d after some debugging with pfctl -g -vv -s r it seams that the frist rule skips all others. For my system the current behaviour is quite a show stopper. I'm running 3.3-stable as from around June 13 on i386. If more info is needed I can provied it. -- :wq Claudio
Re: Linux virtual server competition
On Fri, Jun 20, 2003 at 06:53:08PM +0200, Stefan Sonnenberg-Carstens wrote: Hi list, I'm sure anyone here knows about the linux virtual server (layer 4 load-balancer). I searched the web for an equivalent for *bsd, but found none. The only thing which looks like something like a load-balancer is the FreeBSD loadd, which requires packets to copied from kernel-space to user-space and vice versa. I know that OpenBSD/pf has some abilities for load-balancing ip packets. I'd like to know if it goes beyond the round-robin stuff (e.g. schedulars for least-connection,weighted round-robin), or if just does that. I've played arround with load-balancers (F5 BigIP,local director) and would like to write one for *BSD's, if there is a demand for that (and to get my hand dirty on code again). Would it be a good idea to integrate it into a packet-filter (like the lvs) or implement it as a stand-alone solution ? IMHO the best way to implement that would be to have a load-balancing statement which diverts the initial packet to a userland app. The userland app adds then a correct state in the pf state table and from that point all packets will be automaticaly forwarded via the state table. The user app needs to be smart enough to recognize packages that belong to the same stream. Diversion of packets without a state could be quite useful form many problems that need more handling but are not so simple that a rdr and proxy can solve it. There are also a lot of trapdoors and pitfalls that need cautious planning and a clean implementation. This is on my cool stuff that I would do if I had time list since quite a time. -- :wq Claudio
