Re: Verizon FIOS, OpenBSD, and DHCP
On Tue, Feb 5, 2013 at 11:18 PM, Jay Hart jh...@kevla.org wrote: Solved this. It took Verizon three tries (three calls by me), to actually get the RJ-45 port working on the ONT. Hmm... I had to set my MAC address to the Actiontec's. $ cat /etc/hostname.em0 !ifconfig \$if lladdr 00:0f:b3:aa:aa:aa dhcp -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
Re: problem with iscsid
Allan Liblik allan at tarivara.ee writes: hi! I have problem with iscsid - can't connect to NAS4Free iSCSI target. There are - OpenBSD robert.vkhk.ee 5.2 GENERIC.MP#368 amd64 - NAS4Free 9.1.0.1 - Sandstorm (revision 573) In mid of 2012 I have discussed similar issue with another iscsid user. Setups been tried on 1: * initiator (iscsid) OpenBSD xxx 5.0 GENERIC#53 amd64 * target (FreeNAS) FreeBSD xxx 8.2-RELEASE-p9 #1 (istgtcontrol version 0.4 (20111008)) 2: * initiator (iscsid) OpenBSD xxx 5.2 GENERIC#298 amd64 * target (FreeNAS) FreeBSD xxx 8.2-RELEASE-p9 #1 (istgtcontrol version 0.4 (20111008)) On FreeNAS side log/messages was: Jul 19 09:19:32 freenas istgt[18173]: Login(discovery) from openbsd.mailserv (192.168.3.171) on (192.168.3.3:3260,1), ISID=801f363f3c1a, TSIH=5, CID=1356, HeaderDigest=off, DataDigest=off Jul 19 09:19:32 freenas istgt[18173]: Logout(discovery) from openbsd.mailserv (192.168.3.171) on (192.168.3.3:3260,1), ISID=801f363f3c1a, TSIH=5, CID=1356, HeaderDigest=off, DataDigest=off Jul 19 09:44:17 freenas istgt[18173]: Login(discovery) from openbsd.mailserv (192.168.3.171) on (192.168.3.3:3260,1), ISID=80d9d858cab2, TSIH=6, CID=4226, HeaderDigest=off, DataDigest=off Jul 19 09:44:17 freenas istgt[18173]: Logout(discovery) from openbsd.mailserv (192.168.3.171) on (192.168.3.3:3260,1), ISID=80d9d858cab2, TSIH=6, CID=4226, HeaderDigest=off, DataDigest=off Jul 19 09:46:56 freenas istgt[18173]: istgt_iscsi.c:2056:istgt_iscsi_op_login: ***ERROR*** SessionType is empty Jul 19 09:46:56 freenas istgt[18173]: istgt_iscsi.c:2033:istgt_iscsi_op_login: ***ERROR*** InitiatorName is empty Jul 19 09:46:56 freenas istgt[18173]: istgt_iscsi.c:3116:istgt_iscsi_op_scsi: ***ERROR*** before Full Feature Jul 19 09:46:56 freenas istgt[18173]: istgt_iscsi.c:4629:istgt_iscsi_execute: ***ERROR*** iscsi_op_scsi() failed Jul 19 09:46:56 freenas istgt[18173]: istgt_iscsi.c:5269:worker: ***ERROR*** iscsi_execute() failed on (openbsd.mailserv,i,0x802f2bdd1232) Cheers, Alexey
Re: Verizon FIOS, OpenBSD, and DHCP
On 6 February 2013, bofh goodb...@gmail.com wrote: On Tue, Feb 5, 2013 at 11:18 PM, Jay Hart jh...@kevla.org wrote: Solved this. It took Verizon three tries (three calls by me), to actually get the RJ-45 port working on the ONT. Hmm... I had to set my MAC address to the Actiontec's. $ cat /etc/hostname.em0 !ifconfig \$if lladdr 00:0f:b3:aa:aa:aa dhcp For what it's worth, it's probably useful to keep around a packet capture of a successful DHCP negotiation with your ISP. DHCP is a complicated protocol, and ISPs do weird things with it. A known-good packet capture might save you a lot of time when switching equipment. Regards, Liviu Daia
Re: UNIX A to Z List RFC
-- William Boshuck bos...@math.mcgill.ca [2013-02-04 14:25:04 -0500]: On Mon, Feb 04, 2013 at 10:27:42AM +, James Griffin wrote: I think vi(1) - not vim - would be a great tool for him to learn. A real hardcore UNIX editor, ed(1) Yes, absolutely. There was a thread on this list recently about bsd.rd not having vi(1) and learning ed(1) is certainly a really useful tool to learn. It's not that hard either, if learning vi(1) also. -- Primary Key: 4096R/1D31DC38 2011-12-03 Key Fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
pppx interface group
Hi, I've seen on the tech mailing list a patch for implementing a pppx interface group (just one line code addition). Is this going to be in 5.3 release? It would make PF filtering much nicer with many dynamic ipsec/l2tp connections. Regards Robert Blacquiere
Re: NAT over enc(4)
Hello Mitja, Le 05/02/2013 22:36, Mitja Muženič a écrit : I'm the author of the article you quoted. Your article is really great, I'm glad to get some help from you :) Do you have a default gateway? IPsec on OpenBSD behaves weirdly if you don't have one (even if it's not needed!). This scenario is likely to happen especially in the test setups with directly connected firewalls... Yes, I have one. In fact this is not a lab setup. I'm doing the test in production environment. I can break it as this is not a site of great importance. The two sites are connected via the Internet. The trick is that both ipsec tunnel perform a sanity check on the address range of the traffic. On this side the tunnel is between 192.168.0/24 and 192.168.6/24 [1], but we tell the peer that he ought to establish a tunnel from _his_ 192.168.0/24 to 192.168.7/24 [2]. So your traffic from the remote 192.168.0.1 to 192.168.7.1 fails the source check on this end, as there is no NAT on remote device and this side sees traffic from 192.168.0.1, not 192.168.6.1 as defined by the tunnel [1], so it's silently discarded. If you try to bypass this by pinging from 192.168.6.1 to 192.168.7.1, such traffic won't match the remote site's source tunnel definition [2] and will be dropped on the remote end already before even entering the tunnel. It isn't clear to me. There is NAT on remote the device and I can see traffic from 192.168.6.1. There shouldn't be any traffic from 192.168.x.0 on your em0, that's your public interface, isn't it? I presume this comes from you actually testing this in a lab and em0 is actually directly connected to the remote device? So the private traffic on em0 is leakage from far side because that traffic does not enter the vpn tunnel at all. em0 is my public facing interface and it is connected to an ISP that route traffic to the other site. This is unexpected, you should be seeing icmp echo from 192.168.7.1 to 192.168.6.1. Double check that your match on enc0... rules really apply to those packets, I've been bitten by the match logic before. For test purposes you can always rewrite that rule to pass out quick on enc0 Also see that you don't have a set skip on enc0 line. I don't for sure. The whole pf.conf was posted at the top of the first mail. There is nothing more than the first match rule. I'm pretty sure the problem lies with PF, can't see where for now but I'm still searching. Thank you very much for the answer. Denis
Re: Verizon FIOS, OpenBSD, and DHCP
You shouldn't have to input the actiontec MAC. I feel your pain about the support though. It sucks. To alleviate this put the actiontec back in. Log into it and go to the interface and actually release the IP. After that unplug it immediately. Plug your ONT into your BSD firewall and boot it up and you'll be good to go. You can also just run dhclient on yiur interfacr but I found a solid reboot worked for me as just requesting a new IP did not. Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Liviu Daia [liviu.d...@romednet.com] Received: Wednesday, 06 Feb 2013, 4:55am To: misc@openbsd.org [misc@openbsd.org] Subject: Re: Verizon FIOS, OpenBSD, and DHCP On 6 February 2013, bofh goodb...@gmail.com wrote: On Tue, Feb 5, 2013 at 11:18 PM, Jay Hart jh...@kevla.org wrote: Solved this. It took Verizon three tries (three calls by me), to actually get the RJ-45 port working on the ONT. Hmm... I had to set my MAC address to the Actiontec's. $ cat /etc/hostname.em0 !ifconfig \$if lladdr 00:0f:b3:aa:aa:aa dhcp For what it's worth, it's probably useful to keep around a packet capture of a successful DHCP negotiation with your ISP. DHCP is a complicated protocol, and ISPs do weird things with it. A known-good packet capture might save you a lot of time when switching equipment. Regards, Liviu Daia
bge(4) Broadcom 5720/Dell R320 support backout
Hi all, It seems that the support for 5720 was backout because it broke another chipset. [1] The thing is that the newer Dell R320 has this chipset and I'm currently evaluating the its support. So I would like to know if the support would indeed work if I applied the patch again. I mean was the only reason to backout the break in other chipset? Thanks in advance. Cheers, --rodolfo [1] rev 1.317 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_bge.c
Re: Verizon FIOS, OpenBSD, and DHCP
FIOS doesn't have any influence on whether an O/S will work with it. The GPON gear tracks DHCP requests, storing response. At least that is how it works on Tellabs and I believe Verizon FIOS uses Tellabs gear. I've been using OpenBSD's dhclient on an enterprise GPON implementation for a couple years. diana Past hissy-fits are not a predictor of future hissy-fits. Nick Holland(06 Dec 2005)
Re: OpenBSD VAX on SIMH, sloooow networking!
On 2013-02-05, John Long codeb...@inbox.lv wrote: I installed OpenBSD VAX on SIMH. Host is OpenBSD 5.2 stable amd64. Networking from within SIMH is unbelievably slow. It takes 5 hours to download base52.tgz. I've done ftp and NFS installs from my own local servers, performance to my host box is 7 MB/sec. In SIMH it's about 4kb/sec. Running SIMH on a mipsel64 box running OpenBSD 5.2 stable is exactly as bad. Has anybody experienced Yes. and overcome this? No.
Re: OpenBSD VAX on SIMH, sloooow networking!
On Wed, Feb 06, 2013 at 06:03:04PM +, Stuart Henderson wrote: On 2013-02-05, John Long codeb...@inbox.lv wrote: I installed OpenBSD VAX on SIMH. Host is OpenBSD 5.2 stable amd64. Networking from within SIMH is unbelievably slow. It takes 5 hours to download base52.tgz. I've done ftp and NFS installs from my own local servers, performance to my host box is 7 MB/sec. In SIMH it's about 4kb/sec. Running SIMH on a mipsel64 box running OpenBSD 5.2 stable is exactly as bad. Has anybody experienced Yes. and overcome this? No. Thanks for the data point/confirmation. I'll try it on another OS and see if anything changes. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Safe bruteforce rule for mobile-friendly website
Hi, Turns out this (http://home.nuug.no/~peter/pf/en/long-firewall.html) bans any IP connecting from mobile devices: pass in on $ext_if inet proto tcp from any to any port 80 keep state (max-src-conn 100, max-src-conn-rate 15/5, overload bruteforce flush global) Works fine when connecting from regular PCs though. Why is that? Do mobile devices connect differently somehow? And can someone recommend a mobile-friendly bruteforce rule for port 80? Thanks!
Re: Safe bruteforce rule for mobile-friendly website
2013/2/6 Mikkel Bang facebookman...@gmail.com: Works fine when connecting from regular PCs though. Why is that? Do mobile devices connect differently somehow? Start in /var/log, I suppose. -- Michał Markowski
Re: Safe bruteforce rule for mobile-friendly website
On Feb 06 21:52:20, facebookman...@gmail.com wrote: Hi, Turns out this (http://home.nuug.no/~peter/pf/en/long-firewall.html) bans any IP connecting from mobile devices: pass in on $ext_if inet proto tcp from any to any port 80 keep state (max-src-conn 100, max-src-conn-rate 15/5, overload bruteforce flush global) Works fine when connecting from regular PCs though. Why is that? Do mobile devices connect differently somehow? tcpdump such a session to see what kind of connection your mobile device does to port 80; my android's browser for example goes over 15/5 like nothing. And can someone recommend a mobile-friendly bruteforce rule for port 80? It depends on your situation entirely. Do you want to block 15/5 clients?
Re: Safe bruteforce rule for mobile-friendly website
Mikkel Bang facebookman...@gmail.com writes: Turns out this (http://home.nuug.no/~peter/pf/en/long-firewall.html) bans any IP connecting from mobile devices: Well, that document says a lot of other stuff too, so please be more specific. pass in on $ext_if inet proto tcp from any to any port 80 keep state (max-src-conn 100, max-src-conn-rate 15/5, overload bruteforce flush global) Works fine when connecting from regular PCs though. Why is that? Do mobile devices connect differently somehow? Somehow your mobiles hit either the fifteen new connections per five seconds max (that's only three new connections per second) or the 100 simultaneous connections. Impossible to say which one without studying the actual session data via tcpdump. Unless the back end is too brittle, consider loosening the rate limiting or discarding it altogether. You could try temporarily removing either the max-src-conn or the max-src-conn-rate setting to see which one trips up the mobiles. Possibly relevant question: do all clients receive the same content, or is there a separate version you serve to mobile clients? - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
label-like output for pf table stats
Curious to know if anyone else has had the need for a label-like output option for displaying pf table stats. $ `pfctl -vsl' produces a nice parse-able output; int_if_icmp 50247 160 221120 80 110560 80 110560 2 $ `pfctl -v -t table_name -T show' produces similar data but difficult to parse; 10.0.0.27 Cleared:Tue Feb 5 12:13:13 2013 In/Block: [ Packets: 0 Bytes: 0 ] In/Pass:[ Packets: 80584 Bytes: 11502955 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass: [ Packets: 107323 Bytes: 116053001 ] I assume this can be worked from pf ioctl's (man 4 pf) but for someone lacking C programming skills this would be a nice out-of-the box feature. Or is this request out-of-scope for pfctl's design? -- Byron Klippert byronklipp...@ml1.net c. 867-336-1306
Relayd as Transparent HTTP Proxy problem
I have been trying to get relayd to work as a Transparent http proxy on
a old OBSD 4.7 server today but I am having some trouble getting it to
do what I want. The transparent proxy works perfectly but I want to
block access to all websites unless their on a whitelist in the
relayd.conf file. We have squid proxy that all our web traffic should
go through but we also have some apps that just refuse to use a proxy
that we think we could let through the transparent proxy.
http protocol httpfilter {
tcp { nodelay, sack, socket buffer 65536, backlog 1000 }
return error
header change Keep-Alive to $TIMEOUT
header change Connection to close
request header log Host
label Unauthorised Host please contact support@
request header expect undeadly.org from Host
request header expect *undeadly.org* from Host
# label BAD user agent
# request header filter Mozilla/4.0* from User-Agent
# request header filter SomeBrokeBrowser/1.0* from User-Agent
# label BAD Host request
#request header filter *youtube.com* from Host
#request header filter *myspace.com* from Host
#request header filter *facebook.com* from Host
#request header filter *bfriends.com* from Host
request header change Accept to
text/html,text/plain;q=0.9,*/*;q=0.8
request header change Accept-Charset to ISO-8859-1,utf-8;q=0.9
request header change Accept-Encoding to gzip
request header change Accept-Language to en-us,en;q=0.9
request header change User-Agent to InVis
}
relay httpproxy {
listen on 127.0.0.1 port 8080
protocol httpfilter
forward to nat lookup
}
When the above config is loaded and I visit the undeadly website I just
get the following error.
Forbidden
incomplete request
OpenBSD relayd at 127.0.0.1 port 8080
Can someone help ?
Thanks
Keith
Re: openbsd and vmware
I'm Using KVM to virtualize OpenBSD 5.2 right now. I'm not that impressed about Vmware. I used a esxi server for 2 years extensivly. Things i didnt like : cli,closed software,bloated,technical documentation,gui. Not that KVM is much better at this point,but at least, i have the sources. problems i found using kvm and openbsd: SMP not working as it should. spice and qxl is not that good right now. No virto drivers for openbsd(disk i miss the most) Virt-viewer (remote spice viewer app) has some annoying keyboardlayout obfuscation. And with a look in the future i dont think the problems are going to to be solved. A recent article on phoronix.com had information about qxl getting KMS support. Correct me if im wrong, but this seems quite linux only to me. Non the less, i use KVM right now for a few OpenBSD,Linux and Win8 Maschines and overall it performs quite well. One of myinterests are VDI solutions, for that i will check citrix (xen) as an alternative in the future. --send from mobile
Re: Relayd as Transparent HTTP Proxy problem
On Wed, Feb 6, 2013 at 4:03 PM, Keith ke...@scott-land.net wrote: I have been trying to get relayd to work as a Transparent http proxy on a old OBSD 4.7 server today but I am having some trouble getting it to do what I want. The transparent proxy works perfectly but I want to block access to all websites unless their on a whitelist in the relayd.conf file. We have squid proxy that all our web traffic should go through but we also have some apps that just refuse to use a proxy that we think we could let through the transparent proxy. ... Can someone help ? There have been *massive* changes in relayd in recent releases...and you're using a release from almost 3 years ago. So: set up a new server running 5.2 next to your current one, then transition everything to it, then give it another shot. Philip Guenther
