Re: What are the security features in OpenBSD 6.0 that are by default disabled?
On Sat, Oct 15, 2016 at 03:57:57PM -0500, Patrick Dohman wrote: > The daily security out being emailed is also default disabled ;) > > The monthly & weekly outs never seem to work either. nonsense. daily security is mailed *if it is non-empty*. Same goes for weekly and mothly. -Otto
iked - how to keep traffic outside the tunnel?
Hello I recently moved from ipsec/npppd to ikev2. Making the change went easily enough. However, there is something that I can't seem to figure out. I am using ikev2/ipsec to create a tunnel between two networks. Each network faces the internet through a openbsd gateway which gets is public IP via DHCP. Local Net --> IPSEC GW--> Internet<-- IPSEC GW<-- Remote Net 10.3.0.0/16 10.3.0.20 (int) 192.168.0.1 (int) 192.168.0.0/24 73.208.x.x (public DHCP) 99.23.x.x (public DHCP) The iked.conf file on each end is relatively simple. The "local" end: ikev2 "static_vpn" quick passive ipcomp esp from 10.3.0.0/16 to 192.168.0.0/24 peer 99.23.x.x srcid local.domain.com dstid remote.domain.com And, on the "remote" end: ikev2 "static_vpn" active ipcomp esp from 192.168.0.0/24 to 10.3.0.0/16 peer 73.208.x.x srcid remote.domain.com dstid local.domain.com This works without an issue. The tunnel is created, and all traffic gets forwarded from the two networks as expected. I can also contact (ssh) the "remote" IPSEC GW from a client on the "local" net via the tunnel (i.e. using 192.168.0.1 as the destination). But, if I try to connect to the "remote" IPSEC GW using its public IP (99.23.x.x) from a client on the "local" net, there is no connection. If I take the tunnel down, then I can connect (ssh) to the public IP of the remote IPSEC GW again. But, I don't understand why the traffic destined for the public IP of the remote IPSEC GW is (apparently??) being intercepted by iked. The way I read the man page, I was under the impression that only traffic for "192.168.0.0/24" would be encapsulated in the tunnel (using the rules above); and that traffic destined for the public IP of the "peer" would be ignored by iked. Is there something I am missing? Thanks
Re: relayd.conf error
On Sat, October 15, 2016 10:47 am, Ali H. Fardan wrote: > Hey misc@, I'm having issues with relayd.conf. this is the error I get > when I try to run relayd: > > > # rcctl -df start relayd > doing _rc_parse_conf > doing _rc_quirks > relayd_flags empty, using default >< > doing _rc_parse_conf /var/run/rc.d/relayd > doing _rc_quirks > doing rc_check > relayd > doing rc_pre > host_dns: chat.freenode.net resolves to more than 1 hosts > host_dns: irc.oftc.net resolves to more than 1 hosts > /etc/relayd.conf:11: syntax error > /etc/relayd.conf:12: protocol irctls defined twice > /etc/relayd.conf:17: syntax error > /etc/relayd.conf:18: protocol irctls defined twice > /etc/relayd.conf:23: syntax error > /etc/relayd.conf:24: protocol irctls defined twice > /etc/relayd.conf:31: syntax error > no actions, nothing to do > doing _rc_rm_runfile > (failed) > # > > > using this config: > > > # cat /etc/relayd.conf > protocol "irctls" { > tcp { nodelay, sack } > } > > table { chat.freenode.net } > table { irc.oftc.net } > table{ irc.swepipe.se } > table { irc.krustykrab.restaurant } > > relay "freenode" { > listen 127.0.0.1 port 7000 > protocol "irctls" > forward with tls to port 6697 > } > > relay "oftc" { > listen 127.0.0.1 port 7001 > protocol "irctls" > forward with tls to port 6697 > } > > relay "efnet" { > listen 127.0.0.1 port 7002 > protocol "irctls" > forward with tls to port 6697 > } > > relay "volatile" { > listen on 127.0.0.1 port 7003 > protocol "irctls" > forward with tls to 6697 > } > # > > > by the way, this config used to work the last time I tried it on my > last server, not this though, have relayd.conf syntax change in last > update? > Re-check your config like the errors say. You're not consistantly using the correct syntax. This has an error: listen 127.0.0.1 port 7000 This does not: listen on 127.0.0.1 port 7003 This has an error: forward with tls to 6697 The rest of your forward to lines do not. Tim.
support for AMD Radeon RX400 series
I've acquired an AMD Sapphire Nitro Radeon RX460 video card, a recently released (August 2016) GPU which is attractive for its good performance and low TDP. On amd64-current #2488 Sep 24 2016 it is detected as: vga1 at pci1 dev 0 function 0 vendor "ATI", unknown product 0x67ef rev 0xcf There is currently no listed support for this series in the manpage, so as expected radeondrm does not attach and there is no KMS or X acceleration. AMD released[0] an open source Linux driver along with the hardware. Because this card has a new (Polaris) chipset, does/will support for this chipset in OpenBSD eventually come from upstream somewhere or from an OpenBSD developer doing a driver port (in which case, would a hardware donation have value)? [0] http://www.phoronix.com/scan.php?page=article&item=amdgpu-rx480-linux&num=2 OT: While exploring the source tree at /usr/src/sys/dev/pci/drm/radeon/ I found a few typo nits, would patches come here?
Re: What are the security features in OpenBSD 6.0 that are by default disabled?
On Fri, 14 Oct 2016 20:50:20 +0200 "thrph.i...@gmail.com" wrote: > or this kind... > > " The only truly secure system is one that is powered off, cast in a > block of concrete and sealed in a lead-lined room with armed guards - > and even then I have my doubts. " > It needs to be stored under a filing cabinet in a disused lavatory with a sign on the door saying Beware of the Leopard.
Re: What are the security features in OpenBSD 6.0 that are by default disabled?
The daily security out being emailed is also default disabled ;) The monthly & weekly outs never seem to work either. Regards Patrick > On Oct 15, 2016, at 11:20 AM, Peter Janos wrote: > > remote supervisor/console solutions are still turned on while the server > is off, so simply powering off the OS isn't enough.there were/will be > many bugs for these remote console solutions too Sent: Friday, October > 14, 2016 at 9:48 PM > From: "Raul Miller" > To: "thrph.i...@gmail.com" > Cc: "OpenBSD general usage list" > Subject: Re: What are the security features in OpenBSD 6.0 that are by > default disabled?On Fri, Oct 14, 2016 at 2:50 PM, thrph.i...@gmail.com > wrote: >> " The only truly secure system is one that is powered off, cast in a > block of concrete and sealed in a lead-lined room with armed guards - and > even then I have my doubts. " > > Powered off works surprisingly well for some other operating systems. > > -- > Raul
Re: What are the security features in OpenBSD 6.0 that are by default disabled?
If that is a real issue for you, you should be building your own hardware and monitoring the electromagnetic spectrum. -- Raul On Sat, Oct 15, 2016 at 12:20 PM, Peter Janos wrote: > remote supervisor/console solutions are still turned on while the server is > off, so simply powering off the OS isn't enough. > there were/will be many bugs for these remote console solutions too > > Sent: Friday, October 14, 2016 at 9:48 PM > From: "Raul Miller" > To: "thrph.i...@gmail.com" > Cc: "OpenBSD general usage list" > Subject: Re: What are the security features in OpenBSD 6.0 that are by > default disabled? > On Fri, Oct 14, 2016 at 2:50 PM, thrph.i...@gmail.com > wrote: >> " The only truly secure system is one that is powered off, cast in a block >> of concrete and sealed in a lead-lined room with armed guards - and even >> then I have my doubts. " > > Powered off works surprisingly well for some other operating systems. > > -- > Raul
Re: What are the security features in OpenBSD 6.0 that are by default disabled?
remote supervisor/console solutions are still turned on while the server is off, so simply powering off the OS isn't enough.there were/will be many bugs for these remote console solutions too Sent: Friday, October 14, 2016 at 9:48 PM From: "Raul Miller" To: "thrph.i...@gmail.com" Cc: "OpenBSD general usage list" Subject: Re: What are the security features in OpenBSD 6.0 that are by default disabled?On Fri, Oct 14, 2016 at 2:50 PM, thrph.i...@gmail.com wrote: > " The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts. " Powered off works surprisingly well for some other operating systems. -- Raul
relayd.conf error
Hey misc@, I'm having issues with relayd.conf. this is the error I get when I try to run relayd: # rcctl -df start relayd doing _rc_parse_conf doing _rc_quirks relayd_flags empty, using default >< doing _rc_parse_conf /var/run/rc.d/relayd doing _rc_quirks doing rc_check relayd doing rc_pre host_dns: chat.freenode.net resolves to more than 1 hosts host_dns: irc.oftc.net resolves to more than 1 hosts /etc/relayd.conf:11: syntax error /etc/relayd.conf:12: protocol irctls defined twice /etc/relayd.conf:17: syntax error /etc/relayd.conf:18: protocol irctls defined twice /etc/relayd.conf:23: syntax error /etc/relayd.conf:24: protocol irctls defined twice /etc/relayd.conf:31: syntax error no actions, nothing to do doing _rc_rm_runfile (failed) # using this config: # cat /etc/relayd.conf protocol "irctls" { tcp { nodelay, sack } } table { chat.freenode.net } table { irc.oftc.net } table{ irc.swepipe.se } table { irc.krustykrab.restaurant } relay "freenode" { listen 127.0.0.1 port 7000 protocol "irctls" forward with tls to port 6697 } relay "oftc" { listen 127.0.0.1 port 7001 protocol "irctls" forward with tls to port 6697 } relay "efnet" { listen 127.0.0.1 port 7002 protocol "irctls" forward with tls to port 6697 } relay "volatile" { listen on 127.0.0.1 port 7003 protocol "irctls" forward with tls to 6697 } # by the way, this config used to work the last time I tried it on my last server, not this though, have relayd.conf syntax change in last update?