Re: VMs as real hosts on the same network
could you post here your /etc/pf.conf rules? Dne 07. 12. 18 v 12:40 Mischa napsal(a): On 7 Dec 2018, at 12:32, mabi wrote: ‐‐‐ Original Message ‐‐‐ On Friday, December 7, 2018 11:43 AM, Mischa wrote: It might be as easy as adding: up cat /etc/hostname.bridge6 == add vlan6 up By default the bridge interface is not brought up. You can also run: ifconfig bridge6 up Good idea and I added "up" to my hostname.bridge6 file but it looks like it was already up (at least by doing an ifconfig bridge6 shows the "UP" flag). Neverthless to be on the safe side I rebooted the server but still not connectivity on the vlan6/bridge6 network for the VMs. On the bridge6 interface I can see the DHCP request with tcpdump when the OpenBSD installer in the VM tries to fetch an IP address with DHCP: 11:59:35.672258 0.0.0.0.68 > 255.255.255.255.67: xid:0xbafb375b [|bootp] [tos 0x10] Then on the DHCP server I can see the following in loop: Dec 7 12:00:27 dhcpsrv dhcpd[18917]: DHCPDISCOVER from fe:e1:bb:01:01:01 via XXX.XXX.XXX.1 Dec 7 12:00:27 dhcpsrv dhcpd[18917]: DHCPOFFER on XXX.XXX.XXX.101 to fe:e1:bb:01:01:01 via XXX.XXX.XXX.1 The IP address ending with .1 is the gateway on my public network and the one ending with .101 is the IP which should be assigned to my OpenBSD VM. It seems like the traffic is not flowing back to the VM itself. I just found a very interesting behaviour by running tcpdump on pretty much all interfaces of my server to analyze the traffic at different levels and BINGO: as soon as I run tcpdump on my trunk0 interface the DHCP request goes through and my VM has network connectivity! But as soon as I stop tcpdump on the trunk interface: no more network connectivity... Now as far as I know running tcpdump enables promiscous mode (PROMISC flag on the interface) and this should the reason why it works. But now what does it mean for my setup, do I need to enable promiscuous mode on my trunk interface manually? and if yes how can I do that? The VLAN does require an IP address as far as I am aware. Mischa -- Martin Sukany UNIX Engineer - Solaris / Linux / OpenBSD L3 Specialist +420 776 275 713 www.sukany.cz
Re: Thinkpad T430 random power off while sleeping
> I have a similar issue with the X220, the problem is a watchdog > timer, > that I suspect is in the Intel ME. It expires without being reset > and > forces the machine to restart. Or at least that is the cause of > that > happening on my X230's. I've ripped a few of them apart and > analyzed > their guts and found only the CPU and a few other chips are active > during suspend. I've probed all the buses of those other chips and > none > make a peep when the machine reboots, the only chip left active is > the > Intel ME chunk of the CPU, and for obvious reasons, I have no idea > what > it is doing, so I suspect it is the culprit. I think there is at least some aspect of software at play here however. I did not experience these issues while running Debian 9 on the machine. It could be that Linux uses some horrible hack to make suspend work reliably, but it does nevertheless work. > I gave up on the work a few months ago since it seemed easier to > just > accept that suspend isn't going to work and just use suspend-to-disk > or > just shut the machine down completely. I had intended to use suspend-to-disk with this machine, but I found that applications that use hardware acceleration (namely Firefox) do not function after resuming from suspend to disk. The specific symptom is that the application's window is just black with no visible contents. Restarting it does nothing. This is very likely a problem with inteldrm. Disabling hardware acceleration in FF fixes the problem, but makes it almost unusably slow. > If you want to do more, and have > access to a Windows machine, you can try pulling apart the Lenovo > drivers to see what the Lenovo-specific ACPI driver is doing when > the > machine goes into suspend. I don't, but I had planned to throw Windows on a spare disk and see if updating the firmware / BIOS / playing with the proprietary driver helps or yields any useful information. ... Maybe I should look at running coreboot on the T430, since it's supported now. Thanks for your detailed response!
Re: sh /etc/netstart interface counter intuitive behaviour with multiple inet aliases 6.4 and 6.3
Thanks Tom Smyth On Fri, 7 Dec 2018 at 13:09, Martin Pieuchot wrote: > > On 06/12/18(Thu) 22:49, Tom Smyth wrote: > > Hello, > > > > Im running a router with multiple ips on an interface using the > > inet alias > > > > issue: > > when commenting out configured aliases on hostname.if > > after running sh /etc/netstart vio4 > > > > if you run ifconfig vio4 after the restart of the interface > > the old aliases that were commented still appear in ifconfig output ahead > > of the first ip address configured in the /etc/hostname.vio4 file. > > > > ifconfig before commenting out 10.134.91.253 in hostname.vio4 > > is listed below > > vio4: flags=8843 mtu 1500 > > lladdr 16:2c:a4:f2:b4:e3 > > index 5 priority 0 llprio 3 > > media: Ethernet autoselect > > status: active > > inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 > > inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 > > inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 > > inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 > > inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 > > inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 > > inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 > > inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 > > inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 > > inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 > > inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 > > inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 > > inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 > > inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 > > inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 > > inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211 > > inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215 > > inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219 > > inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223 > > inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227 > > inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231 > > inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235 > > inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239 > > inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243 > > inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247 > > inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 > > inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 > > > > > > after commenting out the last 2 inet aliases , and running sh /etc/netstart > > vio4 > > > > the ifconfig output is as follows (i have highlighted with *** the > > addresses > > which I think should have been removed > > > > vio4: flags=8843 mtu 1500 > > lladdr 16:2c:a4:f2:b4:e3 > > index 5 priority 0 llprio 3 > > media: Ethernet autoselect > > status: active > > ** inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 > > ** inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 > > inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 > > inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 > > inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 > > inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 > > inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 > > inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 > > inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 > > inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 > > inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 > > inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 > > inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 > > inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 > > inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 > > inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 > > inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 > > inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211 > > inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215 > > inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219 > > inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223 > > inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227 > > inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231 > >
Re: VMs as real hosts on the same network
> On 7 Dec 2018, at 11:35, mabi wrote:
>
> Hello,
>
> I am trying out VMM on an OpenBSD 6.4 server which has the following network
> interfaces defined:
>
> [bnx0]+[bnx1]-->[trunk0]-->[vlan2]
> [bnx0]+[bnx1]-->[trunk0]-->[vlan6]-->[bridge6]
>
> The vlan2 is for the internal (management) network and vlan6 for the public
> (internet) network. I manage my server from vlan2 and would like to have my
> virtual machines on vlan6 which uses public IP addresses. For that purpose I
> have setup my /etc/hostname.* files as such:
>
> hostname.bnx0 + hostname.bnx1:
> up
>
> hostname.trunk0:
> trunkproto failover trunkport bnx0 trunkport bnx1 up
>
> hostname.vlan2:
> inet 192.168.1.5 255.255.255.0 192.168.1.255 vnetid 2 parent trunk0
> description "private"
>
> hostname.vlan6:
> vnetid 6 parent trunk0 description "public" up
>
> hostname.bridge6:
> add vlan6
>
It might be as easy as adding: up
# cat /etc/hostname.bridge6
add vlan6
up
By default the bridge interface is not brought up.
You can also run: ifconfig bridge6 up
This will most likely be the "problem".
Mischa
> I am actually using Option 4 from the Networking chapter in the
> virtualization FAQ (https://www.openbsd.org/faq/faq16.html) just that my
> setup has a redundant link (trunk0) and a VLAN (vlan6). So in theory that
> should work but unfortunately when I start a VM to install OpenBSD 6.4 from
> the bsd.rd boot file I do not have any network connectivity. I tried with
> DHCP first and in that case on the DHCP server I see the DHCPDISCOVER and
> DHCPOFFER requests/answer but there is never a DHCPACK. Then I tried
> assigning a static IP directly but still no network connectivity. I can't
> ping the default gateway of that public network. Checking with tcpdump on the
> firewall I can see the ARP who-has request and the ARP reply back the the VM
> but again it seems like the VM does not get it.
>
> Here is my vm.conf conf file:
>
> switch "uplink_vlan6" {
>interface bridge6
> }
>
> vm "example" {
>disable
>memory 2G
>boot "/home/admin/bsd.rd"
>disk "/var/vmm/example.qcow2"
>
>interface {
>switch "uplink_vlan6"
>lladdr fe:e1:bb:01:01:01
>}
> }
>
> I have also totally disabled pf on that OpenBSD VMM server but that did not
> change anything (I am using the default pf.conf from the installation)
>
> Any ideas what I might be doing wrong or forgetting?
>
> Regards,
> Mabi
>
Re: VMs as real hosts on the same network
‐‐‐ Original Message ‐‐‐
On Friday, December 7, 2018 12:57 PM, Martin Sukany wrote:
> could you post here your /etc/pf.conf rules?
Sure, it's actually the default OpenBSD 6.4 one as you can see below:
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
set skip on lo
block return log# block stateless traffic
pass# establish keep-state
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
See my previous mail answering Mischa, his solution of adding an IP to the VLAN
interface solves my issue...
VMs as real hosts on the same network
Hello,
I am trying out VMM on an OpenBSD 6.4 server which has the following network
interfaces defined:
[bnx0]+[bnx1]-->[trunk0]-->[vlan2]
[bnx0]+[bnx1]-->[trunk0]-->[vlan6]-->[bridge6]
The vlan2 is for the internal (management) network and vlan6 for the public
(internet) network. I manage my server from vlan2 and would like to have my
virtual machines on vlan6 which uses public IP addresses. For that purpose I
have setup my /etc/hostname.* files as such:
hostname.bnx0 + hostname.bnx1:
up
hostname.trunk0:
trunkproto failover trunkport bnx0 trunkport bnx1 up
hostname.vlan2:
inet 192.168.1.5 255.255.255.0 192.168.1.255 vnetid 2 parent trunk0 description
"private"
hostname.vlan6:
vnetid 6 parent trunk0 description "public" up
hostname.bridge6:
add vlan6
I am actually using Option 4 from the Networking chapter in the virtualization
FAQ (https://www.openbsd.org/faq/faq16.html) just that my setup has a redundant
link (trunk0) and a VLAN (vlan6). So in theory that should work but
unfortunately when I start a VM to install OpenBSD 6.4 from the bsd.rd boot
file I do not have any network connectivity. I tried with DHCP first and in
that case on the DHCP server I see the DHCPDISCOVER and DHCPOFFER
requests/answer but there is never a DHCPACK. Then I tried assigning a static
IP directly but still no network connectivity. I can't ping the default gateway
of that public network. Checking with tcpdump on the firewall I can see the ARP
who-has request and the ARP reply back the the VM but again it seems like the
VM does not get it.
Here is my vm.conf conf file:
switch "uplink_vlan6" {
interface bridge6
}
vm "example" {
disable
memory 2G
boot "/home/admin/bsd.rd"
disk "/var/vmm/example.qcow2"
interface {
switch "uplink_vlan6"
lladdr fe:e1:bb:01:01:01
}
}
I have also totally disabled pf on that OpenBSD VMM server but that did not
change anything (I am using the default pf.conf from the installation)
Any ideas what I might be doing wrong or forgetting?
Regards,
Mabi
Re: sh /etc/netstart interface counter intuitive behaviour with multiple inet aliases 6.4 and 6.3
On 06/12/18(Thu) 22:49, Tom Smyth wrote: > Hello, > > Im running a router with multiple ips on an interface using the > inet alias > > issue: > when commenting out configured aliases on hostname.if > after running sh /etc/netstart vio4 > > if you run ifconfig vio4 after the restart of the interface > the old aliases that were commented still appear in ifconfig output ahead > of the first ip address configured in the /etc/hostname.vio4 file. > > ifconfig before commenting out 10.134.91.253 in hostname.vio4 > is listed below > vio4: flags=8843 mtu 1500 > lladdr 16:2c:a4:f2:b4:e3 > index 5 priority 0 llprio 3 > media: Ethernet autoselect > status: active > inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 > inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 > inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 > inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 > inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 > inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 > inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 > inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 > inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 > inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 > inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 > inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 > inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 > inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 > inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 > inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211 > inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215 > inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219 > inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223 > inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227 > inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231 > inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235 > inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239 > inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243 > inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247 > inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 > inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 > > > after commenting out the last 2 inet aliases , and running sh /etc/netstart > vio4 > > the ifconfig output is as follows (i have highlighted with *** the addresses > which I think should have been removed > > vio4: flags=8843 mtu 1500 > lladdr 16:2c:a4:f2:b4:e3 > index 5 priority 0 llprio 3 > media: Ethernet autoselect > status: active > ** inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 > ** inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 > inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 > inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 > inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 > inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 > inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 > inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 > inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 > inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 > inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 > inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 > inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 > inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 > inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 > inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 > inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 > inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211 > inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215 > inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219 > inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223 > inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227 > inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231 > inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235 > inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239 > inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243 > inet 10.134.91.245
Re: VMs as real hosts on the same network
‐‐‐ Original Message ‐‐‐ On Friday, December 7, 2018 11:43 AM, Mischa wrote: > It might be as easy as adding: up > > cat /etc/hostname.bridge6 > > == > > add vlan6 > up > > By default the bridge interface is not brought up. > You can also run: ifconfig bridge6 up Good idea and I added "up" to my hostname.bridge6 file but it looks like it was already up (at least by doing an ifconfig bridge6 shows the "UP" flag). Neverthless to be on the safe side I rebooted the server but still not connectivity on the vlan6/bridge6 network for the VMs. On the bridge6 interface I can see the DHCP request with tcpdump when the OpenBSD installer in the VM tries to fetch an IP address with DHCP: 11:59:35.672258 0.0.0.0.68 > 255.255.255.255.67: xid:0xbafb375b [|bootp] [tos 0x10] Then on the DHCP server I can see the following in loop: Dec 7 12:00:27 dhcpsrv dhcpd[18917]: DHCPDISCOVER from fe:e1:bb:01:01:01 via XXX.XXX.XXX.1 Dec 7 12:00:27 dhcpsrv dhcpd[18917]: DHCPOFFER on XXX.XXX.XXX.101 to fe:e1:bb:01:01:01 via XXX.XXX.XXX.1 The IP address ending with .1 is the gateway on my public network and the one ending with .101 is the IP which should be assigned to my OpenBSD VM. It seems like the traffic is not flowing back to the VM itself. I just found a very interesting behaviour by running tcpdump on pretty much all interfaces of my server to analyze the traffic at different levels and BINGO: as soon as I run tcpdump on my trunk0 interface the DHCP request goes through and my VM has network connectivity! But as soon as I stop tcpdump on the trunk interface: no more network connectivity... Now as far as I know running tcpdump enables promiscous mode (PROMISC flag on the interface) and this should the reason why it works. But now what does it mean for my setup, do I need to enable promiscuous mode on my trunk interface manually? and if yes how can I do that?
Re: VMs as real hosts on the same network
> On 7 Dec 2018, at 12:32, mabi wrote: > > ‐‐‐ Original Message ‐‐‐ > On Friday, December 7, 2018 11:43 AM, Mischa wrote: > >> It might be as easy as adding: up >> >> cat /etc/hostname.bridge6 >> >> == >> >> add vlan6 >> up >> >> By default the bridge interface is not brought up. >> You can also run: ifconfig bridge6 up > > Good idea and I added "up" to my hostname.bridge6 file but it looks like it > was already up (at least by doing an ifconfig bridge6 shows the "UP" flag). > Neverthless to be on the safe side I rebooted the server but still not > connectivity on the vlan6/bridge6 network for the VMs. > > On the bridge6 interface I can see the DHCP request with tcpdump when the > OpenBSD installer in the VM tries to fetch an IP address with DHCP: > > 11:59:35.672258 0.0.0.0.68 > 255.255.255.255.67: xid:0xbafb375b [|bootp] > [tos 0x10] > > Then on the DHCP server I can see the following in loop: > > Dec 7 12:00:27 dhcpsrv dhcpd[18917]: DHCPDISCOVER from fe:e1:bb:01:01:01 via > XXX.XXX.XXX.1 > Dec 7 12:00:27 dhcpsrv dhcpd[18917]: DHCPOFFER on XXX.XXX.XXX.101 to > fe:e1:bb:01:01:01 via XXX.XXX.XXX.1 > > The IP address ending with .1 is the gateway on my public network and the one > ending with .101 is the IP which should be assigned to my OpenBSD VM. > > It seems like the traffic is not flowing back to the VM itself. > > I just found a very interesting behaviour by running tcpdump on pretty much > all interfaces of my server to analyze the traffic at different levels and > BINGO: as soon as I run tcpdump on my trunk0 interface the DHCP request goes > through and my VM has network connectivity! But as soon as I stop tcpdump on > the trunk interface: no more network connectivity... > > Now as far as I know running tcpdump enables promiscous mode (PROMISC flag on > the interface) and this should the reason why it works. > > But now what does it mean for my setup, do I need to enable promiscuous mode > on my trunk interface manually? and if yes how can I do that? > The VLAN does require an IP address as far as I am aware. Mischa
Re: VMs as real hosts on the same network
‐‐‐ Original Message ‐‐‐ On Friday, December 7, 2018 12:40 PM, Mischa wrote: > The VLAN does require an IP address as far as I am aware. Thanks that worked. I now have network connectivity on my public VM VLAN. I saw that adding an IP to my VLAN interface automatically set the trunk interface to PROMISC. I was trying to avoid "wasting" an IP address as there is no real need for an IP on that VLAN interface on the server itself. But if that's the only way I am fine with that :)
Renew/extend CA created with ikectl
Hello, before I start getting creative with openssl(1) on my ikectl(8) created ca. Yesterday my ca certificate expired and I need to renew it (without loosing all the client certificates) Is there a recommended way of renewing the ca.crt created using ikectl ca create? I didn't find anything in the man pages nor on the mailing list. Having had a look at ikeca.c gave me some idea of how the file is created. Also is there a way of having the ca cert valid for more than 365 days? Cheers, Kim smime.p7s Description: S/MIME Cryptographic Signature
Pass, gpg2, gpg
Hi everyone, I can not seem to find a solution to this. I like https://www.passwordstore.org/ and I am so gratefull to have it in OpenBSD as a package! I can deduce pass command uses gpg2 command which in turn uses gpg command. The issue is *gpg is always in batch mode*, so if I want to use pass, I have to manually decrypt something directly using gpg2 (gpg2 -d bla -> prompt for passphrase). This way pass is usable as one would expect. Question: How to set gpg, gpg2 as interactive mode *by default*? Thank you very much! Lucas.
Re: relayd: Layer 7 proxy: forward failed
On Thu, December 6, 2018 12:04 pm, Leo Unglaub wrote:
> Hi,
> i am trying to use relayd as an outbound proxy. I am following the
> manual page and also the book "Httpd and Relayd Mastery". I did this on
> the latest release 6.4 and also on the latest snapshot to make sure this
> was not already fixed somewhere. I am on amd64.
>
> My relayd config looks like this:
>
>> # cat /etc/relayd.conf
>> relay "proxy" {
>> listen on 127.0.0.1 port 8080
>> forward to destination
>> }
>>
>> relay "proxy2" {
>> listen on 192.168.0.19 port 9090
>> forward to destination
>> }
>
>
> I use this command to open up a connection from a different host in the
> network:
>
>> $ curl -i -x 192.168.0.19:9090 openbsd.org
>
> I used the following command when i am on the same host:
>
>> $ curl -i -x 127.0.0.1:8080 openbsd.org
>
I don't have the time to set this up to test, so just throwing ideas out.
Doesn't this set up a transparent relay? Should you be configuring a
proxy with curl in this case? Did you try it without?
>
> I get the same error every time:
>> # relayd -df /etc/relayd.conf
>> startup
>> pfe: filter init done
>> socket_rlimit: max open files 1024
>> socket_rlimit: max open files 1024
>> socket_rlimit: max open files 1024
>> socket_rlimit: max open files 1024
>> parent_tls_ticket_rekey: rekeying tickets
>> relay_privinit: adding relay proxy
>> protocol -1: name default
>> flags: used, relay flags: divert
>> tls session tickets: disabled
>> type: tcp
>> relay_privinit: adding relay proxy2
>> protocol -1: name default
>> flags: used, relay flags: divert
>> tls session tickets: disabled
>> type: tcp
>> init_tables: created 0 tables
>> relay_launch: running relay proxy
>> relay_launch: running relay proxy
>> relay_launch: running relay proxy2
>> relay_launch: running relay proxy
>> relay_launch: running relay proxy2
>> relay_launch: running relay proxy2
>> relay_connect: session 1: forward failed: Operation not permitted
>> relay_close: sessions inflight decremented, now 0
>
>
> I used the following addition to the default pf.conf.
>> pass in on egress inet proto tcp to port 80 divert-to 127.0.0.1 port
>> 8080
>
If you're connecting from inside the network, is 'in on egress' the
correct interace here?
>
>
> Is this a bug in my setup or a problem with relayd?
>
> I also tryed the entire config from the book "Httpd and Relayd Mastery"
> and even when i type it down 1 by 1 i get the same error.
>
> Thanks and greetings
> Leo
>
Re: OpenBSD current & Firefox
So seems that going back to default configuration fixed for a bit ublock. But adding lists seems to break it (I really don't have time to debug this further). Trying now with umatrix instead and seems to work without any issues. Just in case someone has the same problem. Regards, --- Oriol Demaria 2FFED630C16E4FF8 On 04/12/2018 14:16, Oriol Demaria wrote: So over the weekend I noticed that Ublock Origin is not working for me anymore on firefox since the last upgrade. I have tried to debug with ktrace to figure out why. Checked the list, but found only someone having issues with pledge over some unusual configuration. Has anyone else had this problem? Any advice on debugging this issue? Thanks in advance.
Re: iked : pf.conf rule for outgoing traffic
> I'm confused how to replace "$some_address". Isn't it "(egress)" ? "(egress)" or your_WAN_IP On Fri, 7 Dec 2018 10:00:07 +0100 Thuban wrote: > * Stuart Henderson le [06-12-2018 13:44:50 +]: > > On 2018-12-06, Thuban wrote: > > > * Thuban le [02-12-2018 19:16:09 +0100]: > > >> Hi, > > >> I need help to write a correct rule in pf.conf. > > >> > > >> I want : > > >> > > >> A -> B --> web > > >> > > >> The appearing IP of A is the B's one on the web. > > >> > > >> I managed to configure iked on A and B using default pubkeys according > > >> to Stuart Henderson advices. > > >> > > >> iked.conf on A : > > >> > > >> ikev2 active ipcomp esp \ > > >> from 192.168.100.0/16 to 0.0.0.0/0 \ > > >> peer "xx.xx.xx.xx" \ > > >> srcid "m...@moria.lan" \ > > >> dstid "B-hostname.tld" \ > > >> tag IKED > > >> > > >> iked.conf on B : > > >> > > >> ikev2 "warrior" passive esp \ > > >> from 0.0.0.0/0 to 0.0.0.0/0 \ > > >> local xx.xx.xx.xx peer any \ > > >> srcid "B-hostname.tld" \ > > >> tag IKED > > >> > > >> Auth works as expected : > > >> > > >> # iked -vvd > > >> .. > > >> sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to > > >> 192.168.100.122:4500 policy 'policy1' > > >> .. > > >> > > >> > > >> But I can't reach internet from A through B. > > >> > > >> Here is the pf.conf on B (at least a small part of it) > > >> > > >> pass out on egress \ > > >> from any to any tagged IKED \ > > >> nat-to (egress) > > >> > > >> > > > > > > I'm still stuck at the same point. > > > Can someone give me an example of a working configuration natting ot > > > Internet? > > > > I used this, > > > > pass in on enc0 inet from $some_net > > pass out quick on egress inet received-on enc0 nat-to $some_address > > > > Also I don't remember what you've already said you checked, but > > make sure you have sysctl net.inet.ip.forwarding=1. > > > > Thank you. > Yes, I do have ip.forwarding=1. > > I'm confused how to replace "$some_address". Isn't it "(egress)" ? > > Regards. > -- radek
Re: default terminal autoload disable afater xenodm login
.spectrwm.conf should contain or commented it out: ... autorun = ws[1]:/usr/X11R6/bin/xterm -bg black -fg white +sb ... to fix unexpected terminals load after xenodm login. On 12/7/2018 7:59 PM, Anthony Campbell wrote: > On 07 Dec 2018, Denis wrote: >> Additional terminal loads by spectrwm because of config settings. >> >> Fixed it already. >> >> On 12/6/2018 9:33 PM, Denis wrote: >>> After changing X Display Manager to xenodm + spectrwm as win manager I >>> have an additional terminal load just after xenodm login. >>> >>> I've disabled 'xconsole' in /etc/X11/xenodm/Xsetup_0 by commenting it. >>> >>> # cat ~/.xsessinon >>> export ENV=$HOME/.kshrc >>> xsetroot -solid grey & >>> xterm -bg black -fg white +sb & >>> /usr/local/bin/spectrwm >>> >>> After login I have one xterm with black background, and the second one >>> (xconsole) I want to disable. It loads by default once login is accepted. >>> >>> Please advice to do that >>> > > > Thanks for posting this - been bugging me for weeks. >
Re: sh /etc/netstart interface counter intuitive behaviour with multiple inet aliases 6.4 and 6.3
I have tried '-inet' on 6.3/i386 firewall/GW/VPN/etc.. adding 4 aliases (public
IPs) and then removing 2 of them. If_driver was vr(4). I did it few times over
SSH without any meltdown of the network. Everything seems to work as expected.
$ cat /etc/hostname.vr0
-inet
inet A.B.C.77 255.255.254.0
inet alias A.B.C.76 255.255.255.255 NONE description "Alias76"
inet alias A.B.C.75 255.255.255.255 NONE description "Alias75"
inet alias A.B.C.74 255.255.255.255 NONE description "Alias74"
inet alias A.B.C.73 255.255.255.255 NONE description "Alias73"
On Sat, 8 Dec 2018 06:48:35 +1100
tomr wrote:
>
>
> On 12/8/18 6:09 AM, Tom Smyth wrote:
> > Hi Florian,
> >
> > i had the inet address as the first line ...
> > and then all the inet alias lines were after that...
> > the behaviour was as described...
> > Thanks for the suggestion though
> > On Fri, 7 Dec 2018 at 18:48, Florian Obser wrote:
>
> I think Florian was saying you could use '-inet' to remove *all* inet
> addresses first, different to what you probably have already.
>
> Maybe something like the following would work to remove any aliases not
> set explicitly in hostname.if (with reduced risk of melting the network)
>
> in hostname.vio4:
> !/usr/local/bin/clean_ifaliases.sh \$if
>
> in /usr/local/bin/clean_ifaliases.sh:
> #!/bin/ksh
> for addr in $(ifconfig $1 | awk '/^[[:blank:]]inet/ {print $2}') ; do
> egrep "^(alias|inet) $addr" /etc/hostname.$1 >/dev/null || ifconfig $1
> delete $addr ; done
>
>
>
> hth
>
>
> >> One possible workaround is putting
> >> -inet as the first line in /etc/hostname.vio4
> >> It will nuke all v4 addresses and re-add them.
> >>
> >> Depending on your usecase this might work for you or it might melt
> >> down your whole network ;)
> >>
> >> On Thu, Dec 06, 2018 at 10:49:01PM +, Tom Smyth wrote:
> >>> Hello,
> >>>
> >>> Im running a router with multiple ips on an interface using the
> >>> inet alias
> >>>
> >>> issue:
> >>> when commenting out configured aliases on hostname.if
> >>> after running sh /etc/netstart vio4
> >>>
> >>> if you run ifconfig vio4 after the restart of the interface
> >>> the old aliases that were commented still appear in ifconfig output ahead
> >>> of the first ip address configured in the /etc/hostname.vio4 file.
> >>>
> >>> ifconfig before commenting out 10.134.91.253 in hostname.vio4
> >>> is listed below
> >>> vio4: flags=8843 mtu 1500
> >>> lladdr 16:2c:a4:f2:b4:e3
> >>> index 5 priority 0 llprio 3
> >>> media: Ethernet autoselect
> >>> status: active
> >>> inet 10.94.0.1 netmask 0x broadcast 10.94.255.255
> >>> inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67
> >>> inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71
> >>> inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75
> >>> inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87
> >>> inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91
> >>> inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95
> >>> inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163
> >>> inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167
> >>> inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171
> >>> inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175
> >>> inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195
> >>> inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199
> >>> inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203
> >>> inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207
> >>> inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211
> >>> inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215
> >>> inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219
> >>> inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223
> >>> inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227
> >>> inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231
> >>> inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235
> >>> inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239
> >>> inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243
> >>> inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247
> >>> inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251
> >>> inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255
> >>>
> >>>
> >>> after commenting out the last 2 inet aliases , and running sh
> >>> /etc/netstart vio4
> >>>
> >>> the ifconfig output is as follows (i have highlighted with *** the
> >>> addresses
> >>> which I think should have been removed
> >>>
> >>> vio4: flags=8843 mtu 1500
> >>>
Re: default terminal autoload disable afater xenodm login
On 07 Dec 2018, Denis wrote: > Additional terminal loads by spectrwm because of config settings. > > Fixed it already. > > On 12/6/2018 9:33 PM, Denis wrote: > > After changing X Display Manager to xenodm + spectrwm as win manager I > > have an additional terminal load just after xenodm login. > > > > I've disabled 'xconsole' in /etc/X11/xenodm/Xsetup_0 by commenting it. > > > > # cat ~/.xsessinon > > export ENV=$HOME/.kshrc > > xsetroot -solid grey & > > xterm -bg black -fg white +sb & > > /usr/local/bin/spectrwm > > > > After login I have one xterm with black background, and the second one > > (xconsole) I want to disable. It loads by default once login is accepted. > > > > Please advice to do that > > Thanks for posting this - been bugging me for weeks. -- Anthony Campbellhttp://www.acampbell.uk
Re: sh /etc/netstart interface counter intuitive behaviour with multiple inet aliases 6.4 and 6.3
One possible workaround is putting -inet as the first line in /etc/hostname.vio4 It will nuke all v4 addresses and re-add them. Depending on your usecase this might work for you or it might melt down your whole network ;) On Thu, Dec 06, 2018 at 10:49:01PM +, Tom Smyth wrote: > Hello, > > Im running a router with multiple ips on an interface using the > inet alias > > issue: > when commenting out configured aliases on hostname.if > after running sh /etc/netstart vio4 > > if you run ifconfig vio4 after the restart of the interface > the old aliases that were commented still appear in ifconfig output ahead > of the first ip address configured in the /etc/hostname.vio4 file. > > ifconfig before commenting out 10.134.91.253 in hostname.vio4 > is listed below > vio4: flags=8843 mtu 1500 > lladdr 16:2c:a4:f2:b4:e3 > index 5 priority 0 llprio 3 > media: Ethernet autoselect > status: active > inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 > inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 > inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 > inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 > inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 > inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 > inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 > inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 > inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 > inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 > inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 > inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 > inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 > inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 > inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 > inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211 > inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215 > inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219 > inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223 > inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227 > inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231 > inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235 > inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239 > inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243 > inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247 > inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 > inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 > > > after commenting out the last 2 inet aliases , and running sh /etc/netstart > vio4 > > the ifconfig output is as follows (i have highlighted with *** the addresses > which I think should have been removed > > vio4: flags=8843 mtu 1500 > lladdr 16:2c:a4:f2:b4:e3 > index 5 priority 0 llprio 3 > media: Ethernet autoselect > status: active > ** inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 > ** inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 > inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 > inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 > inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 > inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 > inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 > inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 > inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 > inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 > inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 > inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 > inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 > inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 > inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 > inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 > inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 > inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211 > inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215 > inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219 > inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223 > inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227 > inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231 >
Re: sh /etc/netstart interface counter intuitive behaviour with multiple inet aliases 6.4 and 6.3
On 12/8/18 6:09 AM, Tom Smyth wrote:
> Hi Florian,
>
> i had the inet address as the first line ...
> and then all the inet alias lines were after that...
> the behaviour was as described...
> Thanks for the suggestion though
> On Fri, 7 Dec 2018 at 18:48, Florian Obser wrote:
I think Florian was saying you could use '-inet' to remove *all* inet
addresses first, different to what you probably have already.
Maybe something like the following would work to remove any aliases not
set explicitly in hostname.if (with reduced risk of melting the network)
in hostname.vio4:
!/usr/local/bin/clean_ifaliases.sh \$if
in /usr/local/bin/clean_ifaliases.sh:
#!/bin/ksh
for addr in $(ifconfig $1 | awk '/^[[:blank:]]inet/ {print $2}') ; do
egrep "^(alias|inet) $addr" /etc/hostname.$1 >/dev/null || ifconfig $1
delete $addr ; done
hth
>> One possible workaround is putting
>> -inet as the first line in /etc/hostname.vio4
>> It will nuke all v4 addresses and re-add them.
>>
>> Depending on your usecase this might work for you or it might melt
>> down your whole network ;)
>>
>> On Thu, Dec 06, 2018 at 10:49:01PM +, Tom Smyth wrote:
>>> Hello,
>>>
>>> Im running a router with multiple ips on an interface using the
>>> inet alias
>>>
>>> issue:
>>> when commenting out configured aliases on hostname.if
>>> after running sh /etc/netstart vio4
>>>
>>> if you run ifconfig vio4 after the restart of the interface
>>> the old aliases that were commented still appear in ifconfig output ahead
>>> of the first ip address configured in the /etc/hostname.vio4 file.
>>>
>>> ifconfig before commenting out 10.134.91.253 in hostname.vio4
>>> is listed below
>>> vio4: flags=8843 mtu 1500
>>> lladdr 16:2c:a4:f2:b4:e3
>>> index 5 priority 0 llprio 3
>>> media: Ethernet autoselect
>>> status: active
>>> inet 10.94.0.1 netmask 0x broadcast 10.94.255.255
>>> inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67
>>> inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71
>>> inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75
>>> inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87
>>> inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91
>>> inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95
>>> inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163
>>> inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167
>>> inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171
>>> inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175
>>> inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195
>>> inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199
>>> inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203
>>> inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207
>>> inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211
>>> inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215
>>> inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219
>>> inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223
>>> inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227
>>> inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231
>>> inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235
>>> inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239
>>> inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243
>>> inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247
>>> inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251
>>> inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255
>>>
>>>
>>> after commenting out the last 2 inet aliases , and running sh /etc/netstart
>>> vio4
>>>
>>> the ifconfig output is as follows (i have highlighted with *** the
>>> addresses
>>> which I think should have been removed
>>>
>>> vio4: flags=8843 mtu 1500
>>> lladdr 16:2c:a4:f2:b4:e3
>>> index 5 priority 0 llprio 3
>>> media: Ethernet autoselect
>>> status: active
>>> ** inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251
>>> ** inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255
>>> inet 10.94.0.1 netmask 0x broadcast 10.94.255.255
>>> inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67
>>> inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71
>>> inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75
>>> inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87
>>> inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91
>>> inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95
>>>
Re: sh /etc/netstart interface counter intuitive behaviour with multiple inet aliases 6.4 and 6.3
Hi Florian, i had the inet address as the first line ... and then all the inet alias lines were after that... the behaviour was as described... Thanks for the suggestion though On Fri, 7 Dec 2018 at 18:48, Florian Obser wrote: > > One possible workaround is putting > -inet as the first line in /etc/hostname.vio4 > It will nuke all v4 addresses and re-add them. > > Depending on your usecase this might work for you or it might melt > down your whole network ;) > > On Thu, Dec 06, 2018 at 10:49:01PM +, Tom Smyth wrote: > > Hello, > > > > Im running a router with multiple ips on an interface using the > > inet alias > > > > issue: > > when commenting out configured aliases on hostname.if > > after running sh /etc/netstart vio4 > > > > if you run ifconfig vio4 after the restart of the interface > > the old aliases that were commented still appear in ifconfig output ahead > > of the first ip address configured in the /etc/hostname.vio4 file. > > > > ifconfig before commenting out 10.134.91.253 in hostname.vio4 > > is listed below > > vio4: flags=8843 mtu 1500 > > lladdr 16:2c:a4:f2:b4:e3 > > index 5 priority 0 llprio 3 > > media: Ethernet autoselect > > status: active > > inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 > > inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 > > inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 > > inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 > > inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 > > inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 > > inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 > > inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 > > inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 > > inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 > > inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 > > inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 > > inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 > > inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 > > inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 > > inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211 > > inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215 > > inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219 > > inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223 > > inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227 > > inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231 > > inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235 > > inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239 > > inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243 > > inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247 > > inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 > > inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 > > > > > > after commenting out the last 2 inet aliases , and running sh /etc/netstart > > vio4 > > > > the ifconfig output is as follows (i have highlighted with *** the > > addresses > > which I think should have been removed > > > > vio4: flags=8843 mtu 1500 > > lladdr 16:2c:a4:f2:b4:e3 > > index 5 priority 0 llprio 3 > > media: Ethernet autoselect > > status: active > > ** inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 > > ** inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 > > inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 > > inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 > > inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 > > inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 > > inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 > > inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 > > inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 > > inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 > > inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 > > inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 > > inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 > > inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 > > inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 > > inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 > > inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 > > inet 10.134.91.209 netmask
Re: ikev2 and road warriors setup
Hello,
I am still almost in the same point.
If I want to reach my GW88_LAN I have to check "use default gateway on remote
network" box (Windows roadwarrior), but this option makes me reaching the
internet through GW88.
I want to use VPN GW88 to access 192.168.2.0/24 ONLY and roadwarrior's "local"
gateway for the rest of the traffic - unchecked box "use default gateway on
remote network".
If the box is unchecked I am not able to access 192.168.2.0/24.
What should I change in my confs to get it working in this manner?
GW88# grep "^[^#;]" /etc/pf.conf
set skip on {lo, enc}
match in all scrub (no-df random-id)
match out all scrub (no-df random-id)
match out on egress from lan:network to any nat-to egress
block log all
pass out quick on egress inet received-on enc0 nat-to (egress)
pass in on egress proto udp from any to (egress:0) port {isakmp,ipsec-nat-t}
pass in on egress proto {ah,esp}
pass out on egress
pass on lan
GW88# grep "^[^#;]" /etc/iked.conf
ikev2 "roadWarrior" passive esp \
from 0.0.0.0/0 to 10.0.1.0/24 \
from 192.168.2.0/24 to 10.0.1.0/24 \
local 4.5.6.88 peer any \
srcid 4.5.6.88 \
config address 10.0.1.0/24 \
config netmask 255.255.255.0 \
config name-server 8.8.8.8
On Fri, 30 Nov 2018 15:06:28 +0100
Radek wrote:
> Hello,
>
> Thank all of you for your time and your help in this matter!
> I think that the ISP of A.B.C.0/23 is filtering/blocking some certificates.
> I have moved VPN server and clients out of A.B.C.0/23. They can connect
> pretty fine using CA now. Clients from A.B.C.0/23 still can NOT connect to
> VPN serv.
> Site-to-Site VPN is doing its job.
>
> The road_warriors(Windows) can ping GW88_LAN_machine (192.168.2.1) ONLY if
> "use default gateway on remote network" is set.
> I need to make road_warriors:
> - reaching GW88_LAN_machines 192.168.2.254/24
> - reaching GW119_LAN_machines 172.16.X.X via GW88 - if it is possible
> - force road_warriors to use its own gateway for the rest of traffic -
> unticked "use default gateway on remote network".
>
> I was playing around with iked.conf and pf.conf but I did not find the way to
> make it work.
> I will be grateful if anyone could help me with that.
>
> My network diagram and configs of GW88:
>
> GW88$ cat /etc/hostname.enc0
> inet 10.0.1.254 255.255.255.0
>
> GW88$ cat /etc/iked.conf
> #
> ikev2 "roadWarrior" passive esp \
> from 192.168.2.0/24 to 10.0.1.0/24 \
> local 4.5.6.88 peer any \
> srcid 4.5.6.88 \
> config address 10.0.1.0/24
> #
> #
> remote_gw_GW119 = "1.2.3.119" # fw_GW119
> remote_lan_GW119_1 = "172.16.1.0/24"
> remote_lan_GW119_2 = "172.16.2.0/24"
>
> local_gw_GW88_2 = "192.168.2.254"
> local_lan_GW88_2 = "192.168.2.0/24"
>
> ikev2 active esp from $local_gw_GW88_2 to $remote_gw_GW119 \
> from $local_lan_GW88_2 to $remote_lan_GW119_1 peer $remote_gw_GW119 \
> psk "pkspass"
>
> ikev2 active esp from $local_gw_GW88_2 to $remote_gw_GW119 \
> from $local_lan_GW88_2 to $remote_lan_GW119_2 peer $remote_gw_GW119 \
> psk "pskpass"
>
>
> GW88$ cat /etc/pf.conf
> set skip on {lo, enc}
>
> match in all scrub (no-df random-id)
> match out all scrub (no-df random-id)
>
> match out on egress from lan:network to any nat-to egress
>
> block log all
> pass in on egress proto udp from any to any port {isakmp,ipsec-nat-t}
> pass in on egress proto {ah,esp}
> pass out on egress
> pass on lan
>
> table persist counters
> pass in on egress proto tcp from { 1.2.3.119 A.B.C.0/23 } to port ssh flags
> S/SA \
> set prio (6, 7) keep state \
> (max-src-conn 15, max-src-conn-rate 2/10, overload
> flush global)
>
> icmp_types = "{ echoreq, unreach }"
> pass inet proto icmp all icmp-type $icmp_types
>
>
>
>++
>|road_warrior|
> +-+10.0.1.0/24 |
> | ++
> |
>ikev2
> |
> |
> v
>
> 4.5.6.881.2.3.119
> +-+ +--+
> | |
> | GW88 | <--+site-to-site VPN+--> | GW119 |
> +--+--+ +---+--+
>| |
>+-+192.168.1.254/24 |
>| |
>| 172.16.1.254/24---+
>| |
>+---+-+192.168.2.254/24 |
>| | |
>| | +---+ |
>| +---+192.168.2.1| 172.16.2.254/24---|
>| ++
>|
>|+192.168.3.254/24
>
> Thanks!
>
> On Thu, 8 Nov 2018 14:04:23 +0100
> Radek wrote:
>
> > I've been playing around with netcat.
> > I noticed that the netcat process on my VPN_server does not show any "X" on
> > stdout for ports 4500 and 1701.
> >
>
Re: Pass, gpg2, gpg
On Fri, Dec 07, 2018 at 04:33:36PM +0100, Lucas López wrote: > > I can deduce pass command uses gpg2 command which in turn uses gpg command. > The issue is *gpg is always in batch mode*, so if I want to use pass, I > have to manually decrypt something directly using gpg2 (gpg2 -d bla -> > prompt for passphrase). This way pass is usable as one would expect. In my understanding gpg and gpg2 are two different programs. Thus for pass to work you need to setup your keys in gpg2 or import them from gpg. For me pass and gpg2 worked out-of-the-box as expected. Kai signature.asc Description: PGP signature
Re: Pflow granularity
Hi have you tried the diff by yourself ? i cant remember. someone else was working on that at the same time bck then, if i remember correctly. But it might still work. If it does, report back, i might pick the topic up again. I patched it yesterday night and it seems work. i have an issue with udp flows sometimes. the flow data comes multiple times. but i have no idea yet. Thomas /Benno Diese Nachricht wurde versandt mit Webmail von www.tbits.net. This message was sent using webmail of www.tbits.net.
OpenBSD install on a g5 imac power pc
Installed openbsd on a model A1058, imac g5. The install was uneventful. However, I cannot boot to it. I've tried what the documentation says for booting off the HD using open prom and the error is that /bsd does not exist. I'm going off memory now. Is anyone running off a g5? Yudhvir
net/unifi fails to start
Hello,
I just got my hands on some Ubiquity kit, and I wanted to try running
the Unifi Controller software on OpenBSD. I installed the port (there's
no unifi package due to licence issues). When I start unifi (rcctl start
unifi) it seems to start ok, but unfortunately the web interface doesn't
actually load. When I look at the unifi logs, I see this error:
" WARN system - cannot load native lib - ubnt_webrtc_jni"
I tried the lts and stable versions of the port on both OpenBSD 6.4 and
-current, both to no avail. Attached is the mongodb and unifi logs.
Has anyone had any luck running the unifi software on OpenBSD?
Any insight would be much appreciated.
Jordan
2018-12-07T15:53:14.278-0800 I CONTROL [initandlisten] MongoDB starting : pid=12100 port=27117 dbpath=/usr/local/share/unifi/data/db 64-bit host=lenovo.geoghegan.ca
2018-12-07T15:53:14.279-0800 I CONTROL [initandlisten] db version v3.2.13
2018-12-07T15:53:14.279-0800 I CONTROL [initandlisten] git version: 23899209cad60aaafe114f6aea6cb83025ff51bc
2018-12-07T15:53:14.279-0800 I CONTROL [initandlisten] OpenSSL version: LibreSSL 2.8.2
2018-12-07T15:53:14.279-0800 I CONTROL [initandlisten] allocator: system
2018-12-07T15:53:14.279-0800 I CONTROL [initandlisten] modules: none
2018-12-07T15:53:14.279-0800 I CONTROL [initandlisten] build environment:
2018-12-07T15:53:14.279-0800 I CONTROL [initandlisten] distarch: x86_64
2018-12-07T15:53:14.279-0800 I CONTROL [initandlisten] target_arch: x86_64
2018-12-07T15:53:14.279-0800 I CONTROL [initandlisten] options: { net: { bindIp: "127.0.0.1", http: { enabled: false }, port: 27117, unixDomainSocket: { pathPrefix: "/usr/local/share/unifi/run" } }, storage: { dbPath: "/usr/local/share/unifi/data/db" }, systemLog: { destination: "file", logAppend: true, path: "/usr/local/share/unifi/logs/mongod.log" } }
2018-12-07T15:53:14.292-0800 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=1G,session_max=2,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=10),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
2018-12-07T15:53:14.502-0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/usr/local/share/unifi/data/db/diagnostic.data'
2018-12-07T15:53:14.503-0800 I NETWORK [initandlisten] waiting for connections on port 27117
2018-12-07T15:53:14.503-0800 I NETWORK [HostnameCanonicalizationWorker] Starting hostname canonicalization worker
2018-12-07T15:53:14.505-0800 W NETWORK [HostnameCanonicalizationWorker] Failed to obtain address information for hostname lenovo.geoghegan.ca: no address associated with name
2018-12-07T15:53:14.609-0800 I NETWORK [initandlisten] connection accepted from 127.0.0.1:12297 #1 (1 connection now open)
2018-12-07T15:53:14.690-0800 I NETWORK [initandlisten] connection accepted from 127.0.0.1:41869 #2 (2 connections now open)
2018-12-07T15:53:15.128-0800 I COMMAND [conn2] command ace command: eval { $eval: "db.serverStatus()", args: [] } keyUpdates:0 writeConflicts:0 numYields:0 reslen:12691 locks:{ Global: { acquireCount: { r: 3, W: 1 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 368ms
2018-12-07T15:53:15.270-0800 I INDEX[conn2] build index on: ace.heatmap properties: { v: 1, key: { site_id: 1 }, name: "site_id_1", ns: "ace.heatmap" }
2018-12-07T15:53:15.270-0800 I INDEX[conn2] building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2018-12-07T15:53:15.297-0800 I INDEX[conn2] build index done. scanned 0 total records. 0 secs
2018-12-07T15:53:15.317-0800 I INDEX[conn2] build index on: ace.heatmap properties: { v: 1, key: { site_id: 1, map_id: 1 }, name: "map_id_1_site_id_1", ns: "ace.heatmap" }
2018-12-07T15:53:15.318-0800 I INDEX[conn2] building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2018-12-07T15:53:15.319-0800 I INDEX[conn2] build index done. scanned 0 total records. 0 secs
2018-12-07T15:53:15.331-0800 I INDEX[conn2] build index on: ace.heatmap properties: { v: 1, key: { site_id: 1, type: 1 }, name: "site_id_1_type_1", ns: "ace.heatmap" }
2018-12-07T15:53:15.331-0800 I INDEX[conn2] building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2018-12-07T15:53:15.333-0800 I INDEX[conn2] build index done. scanned 0 total records. 0 secs
2018-12-07T15:53:15.351-0800 I INDEX[conn2] build index on: ace.extension properties: { v: 1, key: { site_id: 1 }, name: "site_id_1", ns: "ace.extension" }
2018-12-07T15:53:15.351-0800 I INDEX[conn2] building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2018-12-07T15:53:15.353-0800 I INDEX[conn2] build index done. scanned 0 total records. 0 secs
2018-12-07T15:53:15.369-0800 I INDEX[conn2] build index
Re: radeon driver bug?
I installed Ubuntu 18.04 to a AMD 6450 graphic card, and played Jahshaka. It has mesa version 18.2, and runs Jahshaka very smoothly. The colors I reported before are same in this machine, so that report was not correct. Kenji 2018年12月7日(金) 11:09 岡本健二 : > I checked mesa-18.3.0 sources under src/gallium/drivers/r600 and compared > with those > of xenocara. File names are all same, however, individual sizes are very > different for > most of those, which would not permit me to copy those to xenocara... > > Kenji > > > 2018年12月6日(木) 15:14 岡本健二 : > >> also, it stull has some bugs, because the colors of some >> parts are different from those of original ones. >> >> Kenji >> >> >> 2018年12月6日(木) 15:10 岡本健二 : >> >>> Sorry, I'm a novice to OpenBSD. >>> Yes, it's current branch of xenocara. >>> I updated my xenocara (stable) to that current, and build new xenocara >>> here. >>> >>> Wow, it makes the Jahshaka works! >>> >>> However, it still has some bugs, because it moves and stop suddenly and >>> then >>> move again. Whine the animation stops, the system seems to halting... >>> >>> Anyway it makes much advance, I included the screenshot of it. >>> >>> Kenji >>> >>> PS: sorry tfrohwein, this is doubled to you >>> >>> 2018年12月6日(木) 13:26 岡本健二 : >>> in-current means stable 6.4? Kenji 2018年12月5日(水) 23:58 tfrohw...@fastmail.com : > On December 5, 2018 9:41:44 AM UTC, "岡本健二" wrote: > >This errors come from > >/usr/xenocara/lib/mesa/src/gallium/drivers/r600/r600_state_common.c. > >The mesa version of OpenBSD6.4 is 13.0.6. > >I'm running this Jahshaka on Ubutu 18.04, where the mesa version is > >18.x. > > > >So, it may be the mesa problem... > > > >Kenji > > > > > >2018年12月4日(火) 16:19 岡本健二 : > > > >> I'm using AMD HD6450 graphic card which I reported before, and faced > >a > >> curious thing > >> during running Jahshaka Studio (dev version 7.03a). > >> To run Jahshaka on OpenBSD 6.4 I needed to delete google breakpad > >> temporally, which > >> is not the problem now. > >> > >> After start to run 'Jahshaka Studio', I got start 3D animation > sample > >> 'Skeletal Animation' data to load, then > >> I got many errors included below which seems to come from radeon drm > >> driver's bug to me. > >> If you interested please check it. > >> > >> Thanks in advance > >> > >> Kenji > >> > >> > > There's a known bug where the shader on r600 uses too many registers: > > https://bugs.freedesktop.org/show_bug.cgi?id=99349 > > I encountered this bug with godot on a Radeon HD 7570, too, and it > went away with the updated mesa that's in -current. >
Re: default terminal autoload disable afater xenodm login
Additional terminal loads by spectrwm because of config settings. Fixed it already. On 12/6/2018 9:33 PM, Denis wrote: > After changing X Display Manager to xenodm + spectrwm as win manager I > have an additional terminal load just after xenodm login. > > I've disabled 'xconsole' in /etc/X11/xenodm/Xsetup_0 by commenting it. > > # cat ~/.xsessinon > export ENV=$HOME/.kshrc > xsetroot -solid grey & > xterm -bg black -fg white +sb & > /usr/local/bin/spectrwm > > After login I have one xterm with black background, and the second one > (xconsole) I want to disable. It loads by default once login is accepted. > > Please advice to do that >
Re: iked : pf.conf rule for outgoing traffic
* Stuart Henderson le [06-12-2018 13:44:50 +]: > On 2018-12-06, Thuban wrote: > > * Thuban le [02-12-2018 19:16:09 +0100]: > >> Hi, > >> I need help to write a correct rule in pf.conf. > >> > >> I want : > >> > >> A -> B --> web > >> > >> The appearing IP of A is the B's one on the web. > >> > >> I managed to configure iked on A and B using default pubkeys according > >> to Stuart Henderson advices. > >> > >> iked.conf on A : > >> > >>ikev2 active ipcomp esp \ > >>from 192.168.100.0/16 to 0.0.0.0/0 \ > >>peer "xx.xx.xx.xx" \ > >>srcid "m...@moria.lan" \ > >>dstid "B-hostname.tld" \ > >>tag IKED > >> > >> iked.conf on B : > >> > >>ikev2 "warrior" passive esp \ > >>from 0.0.0.0/0 to 0.0.0.0/0 \ > >>local xx.xx.xx.xx peer any \ > >>srcid "B-hostname.tld" \ > >>tag IKED > >> > >> Auth works as expected : > >> > >> # iked -vvd > >> .. > >> sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to > >> 192.168.100.122:4500 policy 'policy1' > >> .. > >> > >> > >> But I can't reach internet from A through B. > >> > >> Here is the pf.conf on B (at least a small part of it) > >> > >> pass out on egress \ > >> from any to any tagged IKED \ > >> nat-to (egress) > >> > >> > > > > I'm still stuck at the same point. > > Can someone give me an example of a working configuration natting ot > > Internet? > > I used this, > > pass in on enc0 inet from $some_net > pass out quick on egress inet received-on enc0 nat-to $some_address > > Also I don't remember what you've already said you checked, but > make sure you have sysctl net.inet.ip.forwarding=1. > Thank you. Yes, I do have ip.forwarding=1. I'm confused how to replace "$some_address". Isn't it "(egress)" ? Regards.
