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=8850 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 (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 (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 { 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 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 > > > - establish session with B and learn about 1.2.3.4/30; 1.2.3.4/30 is > > > written to pftable , but it's already there, who cares; or maybe > > > it isn't written because it's already there > > > > > either way, pftable still has 1.2.3.4/30 in it. > > In both cases > > above no prefixes shouldn't deleted from pftable > > 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 > > > 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 . > > 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 ... 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: Asymmetric gigabit speeds / OpenBSD 3.7 PF
On Thu, Jun 16, 2005 at 04:57:19PM +0200, Frederic BRET wrote: > I was not sure where to send this question, to an OpenBSD list or to the > PF list. I'm trying to understand why our OpenBSD PF router is not able > to cope correctly with needed gigabit speeds, and perhaps one of you > already encoutered this with his PF > > I have two Dell 1750 single-Xeon 2.8GHz. The first is our production > router still under OpenBSD 3.4 beta with PF since 2 years, and the > second one is a fresh OpenBSD 3.7 under Generic stock kernel. The > ultimate goal beeing to build a CARP dual router with the 2 machines. > > The problem is that none of the 2 machines is able to route at speed > higher than ~350mbit/s, even without PF which could slow things, what I > doubt of. > > In order to validate the capacity of the server to cope with > simultaneous up/down gigabitstreams, I've done several tests > > - First, validate the external test machine and the network. > Here is a simultaneous (-d) iperf TCP test between 2 Sun V40Z (SLES9 > with Broadcom 5703). Between them, there's a HP Procurve 2824 Gigabit > switch with full-duplex enabled and properly negotiated on all ports : > ROOT:Linux:/opt/iperf2/bin > ./iperf -i 1 -c address> -d -w 256k > ./.. > [ 4] 0.0-10.0 sec 1.01 GBytes864 Mbits/sec > [ 5] 0.0-10.0 sec 1.01 GBytes865 Mbits/sec > => The network AND the V40Z are capable of symetric quasi full-duplex > gigabit. OK > > - This beeing said, I'll try to do the same thing between a V40Z and a > DELL 1750 (OpenBSD 3.7 with Broadcom 5704) > First lets do a non-simultaneous (-r) TCP test between the V40Z and a 1750 > ROOT:Linux:/opt/iperf2/bin > ./iperf -i 1 -c address> -r -w 256k > ./.. > [ 4] 0.0-10.0 sec 1.09 GBytes935 Mbits/sec > [ 4] 0.0-10.0 sec 1.09 GBytes938 Mbits/sec > => More than 1GB are transfered in 10s in one way then in the other. > Unidirectionnal bandwidth of 1Gbits/s is almost respected, no problem. > > - Now lets try simultaneously (-d) between the V40Z and the DELL 1750 > like the first iperf test between the 2 linux boxes : > ROOT:Linux:/opt/iperf2/bin > ./iperf -i 1 -c address> -d -w 256k > ./.. > [ 4] 0.0-10.0 sec403 MBytes338 Mbits/sec > [ 5] 0.0-10.0 sec 1.02 GBytes876 Mbits/sec > => The Openbsd box isn't able to receive more the ~330Mbits/s every time > I tried when it's at the same time speeking through the wire. It's a > constant comportment. > This sound like the fameous hlt hlt problem. I think a fix went into 3.7-stable or else try -current to see if this helps. -- :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 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
Re: syn-proxy & application-level-proxy
On Thu, Sep 11, 2003 at 07:37:44PM +0200, Ed White wrote: > On Thursday 11 September 2003 16:22, Daniel Hartmeier wrote: > > Oh, the dreaded payload inspection / passing to userland for inspection > > topic. This is basically unrelated to syn proxying, of course you can > > combine both once you have both. But sneaking it through syn-proxy is > > unlogical ;) > > The fact is that syn-proxy manages already two tcp connections. > I think you missunderstood something. syn-proxy is not a real proxy as in ftp-proxy. The syn-proxy is nothing more than some state table magic so the synproxy state option does not add any overhead. You can compare synproxy with a modulate state rule, with the only difference that the first syn to the server will be delayed. > > 2) application level filtering > > how can syn-proxy talk to a userland program, maybe sharing a buffer ? > This could be done with a rdr and a pass rule. Something like: rdr on $extif proto tcp from any to any port $service -> 127.0.0.1 port $proxy and pass in on lo0 proto tcp from any to 127.0.0.1 port $proxy synproxy state should do the job. What I'm currently pondering is if the syn/ack sent by the synproxy rule will be correctly translated. That's something to either test or ask a pf guru. > > Any idea to solve these 2 problems ? > IMHO there are no problems just missunderstandings. As already said synproxy is just a "keep state" on steroids. -- :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 keep state queue a pass in on fxp1 from any to keep state queue b pass in on fxp1 from any to keep state queue c pass in on fxp1 from any to 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
tabels and label macros
Hi all, out of curiosity I tried a rule like: pass in from any to keep state label out_$dstaddr which results in this funny output: out_97.108.108.111/0 290089 453609 54227731 It is clear that $dstaddr/$srcaddr can only be used on non table rules so pfctl should bark on rule loading. -- :wq Claudio
Re: M$ FTP through PF
On Tue, Jun 17, 2003 at 06:09:36PM -0600, Glamdring wrote:
> I have been fighting with getting FTP to work through PF without success
> (yet). As I have been perusing this mail list I see many having the
> same problem I am having, the FTP server is a separate machine, behind
> the PF box and for reasons unknown to us is running M$ ftp. In digging
> around on the M$ site I came across this article,
> http://support.microsoft.com/default.aspx?scid=kb;en-us;283679 which
> among other things says M$ FTP by default handles passive and active FTP
> depending on what the client asks for. I think a little catch for using
> M$ FTP might be this paragraph...
>
> NOTE: In Windows NT 4.0 and Windows 2000, the valid default ephemeral
> port range is 1024-5000. Increasing the ephemeral range in Windows NT
> 4.0 and Windows 2000 requires adding a value to the system registry.
> (put the registry editor down and step away from the computer)
>
> I haven't got around to figuring out how this fits into the overall
> scheme of things but maybe this will help someone.
>
> I'm off to continue fighting with my problem, I'll be asking for help if
> I get to the "I only have 1 hair left" point.
>
> Thanks for the great feedback on this list.
>
It is unclear if you are using NAT or not.
I have a running setup without NAT and it works.
What I did:
pass in on $ext_if proto tcp from any to $ftp port { ftp ftp-data } flags S/SA keep
state
# I use OpenBSD ftp server so the port range is 49152 to 65535
pass out on $ext_if proto tcp from $ftp port 49151 >< 65536 to any flags S/SA keep
state
# or just (I use this version becaus the ftp server runs on my workstation)
pass out on $ext_if proto tcp from $ftp to any flags S/SA keep state
# don't forget to pass the traffic on $int_if
If you use NAT ftp-proxy is needed (never used ftp-proxy in this
direction).
--
:wq Claudio
