Re: IPv6 ULA routing stops working after 20 hours or so
Sorry for top post. Are you doing any filtering of ICMP6 with PF? I assume your router is also doing rad to hand out slaac to clients? Jason. Sent from my iPhone > On 23 Jun 2024, at 2:27 AM, Thomas Bohl wrote: > > Hello, > > I'm using ULAs for my local IPv6 networks. The hosts have internet access via > the router doing NPTv6. > > After around 20 to 24 hours of uptime the OpenBSD hosts (three in total) are > no longer able to reach the IPv6 internet. A restart of the affected hosts > usually helps. In rare cases a double restart is required. Linux and Windows > don't show this problem. > > Any ideas? What information should I provide in order to debug this further? > > # uname -a > OpenBSD mail1 7.5 GENERIC#79 amd64 > > # cat /etc/hostname.vio0 > # BEGIN ANSIBLE MANAGED BLOCK IPv6 > inet6 -soii > inet6 autoconf > # END ANSIBLE MANAGED BLOCK IPv6 > # BEGIN ANSIBLE MANAGED BLOCK IPv4 > inet 172.17.17.2 255.255.255.252 > !route add default 172.17.17.1 > # END ANSIBLE MANAGED BLOCK IPv4 > > > When things are working: > > # uptime > 5:11PM up 9 mins, 1 user, load averages: 0.00, 0.01, 0.00 > > > # ifconfig vio0 > vio0: > flags=648843 > mtu 1500 > lladdr bc:24:11:10:52:72 > index 1 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect > status: active > inet6 fe80::be24:11ff:fe10:5272%vio0 prefixlen 64 scopeid 0x1 > inet 172.17.17.2 netmask 0xfffc broadcast 172.17.17.3 > inet6 fd00:172:17:170:be24:11ff:fe10:5272 prefixlen 64 autoconf > pltime 604644 vltime 2591844 > inet6 fd00:172:17:170:1fa3:a3db:db4a:707d prefixlen 64 autoconf > temporary pltime 74422 vltime 172248 > > > # ping6 -vn -c 3 google.com > PING google.com (fd00:172:17:170:1fa3:a3db:db4a:707d --> > 2a00:1450:4005:801::200e): 56 data bytes > 64 bytes from 2a00:1450:4005:801::200e: icmp_seq=0 hlim=114 time=27.533 ms > 64 bytes from 2a00:1450:4005:801::200e: icmp_seq=1 hlim=114 time=30.263 ms > 64 bytes from 2a00:1450:4005:801::200e: icmp_seq=2 hlim=114 time=30.143 ms > > --- google.com ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 27.533/29.313/30.263/1.260 ms > > > # traceroute6 -vn google.com > traceroute6 to google.com (2a00:1450:4005:801::200e), 64 hops max, 60 byte > packets > 1 fd00:172:17:170:2a0:57ff:fe3a:ac77 68 bytes to > fd00:172:17:170:1fa3:a3db:db4a:707d 0.227 ms 0.159 ms 0.136 ms > 2 2a02:810d:1:bf::3 68 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d 13.606 > ms 2a02:810d:1:bf::2 68 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d 15.823 > ms 2a02:810d:1:bf::3 68 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d 14.467 ms > 3 * * * > 4 * * * > 5 * * * > 6 2001:4860:1:1::2a4 68 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d > 16.263 ms 12.806 ms 14.327 ms > 7 * 2001:4860:0:1::839f 68 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d > 15.828 ms * > 8 * * * > 9 2001:4860::c:4003:4958 152 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d > 27.715 ms 29.765 ms 30.264 ms > 10 2001:4860::c:4002:f990 152 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d > 31.119 ms 2001:4860::c:4002:f991 152 bytes to > fd00:172:17:170:1fa3:a3db:db4a:707d 29.906 ms 2001:4860::c:4002:f990 152 > bytes to fd00:172:17:170:1fa3:a3db:db4a:707d 36.316 ms > 11 2001:4860::c:4001:ebf 152 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d > 29.679 ms 2001:4860::c:4002:7869 152 bytes to > fd00:172:17:170:1fa3:a3db:db4a:707d 33.901 ms 31.045 ms > 12 2001:4860::9:4001:ecb 68 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d > 29.68 ms 2001:4860::9:4001:ec0 68 bytes to > fd00:172:17:170:1fa3:a3db:db4a:707d 29.575 ms 2001:4860::9:4001:ecb 68 bytes > to fd00:172:17:170:1fa3:a3db:db4a:707d 36.681 ms > 13 2001:4860:0:1::6b65 68 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d > 29.283 ms * * > 14 2001:4860:0:1::6b65 68 bytes to fd00:172:17:170:1fa3:a3db:db4a:707d > 30.595 ms 2a00:1450:4005:801::200e 68 bytes to > fd00:172:17:170:1fa3:a3db:db4a:707d 40.122 ms 2001:4860:0:1::6b65 68 bytes > to fd00:172:17:170:1fa3:a3db:db4a:707d 30.369 ms > > > # route -n show -inet6 > Routing tables > > Internet6: > Destination Gateway Flags Refs Use Mtu > Prio Iface > default fe80::2a0:57ff:fe3a:ac77%vio0 UGS08 - 8 > vio0 > ::/96 ::1 UGRS 00 32768 > 8 lo0 > ::1 ::1 UHhl 10 20 32768 1 > lo0 > :::0.0.0.0/96 ::1 UGRS 0 > 0 32768 8 lo0 > 2002::/24 ::1 UGRS 00 32768 > 8 lo0 > 2002:7f00::/24 ::1 UGRS 00 > 32768 8 lo0 > 2002:e000::/20 ::1 UGRS 00 > 32768 8 lo0 > 2002:ff00::/24 ::1
Re: VLAN-tagging, how?
Add to hostname.vlan101 as well: autoconf up Remove dhcp/autoconf from hostname.em0 but make sure there is an ‘up’ in there. If you are using a macro like $ext_if in pf, just change from em0 to vlan101 and all your external interface rules will work like they did before. Cheers Sent from my iPhone > On 31 May 2024, at 1:28 PM, Martin wrote: > > Would this be adequate? > > /etc/hostname.vlan101 > vlandev em0 vnetid 101 > > em0 is the physical interface connected to the fiber box, > it is then setup to get an IP via DHCP. > > Does vlan101 need to be addressed in PF in any way or are > the rules which currently work for em0 enough? > >> Sorry for the non-inline text. >> >> OpenBSD makes this super simple and it is well documented. The flow is to >> bring up your physical interface and then use that as a parent for your >> pseudo vlan interface. >> >> man ifconfig >> >> Move down to the VLAN section and it is well described to provide you with >> the options you need. >> >> Any clarification just yell out. Cheers. >> >> Sent from my iPhone >> On 31 May 2024, at 8:15 AM, Martin i...@protonmail.com wrote: >>> >>> I am currently using a home made router with OpenBSD which is connected >>> directly to my ISP's fiber router. The OpenBSD router is setup with a >>> fixed IP on the WAN port and I do internal NAT etc. >>> >>> In about a month a new ISP is going to provide internet via the fiber >>> and they are changing the equipment. >>> >>> What they have told me is that in order to use my own router, the >>> router has to support VLAN tagging. >>> >>> The statement I got was: >>> >>> "We send traffic out on VLAN 100 so your router needs to be tagged to >>> 100. Then all it has to do is to get an IP via DHCP." >>> >>> I have not done any VLAN stuff before and I am unsure exactly how to do >>> this. >>> >>> Is this possible and how exactly is that done? >>> >>> Thanks. >
Re: VLAN-tagging, how?
Sorry for the non-inline text. OpenBSD makes this super simple and it is well documented. The flow is to bring up your physical interface and then use that as a parent for your pseudo vlan interface. man ifconfig Move down to the VLAN section and it is well described to provide you with the options you need. Any clarification just yell out. Cheers. Sent from my iPhone > On 31 May 2024, at 8:15 AM, Martin wrote: > > I am currently using a home made router with OpenBSD which is connected > directly to my ISP's fiber router. The OpenBSD router is setup with a > fixed IP on the WAN port and I do internal NAT etc. > > In about a month a new ISP is going to provide internet via the fiber > and they are changing the equipment. > > What they have told me is that in order to use my own router, the > router has to support VLAN tagging. > > The statement I got was: > > "We send traffic out on VLAN 100 so your router needs to be tagged to > 100. Then all it has to do is to get an IP via DHCP." > > I have not done any VLAN stuff before and I am unsure exactly how to do > this. > > Is this possible and how exactly is that done? > > Thanks. >
Re: No packages found for 7.5 snapshot on arm64
Try -D snap Cheers Sent from my iPhone > On 9 Mar 2024, at 6:31 pm, ofthecentury wrote: > > I had a similar problem this week, for amd64. > The 'packages/amd64' folder on the OpenBSD > mirrors for 7.5 snapshot is also empty. So I > just manually set PKG_PATH to 7.4 packages > folder for the time being. > >> On Sat, Mar 9, 2024 at 2:15 PM Dmitry Matveyev wrote: >> >> Hi, >> >> I was running an OpenBSD with this description of the iso: OpenBSD >> 7.4-current 2023-11-03 (arm64). A week ago I started getting an error >> trying to install any package: >> >> # pkg_add -Uvi colorls >> Update candidates: quirks-7.12 -> quirks-7.12 >> Update candidates: updatedb-0p0 -> updatedb-0p0 >> quirks-7.12 signed on 2024-03-05T14:52:30Z >> Can't install colorls-7.4 because of libraries >> |library c.99.0 not found >> | /usr/lib/libc.so.98.0 (system): bad major >> Couldn't install colorls-7.4 >> >> Here I have an older version whereas the package requires a newer >> version. >> >> I've read that it might be due to using -current and that I need to >> upgrade my system to the latest snapshot. I have run sysupgrade and now >> uname says that I'm on OpenBSD 7.5 GENERIC.MP#128 arm64. And now I can't >> install anything at all because pkg_add complains that it can't find a >> directory https://ftp.hostserver.de/pub/OpenBSD/7.5/packages/aarch64/. I >> have checked several mirrors at https://www.openbsd.org/ftp.html and >> they indeed don't have any packages under 7.5. >> >> How do I fix this? >> >
Re: Panic in 7.2 and snapshots at boot due to acpi bios error
From: owner-m...@openbsd.org on behalf of Jeff Roach Sent: Monday, 23 January 2023 9:08 PM To: misc@openbsd.org Subject: Panic in 7.2 and snapshots at boot due to acpi bios error Hi! Really love OpenBSD and would like to get it working on my Samsung Galaxy Book Flex2 Alpha. NP730QDA-KA3US. Just offering this up because I can't send a dmesg. I believe it may be a bug in the acpi bios code for which there is no firmware update. It boots, linux, win 10/11, net and freebsds fine with acpi errors. We hit this in the Lenovo ThinkStation m70s Gen 3 during hardware validation. A workaround was provided and allowed for more data to be sent but the workaround was not deemed to be acceptable. Here is the original bug and thread: https://marc.info/?l=openbsd-bugs&m=166674319711567&w=2 Good to see that it isn't only a Lenovo thing.
Re: after upgrade to 6.9, iked does not pass traffic
I have a vpn from a Windows machine to a network behind an OpenBSD router. It was working fine until I upgraded the router to 6.9 (amd64). The VPN is still coming up fine, but the traffic is blocked somehow. Using tcpdump on the interface protected by the router (vlan0 in my case), I see the ping requests from the remote vpn address, and the ping replies, but on enc0 I only see the requests. I confirmed that pf is not blocking packets. doas tcpdump -nni enc0 tcpdump: listening on enc0, link-type ENC 08:48:05.289341 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:09.914843 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:14.914988 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:19.915348 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) ^C 4 packets received by filter 0 packets dropped by kernel tcpdump -nni vlan0 host 192.168.9.208 tcpdump: listening on vlan0, link-type EN10MB 09:12:21.467671 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:21.468371 arp who-has 192.168.9.208 tell 192.168.9.101 09:12:21.468386 arp reply 192.168.9.208 is-at ec:eb:b8:5d:94:a0 09:12:21.468937 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:21.468961 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:26.410587 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:26.411144 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:26.411168 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:31.414257 192.168.9.208 > 192.168.9.101: icmp: echo request It looks like 'keep state (if-bound)' iked.conf(5) is not present or being respected on the return traffic to the VPN device/firewall from your internal network. ICMP traffic is coming into the VPN device encrypted, being decrypted and passed to the destination. The destination responds back but the VPN device is not taking those responses and pushing them back through enc0. We have updated a number of IKEv2 devices already without issue. Our testing environment where we are trying out different configurations and scenarios also working fine. Cheers, Jason.
Re: Redistribution between ospfd and ripd
On Sat, 28 Nov 2020 at 11:14, Sebastian Benoit wrote: > Hi, > > > > route add -label FOOBAR 172.16.1.0/24 172.16.2.5 > route show -label FOOBAR > > I am only aware of these mechanisms to set labels on routes added by > routing daemons: > > bgpd (rtlabel keyword in filter "set") > ospfd/ospf6d (rtlabel label external-tag number) > > Neither would help in your situation. > > Can you explain a bit more what you are planing to do? > Thanks for that Benno. I did see another rtlabel reference in ifconfig(8) but I don't think that will work as expected either https://man.openbsd.org/ifconfig#rtlabel During the migration, there will be OpenBSD routers in the network that will have some routes coming in from OSPF and RIPv2 so both daemons will be running on these hosts so network segments can continue to talk to each other. In the usual commercial offerings, you simply imply what you want to redistribute and this can be another routing protocol, static, connected etc. as the routing stack is aware of other protocols being used. | OSPF 0.0.0.1 | <-> | OpenBSD Router | <-> | RIPv2 | Cheers.
Redistribution between ospfd and ripd
Hi, We are planning for migration from ripd to ospf, however both protocols will need to work together as the migration rolls through. I was looking at the 'redistribute rtlabel' option, even after digging into the code, it is unclear how this would work to bring other dynamic routes on the same host to be redistributed by a different routing protocol. A valid, but not very clean solution would be to add: redistribute 10.0.0/8 redistribute 172.16.0/12 redistribute 192.168.0/16 To both ospfd.conf and ripd.conf What am I missing here or is there a far more elegant way to achieve this? Thanks, Jason.
iked(8) bad-ip-version 7 (encap) error after 6.4 upgrade
I am preparing a bug report but just wanted to flag an issue that I discovered after a 6.3 to 6.4 uplift of an iked(8) endpoint. We overlay vxlan(4) on top of iked(8) to provide seamless connectivity to site offices. I have uplifted our test endpoint to 6.4 and discovered that traffic had tanked, basically 99% of packets were being dropped. Investigations showed it isn't an iked(8) issue as the P-t-P traffic is moving as expected and not throwing the error. As soon as you send traffic over the unicast vxlan tunnel, that is when you see the error. Here is a capture from enc0 on the endpoint: 09:14:42.281342 (authentic,confidential): SPI 0xa093378e: ipcomp 192.168.1.1 > 192.168.1.2 cpi 0x0BCE flags 0 next 4 09:14:42.281396 (authentic,confidential): SPI 0x0bce: 192.168.1.1.4789 > 192.168.1.2.4789: vxlan 35: 10.1.1.1 > 10.1.1.2: icmp: echo request [tos 0x10] (encap) 09:14:42.281430 (unprotected): SPI 0x1a63: 192.168.1.2.4789 > 192.168.1.1.4789: vxlan 35: 10.1.1.2 > 10.1.1.1: icmp: echo reply [tos 0x10] (encap) 09:14:42.281631 (authentic,confidential): SPI 0x03096f78: bad-ip-version 7 (encap) Any configuration advice would be appreciated if it isn't a bug. FYI the main termination device is still 6.3#10 Cheers. Jason.
Re: SNMP reporting on VXLAN interfaces
On Fri, 17 Aug 2018 at 11:48, David Gwynne wrote: > On Thu, Aug 16, 2018 at 10:51:25AM +1000, Jason Tubnor wrote: > > > > > Am I missing something here or could it be a potential bug in the VXLAN > > code in how it reports into snmpd? > > The vxlan driver counts something that the network stack does for it > now. The diff below fixes the problem if you want to try it, but I will > be committing it soon. > > > Thanks David. You got it committed quicker than I could patch it. I can confirm that it is now reporting correctly. Thanks for your help. Cheers, Jason.
SNMP reporting on VXLAN interfaces
Hi, Not sure if anyone else here is using SNMP for obtaining VXLAN(4) adapter throughput but after some testing (clamping with PF queues), I have discovered that throughput on VXLAN interfaces via SNMP are reporting exactly double the data throughput than what is measured either through iperf or pfctl -vvsq . Regular interfaces on the machine below (vmx) are reporting correctly. Am I missing something here or could it be a potential bug in the VXLAN code in how it reports into snmpd? Thanks, Jason. dmesg OpenBSD 6.3 (GENERIC.MP) #8: Sat Aug 4 16:56:56 CEST 2018 r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ GENERIC.MP real mem = 17163026432 (16367MB) avail mem = 16635793408 (15865MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 04/14/2014 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) S1F0(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.19 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache acpitimer0: recalibrated TSC frequency 259020 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 65MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 5 (application processor) cpu5: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 0, core 5, package 0 cpu6 at mainbus0: apid 6 (application processor) cpu6: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu6: 256KB 64b/line 8-way L2 cache cpu6: smt 0, core 6, package 0 cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu7: 256KB 64b/line 8-way L2 cache cpu7: smt 0, core 7, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 11, 24 pins acpimcfg0 at acpi0 addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318179 Hz acpihpet0: recalibrated TSC frequency 255290 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpic
Re: Topics for revised PF and networking tutorial
On 8 April 2017 at 07:41, Mihai Popescu wrote: > I don;t want to offend you folks, but I'm curious and I will ask: is > this BSDCon so useful? Does it pay the efforts? > > If someone has time and knowledge to do a PF tutorial he/she can do it > and post. Do you need the Con? > > I'm traveling 17000km+ to go to the conference. This is my second time. Like other return attendees, tutors and presenters, I get a lot out of these conferences and the networking (excuse the pun) that comes out of it. I've been to other conferences like Cisco Live etc, they charge way, way, way more for the average punter and I don't get anywhere near as much out of those flashy conferences than I get from BSDCan. There is nothing quite like quizzing the minds of advanced users and the developers of the tools that we so often use in person. Those conversations are invaluable and something you just can't get via a mailing list.
Re: OpenBSD 6.1-snapshot boot issues in bhyve
On 5 April 2017 at 13:07, Theo de Raadt wrote: > > > cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3491.87 MHz > > cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3, > PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16,xTPR,PCID,DCA, > SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV, > NXE,PAGE1GB,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT > > cpu0: 256KB 64b/line 8-way L2 cache > > (see SDBG in the long line above?) > > In that case the emulation of that cpu must support the feature it > claims to support, either by having the hardware do it, or by having > the vm code emulate it. It must emulate the MSR's associated with > the feature. > > Or, not make the claim. > > bhyve appears to be passing down feature bits from the host cpu > without sanitizing them. > > I wonder what other features they are passing down some of them > are not really safe > Just a follow-up. New hardware has arrived. This is not a wide ranging issue and appears to only affect some models of CPUs. Below is the output from a bhyve guest running on an Atom C2758 SoC, no modification was made to the bhyve startup: OpenBSD 6.1 (GENERIC.MP) #0: Wed Apr 5 08:47:48 AEST 2017 mrbuil...@cybermen.ar18.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056964608 (1008MB) avail mem = 1021227008 (973MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (10 entries) bios0: vendor BHYVE version "1.00" date 03/14/2014 bios0: bhyve BHYVE acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT APIC FACP HPET MCFG acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2400.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,CX16,xTPR,SSE4 .1,SSE4.2,MOVBE,POPCNT,AES,RDRAND,HV,NXE,LONG,LAHF,3DNOWP,ITSC,ERMS,ARAT cpu0: 1MB 64b/line 16-way L2 cache cpu0: TSC frequency 2400132000 Hz cpu0: smt 0, core 0, package 0 mtrr: CPU supports MTRRs but not enabled by BIOS cpu0: apic clock running at 134MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2408.75 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,CX16,xTPR,SSE4 .1,SSE4.2,MOVBE,POPCNT,AES,RDRAND,HV,NXE,LONG,LAHF,3DNOWP,ITSC,ERMS,ARAT cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 0, package 1 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1000 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PC00) "PNP0303" at acpi0 not configured "PNP0F13" at acpi0 not configured "PNP0501" at acpi0 not configured "PNP0501" at acpi0 not configured pvbus0 at mainbus0: bhyve pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 unknown vendor 0x1275 product 0x1275 rev 0x00 ahci0 at pci0 dev 4 function 0 "Intel 82801H AHCI" rev 0x00: apic 0 int 16, AHCI 1.3 ahci0: port 0: 6.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed t10.ATA_BHYVE_SATA_DISK_BHYVE-ABF0-1147-4A70 sd0: 9216MB, 512 bytes/sector, 18874368 sectors, thin virtio0 at pci0 dev 5 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio0: address 00:a0:98:81:81:c6 virtio0: msix shared pcib0 at pci0 dev 31 function 0 "Intel 82371SB ISA" rev 0x00 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0 mux 1 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 /dev/ksyms: Symbol table not valid. vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (1eb522b194b459a8.a) swap on sd0b dump on sd0b -- By applying the -w flag for bhyve start on the original machine, 6.1 starts as expected: Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.1 (RAMDISK_CD) #19: Sat Apr 1 13:49:18 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 251658240 (240MB) avail mem = 240402432 (229MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (10 entries) bios0: vendor BHYVE version "1.00" date 03/14/2014 bios0: bhyve BHYVE acpi0 at bios0: rev 2 acpi0: tables DSDT APIC FACP HPET MCFG acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @
Re: Topics for revised PF and networking tutorial
Without hijacking this thread completely, but touching on some of the elements discussed above (and I think these are great inclusions for the tutorial). We have implemented a variety of queues to manage our internet links and ikev2 VPNs tunnels to remote offices. We have also done something similar for our public wireless like the schedule example above. I'll be giving an overview of this and other cool stuff provided by OpenBSD that we use during my BSDCan 2017 talk titled BSD in 60 Days. Hope to see you there!
OpenBSD 6.1-snapshot boot issues in bhyve
Hi, Just wondering if anyone else is seeing the same issue I am booting a 6.1-snapshot in bhyve? In preparation for the 6.1 pending release, I have tried to spin up 6.1-snap to iron out any issues in bhyve but I don't get very far into the installation process: Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.1 (RAMDISK_CD) #19: Sat Apr 1 13:49:18 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 251658240 (240MB) avail mem = 240402432 (229MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (10 entries) bios0: vendor BHYVE version "1.00" date 03/14/2014 bios0: bhyve BHYVE acpi0 at bios0: rev 2 acpi0: tables DSDT APIC FACP HPET MCFG acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3491.87 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16 ,xTPR,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PA GE1GB,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT cpu0: 256KB 64b/line 8-way L2 cache rdmsr to register 0xc80 on vcpu 0 fatal protection fault in supervisor mode trap type 4 code 0 rip 811c1d17 cs 8 rflags 202 cr2 0 cpl e rsp 81a05940 panic: trap type 4, code=0, pc=811c1d17 The operating system has halted. Please press any key to reboot. - Is anyone able to shed light on this? I can confirm that 6.0-stable installed and runs fine as a guest on this host: - OpenBSD 6.0 (GENERIC.MP) #2: Wed Oct 12 07:46:27 AEDT 2016 mrbuil...@cybermen.ar18.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2130030592 (2031MB) avail mem = 2061062144 (1965MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7fb6a000 (10 entries) bios0: vendor BHYVE version "1.00" date 03/14/2014 acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT FACP HPET APIC MCFG SPCR acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 1000 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3491.95 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,FMA3,CX16,xTPR ,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB ,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: CPU supports MTRRs but not enabled by BIOS cpu0: apic clock running at 134MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3499.42 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,FMA3,CX16,xTPR ,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB ,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 0, package 1 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PC00) "PNP0303" at acpi0 not configured "PNP0F03" at acpi0 not configured "PNP0501" at acpi0 not configured "PNP0501" at acpi0 not configured pvbus0 at mainbus0: bhyve pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 unknown vendor 0x1275 product 0x1275 rev 0x00 unknown vendor 0xfb5d product 0x40fb (class display subclass VGA, rev 0x00) at pci0 dev 2 function 0 not configured ahci0 at pci0 dev 3 function 0 "Intel 82801H AHCI" rev 0x00: apic 2 int 16, AHCI 1.3 ahci0: port 0: 6.0Gb/s scsibus1 at ahci0: 32 targets cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable ahci1 at pci0 dev 4 function 0 "Intel 82801H AHCI" rev 0x00: apic 2 int 17, AHCI 1.3 ahci1: port 0: 6.0Gb/s scsibus2 at ahci1: 32 targets sd0 at scsibus2 targ 0 lun 0: SCSI3 0/direct fixed t10.ATA_BHYVE_SATA_DISK_BHYVE-4AF5-4FB1-76AA sd0: 9216MB, 512 bytes/sector, 18874368 sectors, thin virtio0 at pci0 dev 5 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio0: address 00:a0:98:81:81:c6 virtio0: msix shared virtio1 at pci0 dev 6 function 0 "Qumranet Virtio Network" rev 0x00 vio1 at virtio1: address 00:a0:98:6d:12:d0 virtio1: msix shared pcib0 at pci0 dev 31 function 0 "Intel 82371SB ISA" rev 0x00 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0
Typo error in OpenBSD 6.0 Errata 6 patch file
Hi, Just picked up a typo in in the http://ftp.openbsd.org/pub/OpenBSD/patches/6.0/common/006_iked.patch.sig errata file. While there is a patch below, it will need to be re-issued with an updated signify signature. Cheers! --- 006_iked.patch.sig.orig Sun Sep 18 12:05:38 2016 +++ 006_iked.patch.sig Sun Sep 18 12:05:56 2016 @@ -7,7 +7,7 @@ During parsing of the iked(8) configuration, a variabl mistake, disabling Pre-Shared key authentication. Apply by doing: -signify -Vep /etc/signify/openbsd-60-base.pub -x 005_iked.patch.sig \ +signify -Vep /etc/signify/openbsd-60-base.pub -x 006_iked.patch.sig \ -m - | (cd /usr/src && patch -p0) And then rebuild and install iked:
Re: queueing example on pf.conf man page
On 4 November 2015 at 13:09, Glenn Faustino wrote: > I notice that under queueing section of the pf.conf man page the total > child queues bandwidth exceed what's defined in the parent. rootq was > defined with 100M bandwidth and the child queues defined http 60M, mail > 10M, ssh 20M and std 20M. > > > Can the bandwidth on the child queues exceed what's defined in the parent? > While pf(4) will let you define and load queues that exceed the parent (top level) queue, when you start to load up your queues, you'll get congestion defeating the purpose of queuing. To what point, depends on your environment. Maybe the pf.conf(5) man page needs to be adjusted to reflect the statement below and set the std queue to 10M (but that is up to the project to decide): "All bandwidth values must be specified as an absolute value. The suffixes K, M, and G are used to represent bits, kilobits, megabits, and gigabits per second, respectively. The value must not exceed the interface bandwidth." Cheers.
Re: Anyone experienced with 4G/LTE modems?
On 4 November 2015 at 07:31, Alan Corey wrote: > Anybody have good experiences with any of the currently available > 4G/LTE modems that start around $30 on eBay, mostly by Huawei? I > won't have a real internet connection for at least a year. Right now > You might want to see if the chipset you are looking at lines up with support under the umsm(4) device [ see http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/umsm.4?query=umsm&sec=4 ]. Personally I don't have any of these (I tether to my HTC One when I need internet on the go) but I have heard that everything works as intended with supported devices. At $30, I don't think it is much of a risk to give it a shot, much cheaper to burn out than phones. Cheers, Jason.
PF Queuing of NAT-T IKEv2 ESP Traffic
Hi All, Can anyone verify (based on my diagram below) if they have had success with queuing IKEv2 return traffic from the "Server". I have been able to use IKEv2 based tagging and doing it (as described in iked.conf(5)) when NAT-T isn't used and when traffic is 'pass out' from the IKEv2 "Client", but never for NAT-T connections from the "Server". Looking at tcpdumps of the $ext_if on the "Server", there is never any independent egress ESP traffic from the "Server", it all passes over the original "pass in" connection to the server on port 4500, back to the "Client" via the "NAT GW". As enc(4) is not queue-able, using tagging and queuing of ESP flows is the best option (as excellently documented in iked.conf(5)) but in a NAT-T setup, the ESP flows are 'udpencap' into the NAT-T transport and the individual flows don't actually touch the external interface. For road worriers, this probably isn't a problem but in my case I need to be able to use tagging of the IKEv2 flows to budget traffic and ensure QoS of certain network traffic. Controlling at the network entry points is not an option as I have no control over the network gear (3rd party management by the ISP). Am I doing it wrong? Is this something that wasn't thought of in the OpenIKED implementation? Or is queuing coming to enc(4) real soon? +---++-+pppoe0 +--+ |Client ||NAT GW |130.40.2.3| IKEv2 Server | | 192.168.1.101 | -> | 192.168.1.1 | > Internet > | 10.0.1.1/8 | --> Big Internal +---++-+ 202.140.3.50+--+ Network /8 em0 Thanks in advance, Jason.
Re: iked & nat-t problem (no keep alive)
On 19 October 2015 at 21:49, igyht wrote: > I am testing iked on OpenBSD phobos 5.7 GENERIC#738 i386, I think there is > keep-alive problem when use with NAT-T, > detailed configurations are: > > > > http://daemonforums.org/showthread.php?t=9446 > > > > I think, iked & nat-t need some kind of "keep alive", but I can't find it > in > iked.conf configuration. Any idea? > > > Keep alive is not really the best way to do it and from memory, the RFC states it shouldn't be done (though I think the NAT-T RFC stated it could, but might be getting a whole lot of them mixed up). To keep your link alive, it is easier to be done at the firewall level. Depending on your firewall or NAT device you can configure to use what is known as 'static-port'. Good firewalls like PF use upper port ransomisation for NAT connections, as you have found out, the state expires and when you try to send data again, the firewall sets up a new UDP 4500 link but return responses will be back to the original client port, not the new one that is setup - thus dropped packets and you need to re-initialise the link. The RFC states that the client (active) is not allowed to send the server (passive) the new return port to prevent DDoS occurring on the server. The best way I have found to solve this problem is configuring a match rule specifically for NAT outbound to remote [any] 4500 static-port (see man 5 pf.conf), leaving good port ransomisation in place for all other traffic. Seems the network admins leave static-port matching on on Cisco routers so I haven't had any issues when connecting through these. Cheers, Jason. -- "If my calculations are correct, when this baby hits 88MPH, you're gonna to see some serious shit" - Emmett "Doc" Brown
Re: ipsec via iked
On 3 November 2015 at 03:14, Sébastien Morand wrote: > Hi, > > I set up an ipsec VPN via iked. > > > > The point is that the server has to know my home network (192.168.100.0/24 > ). > How to make it works wherever my laptop is? > > I tried with config address options but can't make it work. > While not an endorsed FAQ or man page from the project, this: http://puffysecurity.com/wiki/openikedoffshore.html should give you a few tips on how to achieve this. The man page (iked.conf) and the references for pf within it should be enough to work it out. But from my observations of your ikev2 configs, you are making it a little more complex than it needs to. Cheers.
Re: IKED and encapsulated peers
On 5 October 2015 at 22:00, Jason Tubnor wrote: > > Solved! > > > I have attached a man 5 iked.conf patch that clears up an example used in > the man page. > The gz diff was stripped by demime, here is the flat text patch file. Cheers, Jason. [demime 1.01d removed an attachment of type application/octet-stream which had a name of iked.conf.5.patch]
Re: IKED and encapsulated peers
On 3 October 2015 at 14:40, Jason Tubnor wrote: > Hi, > > Based on man 5 iked.conf the following should setup technically 4 flows > (reversing and setting active on the corresponding peer): > > > Solved! Main gateway: # cat /etc/iked.conf ikev2 esp from 192.168.232.128 to 192.168.232.129 \ from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.129 psk "HelloWorld" # ipsecctl -sa FLOWS: flow esp in from 192.168.232.129 to 192.168.232.128 peer 192.168.232.129 srcid FQDN/hovpn.local dstid FQDN/rovpn.local type use flow esp out from 192.168.232.128 to 192.168.232.129 peer 192.168.232.129 srcid FQDN/hovpn.local dstid FQDN/rovpn.local type require flow esp in from 192.168.72.0/24 to 192.168.1.0/24 peer 192.168.232.129 srcid FQDN/hovpn.local dstid FQDN/rovpn.local type use flow esp out from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.129 srcid FQDN/hovpn.local dstid FQDN/rovpn.local type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0x01d084c7 auth hmac-sha2-256 enc aes-256 esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0xf055afa1 auth hmac-sha2-256 enc aes-256 Remote gateway (that initiates connection): # cat /etc/iked.conf ikev2 active esp from 192.168.232.129 to 192.168.232.128 \ from 192.168.72.0/24 to 192.168.1.0/24 peer 192.168.232.128 psk "HelloWorld" # ipsecctl -sa FLOWS: flow esp in from 192.168.232.128 to 192.168.232.129 peer 192.168.232.128 srcid FQDN/rovpn.local dstid FQDN/hovpn.local type use flow esp out from 192.168.232.129 to 192.168.232.128 peer 192.168.232.128 srcid FQDN/rovpn.local dstid FQDN/hovpn.local type require flow esp in from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.128 srcid FQDN/rovpn.local dstid FQDN/hovpn.local type use flow esp out from 192.168.72.0/24 to 192.168.1.0/24 peer 192.168.232.128 srcid FQDN/rovpn.local dstid FQDN/hovpn.local type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0x01d084c7 auth hmac-sha2-256 enc aes-256 esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0xf055afa1 auth hmac-sha2-256 enc aes-256 -- I have attached a man 5 iked.conf patch that clears up an example used in the man page. Cheers, Jason. [demime 1.01d removed an attachment of type application/x-gzip which had a name of iked.conf.5.patch.gz]
Re: IKED and encapsulated peers
On 3 October 2015 at 14:40, Jason Tubnor wrote: > Hi, > > > Here is the ipsecctl flows: > > > Sorry, I copied in the flows from the wrong server (testing all different ways trying to get things to work). Here is the ipsecctl to match the iked.conf listed: # ipsecctl -sa FLOWS: flow esp in from 192.168.72.0/24 to 192.168.1.0/24 peer 192.168.232.129 srcid FQDN/hovpn.local dstid FQDN/rovpn.local type use flow esp out from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.129 srcid FQDN/hovpn.local dstid FQDN/rovpn.local type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0x1d3ef308 auth hmac-sha2-256 enc aes-256 esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0x22b8b189 auth hmac-sha2-256 enc aes-256 esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0xb8b060e1 auth hmac-sha2-256 enc aes-256 esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0xbda3e596 auth hmac-sha2-256 enc aes-256 Cheers, Jason
IKED and encapsulated peers
Hi, Based on man 5 iked.conf the following should setup technically 4 flows (reversing and setting active on the corresponding peer): /etc/iked.conf ikev2 esp from 192.168.232.128 to 192.168.232.129 psk "HelloWorld" ikev2 esp from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.129 psk "HelloWorld" The site to site flow (2nd rule) works as intended over the encapsulated interface. However, the 1st rule will not encapsulate the ICMP traffic when pinging from the opposite peer (peer 192.168.232.129 used below): # ping 192.168.232.128 PING 192.168.232.128 (192.168.232.128): 56 data bytes Oct 03 14:21:13.493860 rule 3/(match) block in on em0: 192.168.232.128 > 192.168.232.129: icmp: echo reply Here is the ipsecctl flows: # ipsecctl -sa FLOWS: flow esp in from 192.168.72.0/24 to 192.168.111.0/24 peer 192.168.232.129 srcid FQDN/hovpn.local dstid FQDN/rovpn.local type use flow esp out from 192.168.111.0/24 to 192.168.72.0/24 peer 192.168.232.129 srcid FQDN/hovpn.local dstid FQDN/rovpn.local type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0x09a48897 auth hmac-sha2-256 enc aes-256 esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0x55ef5dfe auth hmac-sha2-256 enc aes-256 esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0x99bd11bb auth hmac-sha2-256 enc aes-256 esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0xf5e4357a auth hmac-sha2-256 enc aes-256 *Note: If I don't have the 1st IKED rule, then the SAD looks correct (only 2 lines, not 4 and still works for the above FLOWS). I'm sort at a loss with this. Now I don't mind if those 192.168.232.x interfaces are encapsulated at the end of the day as all critical traffic will go over the internal network flows, though for monitoring, I'd rather end point gateway tests to remain encapsulated. Any pointers on where to look will be greatly appreciated, I've been through the man pages and mail lists many times trying to work out where I am potentially going wrong. Thanks in advance. Jason. dmesg OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar 8 11:04:17 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 520028160 (495MB) avail mem = 502321152 (479MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 07/31/2013 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) S10F(S3) S11F(S3) S12F(S3) S13F(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2394.21 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 65MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2393.62 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins acpimcfg0 at acpi0 addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 acpicpu1 at acpi0 acpibat0 at acpi0: BAT1 not present acpibat1 at acpi0: BAT2 not present acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: LID_ vmt0 at mainbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08 pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 wsdisplay0 at vga1 mux 1: console (80
Re: spamd pf rules
As Okan stated, your 5.6 man page is still correct for 5.7. It is only of issue when you move to 5.8-Release in November. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/pf.conf.5?query=pf%2econf <- -current and 5.8, use/will use divert-to (Can't give you a link to the online pf.conf man page for 5.7 as it hasn't been snapped for 5.7-release) My man pages on my 5.7 hosts specify rdr-to Cheers, Jason. On 11 June 2015 at 11:51, Edgar Pettijohn III wrote: > On Jun 10, 2015, at 3:59 PM, Okan Demirmen wrote: > >> On Wed 2015.06.10 at 15:43 -0500, Edgar Pettijohn III wrote: >>> I've been using spamd for a while now. I was looking through my pf.conf >>> and noticed that I had the following rules in regards to spamd. >>> >>> table persist >>> table persist file "/etc/mail/nospamd" >>> pass in log on egress proto tcp from any to any port smtp \ >>> rdr-to 127.0.0.1 port spamd >>> pass in on egress proto tcp from to any port smtp >>> pass in on egress proto tcp from to any port smtp >>> pass out log on egress proto tcp to any port smtp >>> >>> Everything seems to work correctly, but I was thinking the rdr-to rule was >>> wrong so I looked at spamd(8) and it shows a divert-to rule instead. When >>> I change it to divert-to I get the following error: >>> >>> # pfctl -vf /etc/pf.conf >>> >>> /etc/pf.conf:19: address family mismatch for divert >>> pfctl: Syntax error in config file: pf rules not loaded >>> >>> What should I do to fix this. Is the rdr-to rule sufficient or do I need >>> to change it? >> >> Depends. 5.7 and prior used rdr-to; and -current switched to divert-to. >> >> http://www.openbsd.org/faq/current.html#20150518 >> >> Thanks > > I guess I missed that line. However, I think my system is out of whack. I > upgraded to 5.7, but the spamd man page is from 5.6. Thanks for the lead. > > Edgar > > -- "If my calculations are correct, when this baby hits 88MPH, you're gonna to see some serious shit" - Emmett "Doc" Brown
Re: vnconfig crypto alternative
On 25 November 2014 at 18:58, David Vasek wrote: > did not look neither efficient, nor healthy. Try dd if=/dev/zero > of=/dev/rsd1c bs=1m while watching systat/iostat at the same time. Is it > still the case? So here are the findings. The test is virtualised but below is the baseline into a vnd container (no crypt etc) GENERIC 5.6-current amd64: # dd if=/dev/zero of=/dev/rvnd0a bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 41.652 secs (25174524 bytes/sec) The results for vnd container using crypt (noticed ~20% cpu utilisation): # dd if=/dev/zero of=/dev/rvnd0a bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 59.270 secs (17691307 bytes/sec) Crypto softraid inside a vnd container (noticed ~8% cpu utilisation): # dd if=/dev/zero of=/dev/rsd2a bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 87.422 secs (11994340 bytes/sec) I'll continue using vnd crypt container based on advice from theo@ . Performance is not a real issue for this small amount of data that is not accessed often in my use case so I wasn't too concerned either way, just wanted to make sure I was on a valid supported path.
vnconfig crypto alternative
With crypto being deprecated (and possibly removed in future versions - depending on dev direction) from vnconfig, would the following be assumed one way of providing an encrypted container? To create 200MB encrypted container: sudo dd if=/dev/zero of=/var/encrypt/container.encrypt bs=1m count=200 sudo chmod 600 /var/encrypt/container.encrypt sudo vnconfig vnd0 /var/encrypt/container.encrypt printf "a\n\n\n\nRAID\nw\nq\n\n" | sudo disklabel -E vnd0 sudo bioctl -c C -l vnd0a softraid0 ## Enter your secret passphrase here sudo dd if=/dev/zero of=/dev/rsd1c bs=1m count=1 printf "a\n\n\n\n4.2BSD\nw\nq\n\n" | sudo disklabel -E sd1 sudo newfs /dev/rsd1a sudo mount /dev/sd1a /encrypt ## sudo umount /encrypt sudo bioctl -d sd1 sudo vnconfig -u vnd0 Then to re-use: sudo vnconfig vnd0 /var/encrypt/container.encrypt sudo bioctl -c C -l vnd0a softraid0 ## Enter your secret passphrase here sudo mount /dev/sd1a /encrypt ## sudo umount /encrypt sudo bioctl -d sd1 sudo vnconfig -u vnd0
rc.conf issue on upgrade from 5.5 to 5.6
Hi, I was just testing upgrades prior to the 5.6 release and noticed items in the rc.conf.local were being ignored. A bit of digging, I noticed, rc.subr had some changes and more importantly there were quite a few changes to rc.conf. Cutting to the chase, replacing rc.conf from the upgraded 5.5 machine with the 5.6_BASE fixed the issue and items were being picked up in the rc.conf.local again. Just thought I would point it out as rc.conf isn't replaced when using the upgrade feature in the 5.6 release. Cheers, Jason.
Re: ifconfig command for IPv6 tunnel
Forgot to reply-all yesterday (only sent to Charles) to keep the thread in-sync with the rest of the conversation (don't nuke me for stating the obvious + added the rtadvd/route6d) On 20 August 2014 13:40, Charles Musser wrote: > ifconfig gif0 tunnel 50.1.94.112 72.52.104.74 > ifconfig gif0 inet6 alias 2001:470:1f04:204::2 2001:470:1f04:204::1 prefixlen > 128 > route -n add -inet6 default 2001:470:1f04:204::1 > Spot on there Chuck. That is how I have mine set up. Don't forget to change in your /etc/sysctl.conf file: net.inet6.icmp6.rediraccept=1 # 1=Accept IPv6 ICMP redirects (for hosts) net.inet6.ip6.forwarding=1 # 1=Permit forwarding (routing) of IPv6 packets (note the removal of the comment #) You will also need to tweek your /etc/pf.conf rule set. Here is a rough guide, mileage may vary: icmp6_types="{ unreach, timex, paramprob, echoreq, routeradv, routersol, neighbradv, neighbrsol }" # Only want these ICMP6 types block return# default that probably exists in your environment - nothing to come in unless explicitly defined below (IPv4 and IPv6) pass out on gif0 inet6# Allow for all ICMP6 traffic out - you may not want to do this but whatever works for you pass inet6 proto icmp6 icmp6-type $icmp6_types # Allow ICMP6 of types defined above to move in and out freely pass on vmx0 inet6# Allowing traffic in and out of internal network. Then you'll need to setup the rtadvd daemon to hand out your /64 to your internal clients (/etc/rtadvd.conf): default:\ :rdnss="":\ :dnssl="": vmx0:\ # This is my internal interface, yours may be different :addr="::":prefixlen#64:tc=default: Now enable all that to serve your internal clients (/etc/rc.conf.local): rtadvd_flags="vmx0" route6d_flags="" That should be about it. -- "Roads? Where we're going, we don't need roads" - Emmett "Doc" Brown
Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src
On 2 June 2014 10:23, Ted Unangst wrote: > > Part of the deprecation / migration process is identifying the weird > ways people use vnd and finding solutions for them. But as we've seen, > people never move forward without the occasional push. > So the most appropriate way to use vnd(4) as an encrypted container going forward would be to lay down softraid(4) CRYPTO inside it to achieve a like-for-like outcome or would this be over-complicating things? I have had success in testing this use case but I am aware it may not be supported.
Re: Has any one had any problem with install50.iso?
Hi Johan, Have you checked the SHA256 sig with the iso? They can be found here: http://ftp.openbsd.org/pub/OpenBSD/5.0//SHA256 If you don't have an OpenBSD installation already running to use the sha256 command, you can pick up tools over on sourceforge http://md5deep.sourceforge.net/ that can help you out with whatever platform you are running. Cheers, Jason. -- "Roads? Where we're going, we don't need roads" - Dr. Emmett "Doc" Brown