Re: Hardware for Access Point on OpenBSD
On Thu, 2 Jan 2020 at 14:04, Stuart Henderson wrote: > > On 2020-01-01, List wrote: > > Hi *, > > I am currently building a home router based upon OpenBSD. > > I therefore need some kind of WIFI Hardware. This piece of hardware > > needs to be connected over usb. > > Do you have any suggestions or recommendations ? As far as I can see > > it's pretty hard to find an antenna which is connected via USB an runs > > on a supported chipset. It is easy to get your hands on a > > realtek-chipset driven device. But urtw(4) doesn't support Host AP > > mode. Only ones that do are: athn(4), ral(4), ath(4). > > Finding those is hard. > > > > Maybe you guys know things I couldn't find ? > > bwfm(4) also supports hostap on USB devices and probably has the > least-worst performance of devices that will attach directly to > OpenBSD rather than as a separate "hardware" AP. > > These are Broadcom "fullmac" devices. IIRC there's a list of actual > devices using these somewhere on wikidevi.com but the site is > currently down so I can't check. The old "official raspberry pi > usb wifi" devices work, there should be some others (they're often > the only devices that work wifi dongles for some smart TVs that don't > have built-in wifi). wikidevi.com was shut down 2019/10/31. My understanding is that the operator(s) provided a db dump to archive.org: https://archive.org/details/wikidevi It appears the data is "living on" on techinfodepot: http://en.techinfodepot.shoutwiki.com/wiki/Main_Page
Re: KNFectomy
On 18 November 2015 at 22:45, Adam Wolk wrote: > On Wed, 18 Nov 2015 11:38:55 -0700 (MST) > Theo de Raadt wrote: > >> >Adam Wolk wrote: >> >> During the LibreSSL early days there were frequent KNFectomy >> >> procedures executed by jsing@. Is the KNFectomy utensil script >> >> available publicly? ;) man -k knf yields only style(9). >> > >> >indent -ci4 -di1 -nlp $1 >> > >> >That's not what joel used, but it's what i have in ~/bin/knf. It >> >usually gets things close enough for some further refinement. > > I'm afraid of tools that redirect me to rcs(1) KEYWORD SUBSTITUTION > documentation in order to be able to decipher their flags :P Though I > do appreciate the info, might be desperate enough on some occasions to > try it out - who am I kidding, I will try it :) > >> >> Until indent -- having come out of the back of a cow -- subtly screws >> your source code and makes a mistake. >> >> Be careful. >> > > Thanks for the heads up. I just had a few occasions lately that I had > to incorporate some broken formatted C code into a project and was > searching for a 'general pass make my eyes not bleed' like tool. > > Regards, > Adam > Hello, You may have better luck with clang-format : http://clang.llvm.org/docs/ClangFormat.html The Linux Kernel Style looks fairly close to KNF, so it can serve as a base configuration (it's all the way down in the examples section) : http://clang.llvm.org/docs/ClangFormatStyleOptions.html Marios
Re: Making IPv6 NAT prefer privacy address
On 23 September 2015 at 15:34, Giancarlo Razzolini wrote: > Em 23-09-2015 04:40, Stuart Henderson escreveu: >> Saves messing about with DHCPv6-PD > > I see. So you translate from what exactly? Wouldn't it be better to use > af-to instead of nat? Hello, Rather than announcing the prefix obtained via DHCPv6-PD you can pick a prefix from fd00::/8 and announce that on your network. It is the equivalent to RFC1918 addresses, except it is for IPv6. Therefore, it is not routable and you need to perform NAT on it. The global address is the one the router obtained via static configuration/SLAAC/DHCPv6, which will then be used by all your clients. > But I can relate to that, given that my CPE will > give me a PD, but won't route packets back because it thinks the prefix > is reachable using NDP. Hence the need for a proxy, which OpenBSD > currently doesn't have. > > Cheers, > Giancarlo Razzolini > Your CPE will see only the OpenBSD router's address so it should work. Marios
Re: Lenovo T450s status
On 16 June 2015 at 14:53, Alex wrote: > On 05/28/2015 01:48 AM, Shaun Reiger wrote: >> Hello Misc I'm looking at purchasing a Lenovo T450s as my main laptop, but >> I wanted to find out if anyone has hit any major roadblocks using obsd 5.7 >> with this model. I know this is a fairly new machine and support is always >> hit and miss, but any guidance on this machine would help. >> >> Biggest concerns are battery life and fan noise. >> >> >> Thanks. >> >> > > Hi Shaun, > > I've just got a Lenovo T450s and tried to install OpenBSD 5.7. > > Early during the installation (while typing the hostname) I had a > strange keyboard behaviour: pressing once "f" lead me to a second of > freeze and then as if I've inputed "f" about ten times. > This should have been fixed : http://marc.info/?l=openbsd-tech&m=142608672523246&w=2 > I've continued the installation and later - during the network > configuration questions - I pressed once which led to the same > behaviour as previously. What happened is that the "superflous" > did answer the default for the next questions, in particular the disk > setup which use the whole disk for OpenBSD. This led to the whole hard > drive being formatted. > > I had only a fresh debian installed so no harm here, but if you try to > install OpenBSD on T450s I would highly recommend you to backup your disk. > > FYI I've used /OpenBSD/5.7/amd64/install57.fs on an USB key. I should > have let the install finish and send a dmesg before reinstalling the > debian back but I've thought about it too late. If someone need a dmesg > or other infos I might try again with the hard drive unplugged this > time, let me know. > > Maybe the installer should have a confirmation question before the disk > partitionning / formatting with a default answer of "no" ? > > Regards, > Alex.
Re: BGP - IP Blackhole
On 18 April 2014 16:29, Tristan PILAT wrote: > 2014-04-18 10:23 GMT+02:00 Tristan PILAT : > > > 2014-04-17 19:27 GMT+02:00 Tristan Pilat : > > > >> > >> > >> On 17 avril 2014 19:02:14 CEST, Claudio Jeker > > >> wrote: > >> >You can't use rtlabels for matching the source, at least I think it > >> >does > >> >not work. I would try to use the "set pftable dos" in bgpd and > >> >"block quick drop from " in pf. > >> > >> Ok i will try this tomorrow thanks. But if it does not work. How can I > >> set up blockhole based on source address as described in RFC5635 with > >> OpenBSD ? > >> -- > >> Tristan > >> > > > > Me again. > > > > This slide from a presentation by Henning Brauer is very interesting... > > http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00031.html > > > > i'm keep digging :-) > > -- > > Tristan > > > > Thanks Claudio, I just tested it and it works with "set pftable dos" in > bgpd.conf and "block drop quick from " in pf.conf but there still a > small thing. In my lab i tried this, sending icmp, and it works only if i > stop the ping command and i relaunch it. I mean, if i'm pinging an IP > address and set the "bgpctl network add..." it don't hang ping. > > How can I stop the flow immediatly with PF ? > > Sounds like your traffic is matching an existing state which is why it's still passing. Look at pfctl manpage, and more specifically the -k switch. Marios > -- > Tristan
Re: where are translated web-pages?
On 18 April 2014 00:18, Alex Naumov wrote: > Thank you for link, but... why? I mean, we are not going to continue work > on translation anymore? Reason? > > This was also discussed : http://marc.info/?l=openbsd-misc&m=139653486420745&w=2 The translation was open sourced also, so nothing stops you from maintaining your translated FAQ. It just won't be published as "canonical" documentation. > > On Fri, Apr 18, 2014 at 12:14 AM, Johan Beisser wrote: > > > http://marc.info/?l=openbsd-cvs&m=139637003025491&w=2 > > > > You did. > > > > On Thu, Apr 17, 2014 at 3:08 PM, Alex Naumov wrote: > > > Hello, > > > > > > I just want to ask about "not English" (translated) pages. I can't find > > > these. > > > Also translation.html and steelix are not avaliable. > > > Did I missed something? > > > > > > Thank you, > > > Alex
Re: ipv6 static routing
On 8 December 2013 17:54, dikshie wrote: > On Mon, Dec 9, 2013 at 1:38 AM, Marios Makassikis > wrote: >> Is PF enabled ? If so, perhaps your current rules are IPv4 only. >> Can you ping6 from this host ? > > pf is disable. > > > # ndp -a > Neighbor Linklayer Address Netif ExpireS > Flags > 2001:d30:101:624::64 0:16:3e:65:2b:b vio1 permanent R > fe80::216:3eff:fe1b:ac9c%vio00:16:3e:1b:ac:9cvio0 permanent R > fe80::216:3eff:fe65:2b0b%vio10:16:3e:65:2b:b vio1 permanent R > fe80::21b:2aff:fee2:a4c0%vio1(incomplete)vio1 expired N > fe80::1%lo0 (incomplete) lo0 permanent R > # > > > # route -n show -inet6 |grep vio1 > defaultfe80::21b:2aff:fee2:a4c0%vio1 UGS > 00 - 8 vio1 > 2001:d30:101:624::/64 link#2 UC > 10 - 4 vio1 > 2001:d30:101:624::100:1b:2a:e2:a4:c0 UHLc > 04 - 4 vio1 > fe80::%vio1/64 link#2 UC > 10 - 4 vio1 > fe80::216:3eff:fe65:2b0b%vio1 00:16:3e:65:2b:0b UHL > 00 - 4 lo0 > fe80::21b:2aff:fee2:a4c0%vio1 00:1b:2a:e2:a4:c0 UHLc > 19 - 4 vio1 > ff01::%vio1/32 link#2 UC > 00 - 4 vio1 > ff02::%vio1/32 link#2 UC > 10 - 4 vio1 > ff02::1:ffe2:a4c0%vio1 link#2 UHLc > 00 - 4 vio1 > > ping6 to gateway's link local is fine. > # ping6 fe80::21b:2aff:fee2:a4c0%vio1 > PING6(56=40+8+8 bytes) fe80::216:3eff:fe65:2b0b%vio1 --> > fe80::21b:2aff:fee2:a4c0%vio1 > 16 bytes from fe80::21b:2aff:fee2:a4c0%vio1, icmp_seq=0 hlim=64 time=1.811 ms > 16 bytes from fe80::21b:2aff:fee2:a4c0%vio1, icmp_seq=1 hlim=64 time=0.912 ms > 16 bytes from fe80::21b:2aff:fee2:a4c0%vio1, icmp_seq=2 hlim=64 time=0.948 ms > 16 bytes from fe80::21b:2aff:fee2:a4c0%vio1, icmp_seq=3 hlim=64 time=0.883 ms > 16 bytes from fe80::21b:2aff:fee2:a4c0%vio1, icmp_seq=4 hlim=64 time=0.938 ms > ^C > --- fe80::21b:2aff:fee2:a4c0%vio1 ping6 statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 0.883/1.098/1.811/0.357 ms > > # ping6 2001:D30:101:624::1 > PING6(56=40+8+8 bytes) 2001:d30:101:624::64 --> 2001:d30:101:624::1 > ^C > --- 2001:D30:101:624::1 ping6 statistics --- > 4 packets transmitted, 0 packets received, 100.0% packet loss ^^^ You can ping6 the gateway, but not a global IPv6 address. It looks like you have IPv6 connectivity problem, and not routing/forwarding (i.e.: your gateway or some other router further upstream is misconfigured).
Re: ipv6 static routing
Is PF enabled ? If so, perhaps your current rules are IPv4 only. Can you ping6 from this host ? On 8 December 2013 17:00, dikshie wrote: > On Sun, Dec 8, 2013 at 10:14 PM, Marios Makassikis > wrote: >> Your /etc/mygate file can look like this : >> >> # cat /etc/mygate >> 202.249.25.1 >> FE80::21B:2AFF:FEE2:A4C0%vio1 >> Make sure you have net.inet6.ip6.forwarding=1 in /etc/sysctl.conf > > same result with previous one. > > # ndp -a > Neighbor Linklayer Address Netif ExpireS > Flags > 2001:d30:101:624::64 0:16:3e:65:2b:b vio1 permanent R > fe80::216:3eff:fe1b:ac9c%vio00:16:3e:1b:ac:9cvio0 permanent R > fe80::216:3eff:fe65:2b0b%vio10:16:3e:65:2b:b vio1 permanent R > fe80::21b:2aff:fee2:a4c0%vio10:1b:2a:e2:a4:c0vio1 23h58m10s S R > fe80::1%lo0 (incomplete) lo0 permanent R > > # sysctl -a |grep forward > net.inet.ip.forwarding=1 > net.inet.ip.mforwarding=0 > net.inet6.ip6.forwarding=1 > net.inet6.ip6.mforwarding=0 > > # route -n show -inet6 > Routing tables > Internet6: > DestinationGateway > Flags Refs Use Mtu Prio Iface > ::/104 ::1UGRS > 00 - 8 lo0 > ::/96 ::1UGRS > 00 - 8 lo0 > defaultfe80::21b:2aff:fee2:a4c0%vio1 UGS > 02 - 8 vio1 > ::1::1UH > 140 33144 4 lo0 > ::127.0.0.0/104::1UGRS > 00 - 8 lo0 > ::224.0.0.0/100::1UGRS > 00 - 8 lo0 > ::255.0.0.0/104::1UGRS > 00 - 8 lo0 > :::0.0.0.0/96 ::1UGRS > 00 - 8 lo0 > 2001:d30:101:624::/64 link#2 UC > 00 - 4 vio1 > > # ifconfig vio0 > vio0: flags=8843 mtu 1500 > lladdr 00:16:3e:1b:ac:9c > priority: 0 > groups: egress > media: Ethernet autoselect > status: active > inet 202.249.25.29 netmask 0xffe0 broadcast 202.249.25.31 > inet6 fe80::216:3eff:fe1b:ac9c%vio0 prefixlen 64 scopeid 0x1 > > # ifconfig vio1 > vio1: flags=8843 mtu 1500 > lladdr 00:16:3e:65:2b:0b > priority: 0 > groups: egress > media: Ethernet autoselect > status: active > inet6 2001:d30:101:624::64 prefixlen 64 > inet6 fe80::216:3eff:fe65:2b0b%vio1 prefixlen 64 scopeid 0x2 > > # traceroute6 -n www.google.com > traceroute6 to www.google.com (2404:6800:4001:c01::6a) from > 2001:d30:101:624::64, 64 hops max, 12 byte packets > 1 * * * > 2 * * * > ^C > # > > thanks!
Re: ipv6 static routing
Your /etc/mygate file can look like this : # cat /etc/mygate 202.249.25.1 FE80::21B:2AFF:FEE2:A4C0%vio1 Make sure you have net.inet6.ip6.forwarding=1 in /etc/sysctl.conf On 8 December 2013 09:59, dikshie wrote: > Hi, > I have an openbsd box with two interface. > > # cat /etc/hostname.vio0 > inet 202.249.25.29 255.255.255.224 > > # cat /etc/mygate > 202.249.25.1 > > # cat /etc/hostname.vio1 > inet6 2001:d30:101:624::64 64 > !route -n add -inet6 default FE80::21B:2AFF:FEE2:A4C0%vio1 > > > my goal: > ipv4 routing should go via interface vio0 with default gateway 202.249.25.1 > and ipv6 routing should go via interface vio1 with default gateway > FE80::21B:2AFF:FEE2:A4C0%vio1 > > while IPv4 is working fine, IPv6 does not work as expected. > > here's the IPv6 routing table > Internet6: > DestinationGateway > Flags Refs Use Mtu Prio Iface > ::/104 ::1UGRS > 00 - 8 lo0 > ::/96 ::1UGRS > 00 - 8 lo0 > defaultfe80::21b:2aff:fee2:a4c0%vio1 US > 0 75 - 8 vio1 > > > # ndp -a > Neighbor Linklayer Address Netif ExpireS > Flags > 2001:d30:101:624::64 0:16:3e:e3:6:de vio1 permanent R > fe80::216:3eff:fe5d:cb31%vio00:16:3e:5d:cb:31vio0 permanent R > fe80::216:3eff:fee3:6de%vio1 0:16:3e:e3:6:de vio1 permanent R > fe80::21b:2aff:fee2:a4c0%vio10:1b:2a:e2:a4:c0vio1 2sD R > fe80::1%lo0 (incomplete) lo0 permanent R > > > do I miss something here? > > thanks! > -- > -dikshie-
Re: Are there any default password managers in OpenBSD?
On 6 December 2013 12:29, Andres Perera wrote:
> On Fri, Dec 6, 2013 at 5:22 AM, Alexander Hall wrote:
>> On 12/06/13 07:50, Andres Perera wrote:
>>>
>>> On Fri, Dec 6, 2013 at 1:58 AM, Jan Stary wrote:
On Dec 05 19:09:05, andre...@zoho.com wrote:
>
> but then if the shell implementation uses tmpfiles for heredoc,
does it?
>>>
>>>
>>> ksh does:
>>>
>>> ~ $ :<>>>
$(sleep 100)
!
>>>
>>> [1] 469
>>> ~ $ ls /tmp/sh*
>>> /tmp/shsWf2OXAO
>>>
>>> src/bin/ksh/exec.c r1.50:
>>>
>>> /* Create temp file to hold content (done before newenv so temp
>>> * doesn't get removed too soon).
>>> */
>>> h = maketemp(ATEMP, TT_HEREDOC_EXP, &e->temps);
>>>
> and
> doesn't do the equivalent of rm -P, you have another leak you thought
> was taken care of
>
> conclusion: shell is not good for this
Yeah right.
Who would even think of doing this in shell.
>>>
>>>
>>> apparently at least one person did
>>>
>>> you aren't in sync with the quantity of real world shells that use
>>> temp files for heredoc, and who feature combinations of { printf
>>> (not)? being a builtin, alternatives like ``print'' and ``echo'' are
>>> unportable }
>>>
>>
>> You do point out some interesting apects. I've used the heredoc approach
>> without considering if my shell used tempfiles or not, but I'm usually
>> mostly concerned about stuff not going on the command line.
>>
>> However one decides for onself where to draw the line. There are probably
>> tons of leaks, even if you write your own code.
>>
>> X, xterm, vi, clipboard, ...
>
> yes, but this case is particularly insidious because i noticed that
> the original code went through the trouble of rm -P
>
> some people may have tmp as a memory backed fs and decide their uptime
> longevity is short enough, some people may have their entire fs's
> encrypted and decide that's enough
>
> that doesn't change the fact that modern password handling code
> doesn't transitively store cleartext secrets this way
>
> with C you can be very explicit about where you store and when you zero out
>
That does not mean this is going to happen though. Did you just
bzero() or memset()
a buffer where you had stored sensitive data ? It may not be enough. From the
compiler's point of view If you don't use the buffer afterwards, then
there is no to
call bzero() at all, so the call may be suppressed as part of optimisations.
> with shell it's easy to be clumsy in this particular domain
>
>>
>> /Alexander
>>
>>
> even if it keeps heredocs in memory you have no idea if it zeros it
> out afterwards
>
> On Thu, Dec 5, 2013 at 6:57 PM, Andres Perera wrote:
>>
>> On Thu, Dec 5, 2013 at 8:57 AM, Christian Weisgerber
>> wrote:
>>>
>>> Zé Loff wrote:
>>>
Not sure how advisable this is, but I'm using a gpg encrypted file,
which I keep somewhere hidden (just because). Just put them in file
foo and do 'gpg -e foo' (assuming you've already setup gpg). When you
need to look something up just do 'gpg -d foo' and the file gets
decrypted to stdout.
>>>
>>>
>>> *takes a deep breath*
>>>
>>> ~/bin/pwsafe
>>> --->
>>> #!/bin/sh
>>>
>>> SAFE=$HOME/.pwsafe
>>> TMPFILE=`mktemp /tmp/pwsafeXX` || exit 1
>>>
>>> trap 'rm -P "$TMPFILE"' 0 1 2 15
>>>
>>> STTY=`stty -g`
>>> echo -n "Password: "
>>> stty -echo
>>> read PASSWORD
>>> stty "$STTY"
>>>
>>> set -e
>>> echo -n "$PASSWORD" | openssl aes-256-cbc -d -in "$SAFE" -out
>>> "$TMPFILE" -pass stdin
>>
>>
>> this is tricky. some people will read and say ok i'll switch echo for
>> printf and get on w/my life
>>
>> printf not being a builtin, will show up in ps(1), and so will
>> $PASSWORD
>>
>> not apparent from the simple syntax used that such a change could end
>> up leaking important things
>>
>> it's better to use heredoc:
>>
>> openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE" -pass stdin <> $PASSWORD
>> !
>>
>>> ${EDITOR-${VISUAL-vi}} "$TMPFILE"
>>> echo -n "$PASSWORD" | openssl aes-256-cbc -in "$TMPFILE" -out "$SAFE"
>>> -pass stdin
>>> <---
>>>
>>> --
>>> Christian "naddy" Weisgerber
>>> na...@mips.inka.de
Re: VPN suggestions
On 12 November 2013 20:42, Kapetanakis Giannis wrote: > On 12/11/13 19:29, Daniel Polak wrote: >> >> Original message from Kapetanakis Giannis at 8-11-2013 13:38 >>> >>> I would like to discuss some suggestions about VPN to multiple road >>> warriors. >>> >>> So far we're using OpenVPN, but I want to change that or at maybe >>> offer L2TP/IPsec in addition to OpenVPN. >> >> Have you considered using isakmpd? > > > Yes my test implementation was with isakmpd and npppd. The problem is the > authentication on the ipsec path. > I don't want to use the same PSK for every-one. > > >>> Playing around with npppd was straight forward and I was quite >>> impressed with it. Good job. >>> EAP-TLS would also be a very nice feature to have. >>> >>> What I'm wondering is what you guys do to setup the ipsec path of the >>> tunnel. >>> >>> One option is to use a unique pre-shared key for all clients. But this >>> is probably insecure since >>> it opens MITM attacks. Isn't it? >>> >>> Best option would be is to use a PKI infrastructure for your clients. >>> Isn't that a pain in the ass for users (user registration, key >>> deliveries etc). >>> How do you guys manage this for best user experience and compatibility >>> with most OSes? >> >> PKI is a bit of a PITA but it is doable. You could use a PKCS#12 package >> to deliver the certificates to the client. >> >> Daniel >> > > Agree with you that PKI is a PITA especially for the users. > > I'm thinking a solution with either OpenCA or Dogtag where user would > ideally > login, generate and download their certificate... > > However the whole process is much more difficult for the end user than > New Connection -> Define Connection type -> Enter username/password -> done. > > IKEv2 looks promising but don't know if it's supported in something else > except windows 8. > I want to cover windows XP,7,Vista,8, MAC OSx (xxx) and varius flavors of > Linux + smart phones. > Win7 and OS X should be supported, as per Reyk Floeter's paper on OpenIKED: http://www.openbsd.org/papers/openiked-asiabsdcon2013.pdf Vista and XP probably need an external client to handle IKEv2. As far as Linux is concerned my guess you'll have to test a bunch of clients and it will depend on what is already being used to manage connections. For instance, NetworkManager can integrate with OpenVPN or Cisco VPN client to provide a GUI to manage the VPN connection. Marios > The only type that works in all these is PPTP but this suxxx a lot in terms > of security... > > G
Re: Blocking facebook.com: PF or squid?
On 19 October 2013 00:27, Stefan Wollny wrote: > > Hi there, > > having a personal dislike of Facebook (and the MeeToo-systems alike) > for their impertinent sniffing for private data I tried on my laptop to > block facebook.com via hosts-file. Interestingly this failed: Calling > "http://www.facebook.com"; always resulted in a lookup for > "httpS://www.facebook.com" and the respective site showed up in the > browser (tried firefox and xombrero). > > Well: Beside excepting the fact that those facebook engineers did a > fine job circumventing the entrys in /etc/hosts I felt immediatly > insecure: The reports on this company's attitude towards even > non-customers privacy are legendary. Their respective track record > earns them the honorable title of "NSA's fittest supporter"... > > Anyway: I think I finally managed to block all their IPs via PF and on > this laptop I now feel a little less 'observed'. [Yes, I know - this is > just today's snapshot of IPs!] > Did you block individual IPs or complete subnets ? Performing DNS resolution on facebook.com and fbcdn.net yields the 173.252.64.0/18 subnet. Blocking it is one additional PF rule or just updating a table of already blocked subnets / IPs. > My question is on the squid-server I have running at home: What > would make more sense - blocking facebook.com via pf.conf alike or are > there reasons to use squid's ACL instead? Performance? Being > ultra-paranoid and implementing both (or even additionally the > hosts-file-block?)? From my understanding squid should not be able to > block https-traffic as it is encrypted - or am I wrong here? > > Curious if there is a particular (Open)BSD solution or simply how you > 'guys and gals' would do it. Having squid running on your laptop just to block facebook is way overkill IMHO. Rather than populating (polluting?) your hosts file, I think using adsuck[1] would be simpler get you similar results, especially if you don't want to use an external service such as OpenDNS. It is available as a OpenBSD package, and it's easily configured to block more than just facebook. Marios [1] https://opensource.conformal.com/wiki/adsuck > > > Thank you for sharing your thoughts. > > Cheers, > STEFAN
Re: PHP 5.3.1 on OpenBSD 4.2
What is recommended is to upgrade to -stable. Then you can install php-5.3.27 / php-5.4.20 from ports or packages On 2 October 2013 13:52, Markus Rosjat wrote: > Hey there, > > I have a server that runs a OpenBSD 4.2 with a php of 5.2.3 and now I just > need some information if it's possible to switch to php 5.3.1 without > bigger problems or is it just not recommended? Some kind of help is most > appreciated. > > Regards > > Markus
Re: OpenBSD5.3/PF Settings help request
On 25 September 2013 16:40, Adelin Balou < adelin.ba...@etu.univ-valenciennes.fr> wrote: > Dear Sir/Madame, > > > I am a student in pending Master's degree in Network and Security at > University of Valenciennes (France), I am currently encountering problems > while setting up a Firewall with Packet Filter on OpenBSD 5.3. > > > I wall a PC with 3 network interfaces ( xl0 : connected to WAN , xl1 : > connected to WLAN , xl2 : connected to LAN ). I need that this PC works > like a > firewall. I have installed OpenBSD and setting up rules in /etc/pf.conf > (please to find attached to this mail my pf.conf file it is commented in > French, if any questions just let me know). > > > The problem is : The Firewall has Internet and hosts on WLAN and LAN can't > connect to internet. > I don't know if my NAT and Filtering rules are not > matching. Add the 'log' keyword to the rules you want to verify and run tcpdump on the pflog0 interface. When you're done, don't forget to remove the log keyword, or you might end up filling your disk with logs. Another way to see if it matches is to look at the counters for each rule when running pfctl -vvsr > My /etc/resolv.conf has an ADSL internet Box address and DNS is > working correctly. My xl0 interface has got IP from DHCP server from the > ADSL > Internet Box so no need to create a file /etc/mygate to specify the ADSL > Internet Box default gateway. The command route show shows me my default > gateway. > > > I have contacted http://www.evolix.fr/ one of the OpenBSD support link > http://www.openbsd.org/support.html in Marseille (France) they have read > the > file but they can't find the problem. I will be grateful if you could help > me. > > > Please find attached my pf.conf file. > > > I am looking forward to reading from you as soon as possible. > > > Kind regards, > > > > -- Adelin Balou > Etudiant en 2ème Année de Master Sécurité et Réseaux. > Institut des Sciences et Techniques de Valenciennes > Université de Valenciennes et du Hainaut-Cambrésis > Téléphone : +33 3 27 27 07 22 > Mobile : +33 6 17 46 10 72 > > [demime 1.01d removed an attachment of type application/octet-stream which > had a name of pf.conf]
Re: nut-2.7.1
On 29 July 2013 10:19, lilit-aibolit wrote: > Does someone have compiled i386 package for current nut? > https://github.com/networkupstools/nut > Or walkthrough how to build it on 5.3. > The reason for install development version it's added > Riello UPS support. > This is my step: > # git clone https://github.com/networkupstools/nut.git > # pkg_add python-3.2.3p0 autoconf-2.69p0 automake-1.13.1 > # ln -s /usr/local/bin/python3.2 /usr/local/bin/python > # cd nut > # ./autogen.sh > Regenerating Augeas ups.conf lens... > File "./gen-nutupsconf-aug.py", line 72 > print dirPrefix > ^ > SyntaxError: invalid syntax > Regenerating the USB helper files... > ./autogen.sh[31]: cd: /root/nut/scripts/augeas/tools - No such file or > directory > Calling autoreconf... > Provide an AUTOCONF_VERSION environment variable, please > # AUTOCONF_VERSION=2.69 ./autogen.sh > Regenerating Augeas ups.conf lens... > File "./gen-nutupsconf-aug.py", line 72 > print dirPrefix > ^ > SyntaxError: invalid syntax > Regenerating the USB helper files... > ./autogen.sh[31]: cd: /root/nut/scripts/augeas/tools - No such file or > directory > Calling autoreconf... > autoreconf-2.69: 'configure.ac' or 'configure.in' is required > Try running it with python2 instead of python3
Re: DF flag with af-to rule
On 6 July 2013 21:26, Pawel Jurusz wrote:
> Hello Marios
>
Hello Pawel,
> DF bit shouldn't be cleared, because it's necessary for PMTUD (Path MTU
> Discovery). There is also nothing amazing, that packets has DF flag set
> (it depends on operating system)
>
I'm aware of the utility of the DF bit. In my case, the original packet has no
fragmentation options (frag headers in IPv6's case), but the DF bit is added
by PF.
I'm assuming it's because of this part from RFC6145:
5.1. Translating IPv6 Headers into IPv4 Headers
[...]
Flags: The More Fragments flag is set to zero. The Don't Fragment
(DF) flag is set to one. In order to avoid black holes caused by
ICMPv4 filtering or non-[RFC2460]-compatible IPv6 hosts (a
workaround is discussed in Section 6), the translator MAY provide
a function as follows. If the packet size is greater than 88
bytes and less than or equal to 1280 bytes, it sets the DF flag to
zero; otherwise, it sets the DF flag to one. The translator
SHOULD provide a method for operators to enable or disable this
function.
The question now becomes "Does PF implement the 'SHOULD' part ?"
Perhaps the translated packets are directly leaving the interface without being
processed by PF any further ?
Marios
>> Hello misc@,
>>
>> I currently have a VM running as a NAT64 gateway.
>> It is running OpenBSD 5.3 with the vio stability patch.
>>
>> I have the following pf.conf:
>>
>> pass in inet6 proto { tcp, udp, icmp6 } from to
>> af-to inet from $ipv4_addr
>>
>> While this works fine in one environnment, the same VM
>> moved on a different host doesn't work properly.
>> Specifically, packets are matched by the rule, I can see them
>> leave the interface with tcpdump, but I never receive a response
>> from the remote host.
>>
>> While investigating the issue, I noticed that when sending a ping
>> from a host behind the NAT64 gateway, the IPv4 packet sent contains
>> the DF (don't fragment) flag.
>>
>> I am suspecting the host might be blackholing all packets having the
>> DF flag set,
>> which is why the translation won't work there.
>>
>> I have the two questions below:
>> - Is this behavior expected ? It affects all IPv4 packets created.
>> - Is there a way to clear the DF flag on the packet created by the af-to
>> rule ?
>>
>> I have tried adding the following rule after the pass :
>> match out scrub (no-df)
>>
>> But to no success. I added the 'log' keyword but it seems the match
>> rule is never matched.
>>
>> Thanks,
>>
>> Marios
DF flag with af-to rule
Hello misc@,
I currently have a VM running as a NAT64 gateway.
It is running OpenBSD 5.3 with the vio stability patch.
I have the following pf.conf:
pass in inet6 proto { tcp, udp, icmp6 } from to
af-to inet from $ipv4_addr
While this works fine in one environnment, the same VM
moved on a different host doesn't work properly.
Specifically, packets are matched by the rule, I can see them
leave the interface with tcpdump, but I never receive a response
from the remote host.
While investigating the issue, I noticed that when sending a ping
from a host behind the NAT64 gateway, the IPv4 packet sent contains
the DF (don't fragment) flag.
I am suspecting the host might be blackholing all packets having the
DF flag set,
which is why the translation won't work there.
I have the two questions below:
- Is this behavior expected ? It affects all IPv4 packets created.
- Is there a way to clear the DF flag on the packet created by the af-to rule ?
I have tried adding the following rule after the pass :
match out scrub (no-df)
But to no success. I added the 'log' keyword but it seems the match
rule is never matched.
Thanks,
Marios
Re: A tricky pf + ecmp routing + squid question [Disregard - SOLVED]
On 2 June 2013 21:33, Rob Sheldon wrote:
> On 2013-06-02 2:35, Loïc BLOT wrote:
>
>> Hello rob,
>> i'm using squid since 3.1 on OpenBSD 5.2 with compiled sources (squid
>> 3.2.5-9 and 3.3.4 at this time). I don't use an IP but the http_port
>> 3129 as my configuration suggests:
>>
>> http_port 3128
>> http_port 3129 intercept
>>
>> And i have those rule in my PF
>>
>> pass in quick proto tcp to { 10.X.1.1 10.X.1.2, 10.X.1.3 } port
>> { $squid_port $squid_intercept_port http }
>> pass in quick inet proto tcp from { }
>> to any port { 80 8080 } rdr-to 10.X.1.1 port $squid_intercept_port
>>
>> And all works perfect :). I haven't tested on 5.3 because the BCM5720
>> which are disabled on 5.2 are enabled and cause problem on my second
>> squid server... but i don't think this cause a problem.
>>
>
> As a forward proxy or a reverse proxy? There's no way a Squid 3.2+
> installation should work with rdr-to, unless:
>
> - the sources were modified to disable the security check described by
> Amos in http://www.squid-cache.org/**mail-archive/squid-users/**
>
201208/0374.html
> ;
>
> - or the destination IP of the requests matches the IP of the requested
> web server (reverse proxy, internal web server, or something).
>
> Amos spelled out the code change in 3.2+ in the mail post above. rdr-to
> rewrites the destination IP in the request. If Squid receives a request for
> a host (e.g. a get request for / on www.google.com), and the DNS lookup
> for the requested host does not match the destination IP of the request
> (e.g. the request was rdr-to'd 10.5.1.1), then Squid will refuse to forward
> the request to www.google.com.
>
> I can accept that maybe there's something going on that I still don't
> understand that's causing my particular configuration to require the
> listening IP in the http_port setting -- although I doubt it, I'm very very
> close to the configuration in the official Squid documentation at this
> point -- but I understand the rdr-to problem well enough now to assert that
> it won't work as intended except in a few specific cases.
>
>
Well you can use divert-to :
pass in quick on $int_if inet proto tcp from to any port www \
route-to lo0 divert-to 127.0.0.1 port 3128
pass out quick inet from divert-reply
These rules work fine on a transparent proxy configuration.
You can also ditch the route-to lo0 I think, although
it's needed if your proxy is setup as a bridge.
I should note that I haven't got around to a working configuration
for squid on a bridge - packets are forwarded fine, but replies never
make it back to the original host.
>
> - R.
>
> --
> [__ Robert Sheldon
> [__ No Problem
> [__ Information technology support and services
> [__ (530) 575-0278
Re: [obsd] Re: Assigning an IP address to a bridge
On 13 February 2013 20:28, Stuart Henderson wrote: > On 2013/02/12 16:54, Jeremie Le Hen wrote: > > Thanks again for your review. > > > > http://people.chchile.org/~jlh/tmp/faq6.html > > http://people.chchile.org/~jlh/tmp/faq6.diff > > This looks fine to me, thank you. Unless there are any objections > or other comments I will commit it soon. > > > One minor comment: you don't *need* to reboot. Although it's a good practice to reboot after you're done setting things up to make sure you don't have any ephemeral configurations (that you will obviously have forgotten about when you reboot for some other reason and find you something is not working as expected). Provided this is explained in 6.2.5, perhaps the 'Reboot and voilà' line should be removed ? On the other hand, the section right before the one Jeremie wrote also recommends a reboot, so it is consistent in that way. > > > Index: faq6.html > > === > > RCS file: /cvs/www/faq/faq6.html,v > > retrieving revision 1.304 > > diff -u -p -r1.304 faq6.html > > --- faq6.html 2 Nov 2012 11:25:12 - 1.304 > > +++ faq6.html 12 Feb 2013 15:52:19 - > > @@ -1295,7 +1295,7 @@ address, the bridge will pass network da > > maintainable (which can be a feature). > > > > > > -An example of a bridge application > > +A simple example of a bridge application > > > > > > One of my computer racks has a number of older systems, none of which > > @@ -1367,6 +1367,87 @@ directions. > > > > > > That's it! Reboot, and you now have a functioning bridge. > > + > > + > > +A bridge acting as a DHCP server > > + > > + > > +Let's say we have a Soekris net5501, which has four > > +http://www.openbsd.org/cgi-bin/man.cgi?query=vr&sektion=4 > ">vr(4) > > +interfaces, vr0 through vr3. We want to bridge vr1, vr2 and vr3 > > +together, leaving out vr0 for an uplink (a cable modem for instance). > > +We also want to serve IP addresses through DHCP over the bridged > > +interfaces. Being a DHCP server and an uplink router, the box needs to > > +have an IP address on the bridged network (contrary to the previous > > +example in which the bridging box was not visible on the network). > > + > > + > > +It is not possible to assign an IP address directly to a > > +http://www.openbsd.org/cgi-bin/man.cgi?query=bridge&sektion=4 > ">bridge(4) > > +interface. The IP address should be added to one of the member > > +interfaces, but we cannot use a physical interface as the link might be > > +down, in which case the address would not be reachable. Fortunately, > > +starting with OpenBSD 4.7, there is a virtual Ethernet interface driver > > +http://www.openbsd.org/cgi-bin/man.cgi?query=vether&sektion=4 > ">vether(4) > > +that can be used for that purpose. We will add it to the bridge, assign > > +the IP address to it and make dhcpd(8) listen there. > > + > > + > > +Notes: > > + > > + > > +The DHCP server configuration is not > > +described yet again in this section but the addressing scheme used here > is > > +the same. > > +This will also be the uplink router for your bridged network, so we > > +will use IP address 192.168.1.1 to match the DHCP server configuration. > > +We will not cover the uplink, routing or firewalling configuration > > +here. > > + > > + > > +First mark vr1, vr2 and vr3 as up: > > + > > + > > +$ cat /etc/hostname.vr1 > > +up > > +$ cat /etc/hostname.vr2 > > +up > > +$ cat /etc/hostname.vr3 > > +up > > + > > + > > + > > +Then create the vether0 configuration: > > + > > + > > +$ cat /etc/hostname.vether0 > > +inet 192.168.1.1 255.255.255.0 192.168.1.255 > > +up > > + > > + > > + > > +We configure the bridge interface to contain all the above > > +interfaces: > > + > > + > > +$ cat /etc/hostname.bridge0 > > +add vether0 > > +add vr1 > > +add vr2 > > +add vr3 > > +up > > + > > + > > + > > +And finally we make dhcpd(8) listen on the vether0 interface: > > + > > + > > +$ grep ^dhcpd_flags= /etc/rc.conf.local > > +dhcpd_flags="vether0" > > + > > + > > + > > +Reboot and voilà! > > > > > > Filtering on a bridge > > > > -- > > Jeremie Le Hen > > > > Scientists say the world is made up of Protons, Neutrons and Electrons. > > They forgot to mention Morons.
Re: serial over USB
On 2 January 2013 23:14, Jan Stary wrote: > On Jan 02 23:02:02, com...@daknet.org wrote: > > >Is anybody using an USB-to-serial connection to an ALIX? > > > > Yes i am. We have many Alix 2D13 boards that we use as routers > > running OpenBSD 5.2 on many sites. I use a USB-to-serial cable to > > configure them without problem but i've never used anything else > > than screen or minicom. You could try with these tools... > > screen is a multiplexing (text)window manager which you can > run on the remote machine once you are logged in. screen itself > does no remote connection, so I believe it's irrelevant here. > > Actually screen can also be used as a serial terminal. It's as easy as screen /dev/ttyS0 38400 (other options can be added after baud rate too) I haven;t used minicom yet - I use cu(1), and now am looking at tip(1). > But I don't think my problem is cu's or tip's problem. Also I would > like to stay in base. > > > The default baud rate on alix boards is 38400 but can be changed in > > cmos setup if you want (pressing S during memory test). > > I forgot whether 38400 was the default or I changed it to that, > but at any rate (ha, pun) that's what is working from any > (non-USB) serial port. > > So I speculate that my problem is with the ucom, > not with the connecting software tools above. > > Have you tried other USB ports ? What software/settings are you using to connect ? A quick Google search suggests both screen /dev/ttyUSB0 38400 and screen /dev/ttyUSB0 38400,cs8 should work.
Re: PF: block upd packets that allready have a state
On 25 June 2012 19:06, Matthias Cramer wrote: > Hi Marios > > On 25/06/12 18:50, Marios Makassikis wrote: >>>> I would consider having PF rate-limit connections to your SIP PBX, and >>>> add any host >>>> that goes over the limit to your badguys table. >>>> An example is described here: >> http://home.nuug.no/~peter/pf/en/bruteforce.html >>> >>> I saw this. But the problem is, the attacker allways comes with the same >> IP/Port Combo >>> so the is allways the same session for pf. So this method does not work! >> My understanding of this, is that the fact that PF creates a state, >> and uses it for the other >> communications with the attacker. Considering there is no other state >> created, it will never >> reach the limit to be added to the table. > > Exactly that's the case. > >> If that is the case, the question remains: how do you detect the >> attack ? Is the PBX rendered >> unusable for other clients ? > > Yes, It becomes more or less unusable... > In that case, the ALTQ trick is pointless. >> I think a more accurate description of the attack would be helpful to >> find a solution to the problem. > > I now have a script, which watches the PBX for unsuccessful authentication > and > adds the IP, if there are 10 unsuccessful tries in 5 seconds, via ssh to the > table on > the OpenBSD box, that solves all my problems greatly. > Seeing your solution ( glad you solved your problem by the way :) ), it looks like someone is bruteforcing your server. Which implies that the first step prior to attempting to authenticate is to establish a connection. I'm surprised PF doesn't catch it though. Even if the attacker is using the exact same packets, I recall reading that PF tracks connections by looking at source and destination transport addresses, but also ISNs. (Of course, you shouldn't take my word for it, as I couldn't find any source that backs this up.) In that case, it would mean your server is using weak ISNs and using modulate state instead of keep state would help mitigate the issue, as new states would be created for each connection and you can effectively do some rate limiting. There's also the possibility that your software keeps the connection open upon a failed auth, instead of closing after a predefined number of attempts. If that's the case, I'd send a bug report to the developers. >>> >>> Is there a way to so something simmilar by packets per second ? >>> >> packets per second sounds like a unit for bandwidth, which would >> suggest using something >> like ALTQ to throttle traffic. The problem remains though, since you >> may end up throttling all >> connections to your PBX, including legitimate clients. > > I considered ALTQ, but that is in my opinion not a very nice way to solve this > problem. > > Regards > > Mattthias > > -- > Matthias Cramer, Erachfeldstrasse 1b, CH-8180 Bülach, Switzerland > http://www.freestone.net > GnuPG 1024D/2D208250 = DBC6 65B6 7083 1029 781E 3959 B62F DF1C 2D20 8250 > > [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: PF: block upd packets that allready have a state
On 25 June 2012 16:12, Matthias Cramer wrote: > Hi Marios > Hi Matthias, > On 25/06/12 15:58, Marios Makassikis wrote: >> On 25 June 2012 15:36, Matthias Cramer wrote: >> >>> - to block a packet even with a established state ? >>> >> >> How are you detecting attackers in your current setup ? > > At the moment by hand ... I know that is not acceptable ... > >> I would consider having PF rate-limit connections to your SIP PBX, and >> add any host >> that goes over the limit to your badguys table. >> An example is described here: http://home.nuug.no/~peter/pf/en/bruteforce.html > > I saw this. But the problem is, the attacker allways comes with the same IP/Port Combo > so the is allways the same session for pf. So this method does not work! My understanding of this, is that the fact that PF creates a state, and uses it for the other communications with the attacker. Considering there is no other state created, it will never reach the limit to be added to the table. If that is the case, the question remains: how do you detect the attack ? Is the PBX rendered unusable for other clients ? I think a more accurate description of the attack would be helpful to find a solution to the problem. > > Is there a way to so something simmilar by packets per second ? > packets per second sounds like a unit for bandwidth, which would suggest using something like ALTQ to throttle traffic. The problem remains though, since you may end up throttling all connections to your PBX, including legitimate clients. > Regards > > Matthias > > -- > Matthias Cramer, Erachfeldstrasse 1b, CH-8180 Bülach > http://www.freestone.net > GnuPG 1024D/2D208250 = DBC6 65B6 7083 1029 781E 3959 B62F DF1C 2D20 8250
Re: using relayd in transparent mode
Hi,
You need to tell PF to intercept packets and redirect them to the relayd
process.
pass in on em2 inet proto tcp to any port www divert-to 192.168.20.1 port
8000
pass out log(all) on em1 divert-reply
You can find some more detailed information regarding relayd transparent
proxying in this thread:
http://marc.info/?l=openbsd-misc&m=130479125318862&w=2
After reloading PF, keep in mind that you have to change your test, i.e.:
connect to
your server on port 80, not port 8000.
Marios.
On 27 March 2012 15:18, Schmurfy wrote:
> Hi,
> I am trying to forward port using relayd which works but what I really need
> is transparent relaying and I cannot make that one works :/
>
> I have one OpenBSD 5.0 server with two network card (em0 can be ignored):
> - em1: 192.168.33.10/24
> - em2: 192.168.20.1/24
>
> And another machine acting as server:
> - em1: 192.168.33.11/24
>
> My computer (client) is connected to the server on em2 and the server and
> router are connected with their em1 interfaces, the server use the router
> as its default route.
>
> Here is my working configuration in non transparent mode:
> pf.conf:
> set skip on lo
> anchor "relayd/*"
> pass # to establish keep-state
>
>
> relayd.conf:
> relay banana {
> listen on "192.168.20.1" port 8000
> forward to "192.168.33.11" port 80
> }
>
>
>
> After restarting relayd I connect with "curl http://192.168.20.1:8000"; and
> I get the page served by the server machine, eveything is fine.
>
> Now I tried switching to a transparent relay, I added this in pf.conf:
> pass out log(all) on em1 divert-reply
>
> and my relayd.conf now looks like this:
> relay banana {
> listen on "192.168.20.1" port 8000
> transparent forward to "192.168.33.11" port 80 interface em1
> }
>
>
> After restarting relayd and reloading pf.conf if I start curl again I
> successfully connects to the relayd process but it never even tries to
> connect to the http server on the server machine :/
>
> I did some tests to ensure the routing was correct and the SO_BINDANY
> option was working by running this command on the router:
> nc -s 192.168.20.254 192.168.33.11 80
>
> When I do this it connects and if I type "GET /" it returns the web page
> and the server sees a connection from 192.168.20.254 so it seems to work.
>
>
> For some reason relayd cannot open the socket but I have no idea why...
> relayd logging is not very helpful, I managed to force it in debug mode and
> I got this:
>
> proc_dispatch: parent 1 got imsg 42 from relay 4
> proc_dispatch: relay 1 got imsg 42 from parent 0
> relay_dispatch_parent: session 1: expired
> proc_dispatch: pfe 1 got imsg 39 from relay 4
> # (previous line repeated a lot of time)
>
> relay banana, session 1 (1 active), 0, 192.168.20.254 -> :80, bindany
> failed, invalid socket
> # (after the previous line the connection with curl is closed)
>
> proc_dispatch: pfe 1 got imsg 39 from relay 4
> # (previous line repeated until I hit Ctrl+C)
>
> Any idea why relayd would fails to establish the connection ? I am now
> digging into the relayd sources trying to find something helpful but not
> much luck for now.
>
> Thanks for any help, it's really driving me crazy...
Re: Problem filtering CARP in PF
> I just thought of something that bit me recently as well. > > With a real IPv6 address CARP will send out advertisements via IPv4 > _and_ IPv6. It's the same CARP message so if either one reaches the > backup it's ok. > > Your block rule had "inet" so you were probably blocking IPv4 only. But > because of the send errors (due to pf blocking) fw1 started to demote > itself. > > Anyway, you have to block inet6 too if you want to block carp completely. > Hi, I thought of this yesterday shortly after leaving ... Indeed, after bumping the net.inet.carp.log value even more, there are messages such as this one in /var/log/messages : fw1 /bsd: carp0: ip_output failed: 65 fw1 /bsd: carp0: ip6_output failed: 65 fw1 /bsd: carp1: ip_output failed: 65 fw1 /bsd: carp1: ip6_output failed: 65 After clearing the states, reloading PF to allow CARP packets, fw1 says it transitioned from master to backup. I take it's because of the demote counter: as soon as I set it back up to 0, fw1 goes back to master and fw2 to backup. The demotion counter is decremented when you lose connectivity (ip_output errors for instance), but shouldn't it be reincremented when you regain connectivity? I'm guessing the user is expected to do this with something like ifstated if it isn't done automatically. I also tested the issue Frederic was having, and it seems to be fixed when you flush the rules and states after disabling PF. @Russell I think either pass quick proto carp keep state (no-sync) or pass quick proto carp no state is more appropriate, as it also takes into account pfsync presence and saves you from debugging issues like the one I was having. Thank you all for your help. Marios.
Re: Problem filtering CARP in PF
Hello,
> No, that's not from your manual commands. It says there are send errors
> when sending out the carp packets.
My bad.
>
> Just paste the output instead of interpreting...
>
Here you go:
carp:
45808 packets received (IPv4)
74835 packets received (IPv6)
0 packets discarded for bad interface
0 packets discarded for wrong TTL
0 packets shorter than header
0 discarded for bad checksums
0 discarded packets with a bad version
0 discarded because packet too short
0 discarded for bad authentication
32062 discarded for unknown vhid
0 discarded because of a bad address list
1582 packets sent (IPv4)
1582 packets sent (IPv6)
0 send failed due to mbuf memory error
923 transitions to master
The unknown vhid is because there another set of hosts using CARP
on the same link. The fw1 and fw2 are using the same vhid.
> If I look at the code netinet/ip_carp.c:
>
>> error = ip_output(m, NULL, NULL, IP_RAWOUTPUT,
&sc->sc_imo,
>> NULL);
>> if (error) {
>> if (error == ENOBUFS)
>> carpstats.carps_onomem++;
>> else
>> CARP_LOG(LOG_WARNING, sc,
>> ("ip_output failed: %d", error));
>> sc->sc_if.if_oerrors++;
>> if (sc->sc_sendad_errors < INT_MAX)
>> sc->sc_sendad_errors++;
>> if (sc->sc_sendad_errors ==
CARP_SENDAD_MAX_ERRORS(sc))
>> carp_group_demote_adj(&sc->sc_if, 1,
>> "> snderrors");
>
>
> Either the "send failed due to mbuf memory error" counter should be
> increasing, or an "ip_output failed" error should appear in the log.
>
As I said before, there's nothing besides state transitions and the snderrors
I pasted and incorrectly interpreted. From your input, I take it the
first demotion
was because I put a 'block all', and as such the CARP packets were
correctly blocked.
The value going back to one is most likely due to the fact I reloaded
PF with a rule
to let CARP traffic pass. However, that doesn't explain why it isn't
going back to 0.
Marios
Re: Problem filtering CARP in PF
Hi, > Are you sure that fw1 is sending and not receiving those? The only way > to be really sure is to use "tcpdump -D out". The sender IP was the one I assigned to fw1, but I retested it anyway with -D out and I can confirm that there is a difference between the demote count displayed by ifconfig and the one transmitted over to fw2. > Not sure what's going on yet, but the following may provide more hints: > - bump net.inet.carp.log to 3 > - check "netstat -s -p carp" > - if you use pfsync, use "no-sync" on the carp pass rules The no-sync shouldn't change anything, as I had previously set 'no state' on the carp rule. pfsync can't sync states that don't exist, can it? :-) Anyway, using either 'no state' or 'no-sync' doesn't change anything. Bumping net.inet.carp.log value only reports the demotion: carp:carp0 demoted group carp by 1 to 2 (> snderrors) carp:carp1 demoted group carp by 1 to 2 (> snderrors) And then, a few state transitions later: carp: carp0 demoted group carp by -1 to 1 (< snderrors) which corresponds to me trying to reset the demote counter back to 0. 'netstat -sp carp' doesn't give any information I consider useful, besides the number of IPv4/IPv6 packets sent and received, as well as the number of transitions to master. Marios
Re: Problem filtering CARP in PF
Hello, No, I'm using hardware machines. I tested what Imre suggested, i.e.: flushing PF states with 'pfctl -F states'. With a freshly booted machine, CARP packets are allowed to pass. I then disabled pf, flushed the states and reloaded pf with the 'block log' rule. At this point, CARP is effectively blocked, and remains so until a reboot happens: adding a pass rule, clearing states or even completely disabling pf had no effects. I tried using the following rule to let CARP pass: pass quick log inet proto carp no state which leads me to a very odd CARP configuration: fw2 remains master although it should go back to backup state. advskew on fw1 is 50, and 100 on fw2. A closer look at tcpdump revealed that CARP packets sent by fw1 have a demote value of 1, which explains why fw2 remains master as its demote value is 0. What I can't explain is this: fw1~# ifconfig -g carp carp: carp demote count 0 In other words, fw1 says it's demotion counter is null, but the messages sent have a demote value of 1. At the same time, fw1 transitions from backup to master and back again repeatedly, as I saw in /var/log/messages. I tried setting the demotion counter to a higher value, say 10, using 'ifconfig -g carp carpdemote 10' and then I get the expected behavior: fw2 remains master, fw1 remains backup and the demote value displayed by ifconfig is the same as the one that is sent to the other machine. I am not sure how useful a dmesg is in this case, but here is the dmesg.boot from the firewall (with the public IPv6 addresses obscured): http://pastebin.ca/2123109 Marios On 1 March 2012 07:03, Camiel Dobbelaar wrote: > On 29-2-2012 23:01, Fridiric URBAN wrote: >> Hello, >> >> Confirmed on a fresh and very simple virtual environnement with 2 >> firewall using latest snapshot (amd64). >> pf.conf containt a single line "block log", nothing is logged on pflog >> and the other firewall on the sharing the link layer still catch carp >> advertisement ! > > Virtual eh? I was wondering where the dmesg was. :-) > > If this is esxi you have to allow promiscious mode on the vswitch. > > Marios, are you using virtual machinery too? Can you post a dmesg > otherwise? > > > -- > Cam
Problem filtering CARP in PF
Hi all, I am in the process of setting up a lab to test a IPv6 setup, and I'm having some issues with filtering CARP traffic. The configuration looks like this: +| WAN/Internet |+ || em0||em0 +-+ +-+ | fw1 |-xl0--xl0-| fw2 | +-+ +-+ em1||em1 || || || em0||em0 +-+ +-+ | br1 |-rl0--rl0-| br2 | +-+ +-+ || || ---+---Shared LAN---+--- All four machines above are running OpenBSD. The firewalls (fw1 and fw2) are running OpenBSD 5.0, while the bridges br1 and br2 are running the latest snapshot available on /pub/OpenBSD/snapshots/ (dated 12/02/2012). I configured two CARP devices on the firewalls: - carp0 for the em0 interfaces - carp1 for the em1 interfaces I added the following rule in the pf.conf file, as the default policy is to block everything pass quick inet proto carp At this point, CARP seems to be working fine, but the rule isn't actually working. If I add the 'log' keyword, and run tcpdump -netvi pflog0 ip proto 112 there is no output at all. On the other and, running the following command on fw2 gives the expected output: tcpdump -netvi em1 ip proto 112 At this point I thought maybe some other rule in my ruleset is letting CARP traffic pass, so I replaced the whole ruleset with the following: block log all Sure enough, I still don't have any output on fw1, but fw2 receives CARP packets correctly. I should mention that originally, all machines were running -current, which made me think a regression may have been introduced. After reinstalling 5.0 on the firewalls and copying back the configuration files, the issue seemed to have disappeared, as I could match CARP packets: rule 25/(match) [uid 0, pid 28901] pass out on em1: carp 192.168.200.253 > 224.0.0.18: CARPv2-advertise 36: vhid=48 advbase=1 advskew=50 demote=2 (DF) [tos 0x10] (ttl 255, id 57018, len 56, bad cksum 0!) rule 25/(match) [uid 0, pid 28901] pass in on em1: carp 192.168.200.252 > 224.0.0.18: CARPv2-advertise 36: vhid=48 advbase=1 advskew=100 demote=0 (DF) (ttl 255, id 31275, len 56) ... Additionally, I should add that all the machines are dual-stacked. Perhaps this has to do something with the problem, although I have the exact same issue. For instance, 'block all' doesn't actually block, and the one time I had PF matching the IPv4 CARP packets, it also matched the IPv6 ones: rule 34/(match) [uid 0, pid 7854] pass out on em1: fe80::20e:cff:fe68:aad2 > ff02::12: CARPv2-advertise 36: vhid=48 advbase=1 advskew=50 demote=0 (len 36, hlim 255) rule 34/(match) [uid 0, pid 7854] pass in on em1: fe80::202:b3ff:feb2:e6ce > ff02::12: CARPv2-advertise 36: vhid=48 advbase=1 advskew=100 demote=0 (len 36, hlim 255) ... Attempts at blocking CARP traffic on the bridge were equally unsuccessful. A last test prior to posting got me the following results: The pf.conf file contained this rule at the top: block quick log inet proto carp And CARP was effectively blocked. Changing the 'block' to 'pass' allowed the packets to flow, as expected. Changing it back again to block has no effect. Can anyone explain this strange behaviour? Thanks, Marios.
