Re: Search OpenBSD mailing list archives?
Marc.info On Wed, Dec 12, 2018, at 5:56 PM, Paul Swanson wrote: > Hi, > > Is there a facility for searching the mailing list archives? > > I can't seem to find one. > > Cheers, > > Paul Swanson
Search OpenBSD mailing list archives?
Hi, Is there a facility for searching the mailing list archives? I can't seem to find one. Cheers, Paul Swanson
Re: vmm(4) update EPT to match mprotect in intial elf load. (Solo5 using vmm, doesn't involved vmd)
On Thu, Dec 13, 2018 at 12:41:10AM +, Adam Steen wrote: > Hi All > > The Solo5/Mirage tender is in the process of enforcing that guest executable > code is not also writable (W^X), but it looks like vmm is not updating EPT > to match the prot from mprotect(). > > further information > https://github.com/Solo5/solo5/issues/303#issuecomment-446503933 > > copied here for completeness > > <-- quote --> > @mato OpenBSD will not allow an mprotect call with both write and execute > enabled, W^X has been enforced at OS level since September 2016. I initially > hit this in porting efforts. > > @adamsteen I know that. What I don't know is, does this subsequent > `mprotect()` > for a PHDR with `PF_X | PF_R` set (i.e. `.text`) > > https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_elf.c#L215 > > called on the guest memory range initially set up at > > https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_openbsd.c#L117 > > have the intended effect on the underlying EPT mapping actually used by vmm to > back that memory, i.e. disallowing `PROT_WRITE`. I'm guessing it does as > otherwise the OpenBSD port would probably not work at all since the initial > mapping does not include `PROT_EXEC`, but given that the FreeBSD vmm has a > separate interface for this (VM_MMAP_MEMSEG) I'm not 100% sure. > > To confirm, could you build the branch at > https://github.com/mato/solo5/tree/enforce-nox, manually run the `test_nox` > case, and post the output? While you're at it, can you confirm that all the > other new tests there pass? > <-- end quote --> > > Is there some way i can ensure that vmm updates the EPT to match the prot > from inital mprotect(). > > Cheers > Adam > > There are two different maps maintained here. One is in vmd or whatever userland equivalent you're using to set up Solo5. The other is the map used by the EPT part in vmm. These are shared via uvm_share. I don't know how hard it would be to make permission changes on one side of the map match the other automatically (nor am I sure that even makes sense). What I could offer would be a new ioctl to set permissions on the EPT side. Something like "vmm_mprotect_ept" or the like. Would that work? -ml
vmm(4) update EPT to match mprotect in intial elf load. (Solo5 using vmm, doesn't involved vmd)
Hi All The Solo5/Mirage tender is in the process of enforcing that guest executable code is not also writable (W^X), but it looks like vmm is not updating EPT to match the prot from mprotect(). further information https://github.com/Solo5/solo5/issues/303#issuecomment-446503933 copied here for completeness <-- quote --> @mato OpenBSD will not allow an mprotect call with both write and execute enabled, W^X has been enforced at OS level since September 2016. I initially hit this in porting efforts. @adamsteen I know that. What I don't know is, does this subsequent `mprotect()` for a PHDR with `PF_X | PF_R` set (i.e. `.text`) https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_elf.c#L215 called on the guest memory range initially set up at https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_openbsd.c#L117 have the intended effect on the underlying EPT mapping actually used by vmm to back that memory, i.e. disallowing `PROT_WRITE`. I'm guessing it does as otherwise the OpenBSD port would probably not work at all since the initial mapping does not include `PROT_EXEC`, but given that the FreeBSD vmm has a separate interface for this (VM_MMAP_MEMSEG) I'm not 100% sure. To confirm, could you build the branch at https://github.com/mato/solo5/tree/enforce-nox, manually run the `test_nox` case, and post the output? While you're at it, can you confirm that all the other new tests there pass? <-- end quote --> Is there some way i can ensure that vmm updates the EPT to match the prot from inital mprotect(). Cheers Adam
Re: ikev2 and road warriors setup
Hello again,
I am using PPTP VPN (npppd) and it works as expected on windows clients -
traffic to the "LAN behind that VPNgateway" is going through VPNgateway. The
"rest" is going through clients' gateway - DO NOT "use default gateway on
remote network".
I have been playing around with iked.conf, pf.conf and ipsec.conf - still
cannot get it working in this manner.
I do not want to use OpenIKED as a internet gateway, VPN is needed only to
access "LAN behind that VPNgateway".
Could someone please help me with this problem? Christmas is coming...
Many thanks!
On Fri, 7 Dec 2018 20:20:21 +0100
Radek wrote:
> 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
> > +-+ +--+
> > | |
> > |
Re: radeondrm failure on amd64 but not on i386?
Still having this issue on -current as of Dec10. machdep.allowaperture=2 does get me past this, but am seeing weird behavior, some regions of screens/terminals not painting or refreshing. So, as this is a major inconvenience I am looking to update the video card. Any recommendations for a low-profile card that is working on 6.4/current? Thanks, Allan Allan Streib writes: > Same issue, also on a Dell machine with ATI Radeon HD 2400 XT. > > Allan > > OpenBSD 6.4 (GENERIC.MP) #0: Sat Nov 17 22:15:46 CET 2018 > > r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4141871104 (3949MB) > avail mem = 4007075840 (3821MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (82 entries) > bios0: vendor Dell Inc. version "A11" date 01/21/2011 > bios0: Dell Inc. OptiPlex 960 > acpi0 at bios0: rev 2 > acpi0: TCPA checksum error > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA DMAR SLIC SSDT > SSDT SSDT > acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5) PCI1(S5) > PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(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)2 Duo CPU E8400 @ 3.00GHz, 2992.96 MHz, 06-17-0a > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu0: 6MB 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges > cpu0: apic clock running at 332MHz > cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.51 MHz, 06-17-0a > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu1: 6MB 64b/line 16-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins, remapped > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 4 (PCI4) > acpiprt1 at acpi0: bus 2 (PCI2) > acpiprt2 at acpi0: bus 3 (PCI3) > acpiprt3 at acpi0: bus 1 (PCI1) > acpiprt4 at acpi0: bus -1 (PCI5) > acpiprt5 at acpi0: bus -1 (PCI6) > acpiprt6 at acpi0: bus 0 (PCI0) > acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS > acpibtn0 at acpi0: VBTN > acpicmos0 at acpi0 > "*pnp0c14" at acpi0 not configured > cpu0: Enhanced SpeedStep 2992 MHz: speeds: 3000, 2667, 2333, 2000 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03 > ppb0 at pci0 dev 1 function 0 "Intel Q45 PCIE" rev 0x03: msi > pci1 at ppb0 bus 1 > radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 2400 XT" rev 0x00 > drm0 at radeondrm0 > radeondrm0: msi > "Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured > pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA > (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI > pciide0: using apic 8 int 18 for native-PCI interrupt > pciide0: channel 0 ignored (not responding; disabled or no drives?) > pciide0: channel 1 ignored (not responding; disabled or no drives?) > puc0 at pci0 dev 3 function 3 "Intel Q45 KT" rev 0x03: ports: 16 com > com4 at puc0 port 0 apic 8 int 17: ns16550a, 16 byte fifo > com4: probed fifo depth: 0 bytes > em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: msi, address > 00:22:19:31:bf:96 > uhci0 at pci0 dev 26 function 0 "Intel 82801JD USB" rev 0x02: apic 8 int 16 > uhci1 at pci0 dev 26 function 1 "Intel 82801JD USB" rev 0x02: apic 8 int 17 > uhci2 at pci0 dev 26 function 2 "Intel 82801JD USB" rev 0x02: apic 8 int 22 > ehci0 at pci0 dev 26 function 7 "Intel 82801JD USB" rev 0x02: apic 8 int 22 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 > addr 1 > azalia0 at pci0 dev 27 function 0 "Intel 82801JD HD Audio" rev 0x02: msi > azalia0: codecs: Analog Devices AD1984A > audio0 at azalia0 > ppb1 at pci0 dev 28 function 0 "Intel 82801JD PCIE" rev 0x02: msi > pci2 at ppb1 bus 2 > ppb2 at pci0 dev 28 function 1 "Intel 82801JD PCIE" rev 0x02: msi > pci3 at ppb2 bus 3 > uhci3 at pci0 dev 29 function 0 "Intel 82801JD USB" rev 0x02: apic 8 int 23 > uhci4 at pci0 dev 29 function 1 "Intel 82801JD USB" rev 0x02: apic 8 int 17 > uhci5 at pci0 dev 29 function 2 "Intel 82801JD USB" rev 0x02: apic 8 int 18 > ehci1 at pci0 dev 29 function 7 "Intel 82801JD USB" rev 0x02:
Re: iked : pf.conf rule for outgoing traffic
* Stuart Henderson le [10-12-2018 18:19:41 +]: > On 2018-12-07, 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. > > > > > > It depends on what you want - I was just giving you the working example > you asked for :-) > > in my case I want to nat to a specific address, and not track the > address/es on any egress interfaces. > > Okay, got it, it works as expected. Thank you :)
Re: rtwn
Eric Furman wrote: > On Tue, Dec 11, 2018, at 8:56 PM, Stanislav wrote: > > OK. What can I do? > > Could you recommend an action I can make? > > Is it normal if I just wait for new version of rtwn? > > Or does this situation mean that mentioned card probably never will be > > supported? > > > > I have searched similar cases. > > Stefan Sperling's report at EuroBSDcon2017: "Sometimes just adding a new > > PCI/USB device ID is enough to extend device support of an existing driver". > > > > Or the problem is more complicated and driver is not ready to work with the > > device. Is it? What can I research? > > If you really want support for this card the best thing to do is buy > one and contact Theo DeRaadt for information on who to send > it to so they can work on supporting it. If a developer does not > have one of these cards in their possession they can't work on > the driver to make it supported. Bingo. Or look at the source, and mail a package to those people. But the other approach of begging people without the hardware to add support is rather ridiculous.
Re: rtwn
On Tue, Dec 11, 2018, at 8:56 PM, Stanislav wrote: > OK. What can I do? > Could you recommend an action I can make? > Is it normal if I just wait for new version of rtwn? > Or does this situation mean that mentioned card probably never will be > supported? > > I have searched similar cases. > Stefan Sperling's report at EuroBSDcon2017: "Sometimes just adding a new > PCI/USB device ID is enough to extend device support of an existing driver". > > Or the problem is more complicated and driver is not ready to work with the > device. Is it? What can I research? If you really want support for this card the best thing to do is buy one and contact Theo DeRaadt for information on who to send it to so they can work on supporting it. If a developer does not have one of these cards in their possession they can't work on the driver to make it supported.
Re: rtwn
On Tue, Dec 11, 2018 at 06:56:22PM -0700, Stanislav wrote: > OK. What can I do? > Could you recommend an action I can make? > Is it normal if I just wait for new version of rtwn? > Or does this situation mean that mentioned card probably never will be > supported? > > I have searched similar cases. > Stefan Sperling's report at EuroBSDcon2017: "Sometimes just adding a new > PCI/USB device ID is enough to extend device support of an existing driver". > > Or the problem is more complicated and driver is not ready to work with the > device. Is it? What can I research? You have a different chip than those which the driver already supports. So just adding an ID won't be enough. About the only possible way to determine what needs to be done is to read and understand the Linux driver code for your chip and figure out how exactly it differs from the code for the chips already supported by both OpenBSD and Linux. Which requires a lot of work to do. Then someone who has time and skills could implement code which covers those differences for OpenBSD's rtwn driver. That's even more work.
Re: rtwn
OK. What can I do? Could you recommend an action I can make? Is it normal if I just wait for new version of rtwn? Or does this situation mean that mentioned card probably never will be supported? I have searched similar cases. Stefan Sperling's report at EuroBSDcon2017: "Sometimes just adding a new PCI/USB device ID is enough to extend device support of an existing driver". Or the problem is more complicated and driver is not ready to work with the device. Is it? What can I research? -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: [OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
Hi Aaron, Thanks! I also tried gif. But the behavior is quite weird. Through the gif devices, the gateway and VPN server can ping each other, while the packets on gateway enc0 from the client routing to the gif device always got bad checksums. I think it is related to the bugs on gif(4) man page? "There are many tunnelling protocol specifications, defined differently from each other. gif may not interoperate with peers which are based on different specifications, and are picky about outer header fields. For example, you cannot usually use gif to talk with IPsec devices that use IPsec tunnel mode.” [Gateway] /etc/hostname.gif0: 10.0.0.2 10.0.0.1 [VPN server] /etc/hostname.gif0: 10.0.0.1 10.0.0.2 Best regards, Siegfried > On Dec 12, 2018, at 7:39 PM, Aaron Mason wrote: > > Hi Siegfried > > (Maintainers of the IPSec stack and ISAKMPD are welcome to tear my answer > apart) > > IPSec tunnels are, for want of a better term, entirely transparent - > the underlying OS and its clients have no idea that it exists. In > order to route across an IPSec tunnel, use gif(4) to create an > IP-to-IP tunnel between the endpoints. IPSec will encrypt all traffic > that goes across it - from there it's a matter of setting up the > static routes on either side. > On Wed, Dec 12, 2018 at 7:40 AM Zhi-Qiang Lei wrote: >> >> I’m building a gateway to encrypt some traffics: >> >> Client —> Gateway —> VPN Server —> Internet >> (192.168.1.16) (10.0.0.2) >> >> >> [Gateway] /etc/iked.conf: >> >> ikev2 quick active ipcomp esp \ >>from 10.0.0.2 to 0.0.0.0/0 \ >>local egress peer $vpn_server_ip \ >>ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group >> curve25519 \ >>childsa enc chacha20-poly130 group curve25519 \ >>dstid "asgard.local" >> >> [VPN Server] /etc/iked.conf: >> >> ikev2 quick passive ipcomp esp \ >>from 0.0.0.0/0 to 10.0.0.2 \ >>local egress \ >>ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group >> curve25519 \ >>childsa enc chacha20-poly130 group curve25519 \ >>dstid "blackjack.local" >> >> The SA has been established. When I ping 10.0.0.2 on VPN Server and tcpdump >> on gateway enc0 I got: >> >> # tcpdump -envps 1500 -i enc0 -l >> tcpdump: listening on enc0, link-type ENC >> 03:48:20.778584 (authentic,confidential): SPI 0x7f27bd3b: $vpn_server_ip > >> $gateway_ip: $vpn_server_ip > 10.0.0.2: icmp: echo request (id:4656 seq:0) >> [icmp cksum ok] (ttl 255, id 60419, len 84) (ttl 50, id 59144, len 104) >> 03:48:21.788330 (authentic,confidential): SPI 0x7f27bd3b: $vpn_server_ip > >> $gateway_ip: $vpn_server_ip > 10.0.0.2: icmp: echo request (id:4656 seq:1) >> [icmp cksum ok] (ttl 255, id 1688, len 84) (ttl 50, id 31496, len 104) >> >> How can I route the packets from the client to the VPN server on the >> gateway? When I was using OpenVPN, I did the routing in pf.conf: >> >> pass in quick from 192.168.1.0/24 to !192.168.1.0/24 route-to tun0 >> pass out quick on tun0 from 192.168.1.0/24 to any nat-to tun0 >> >> However, there is no tunnel device created after the SA is established on >> OpenBSD. Did I miss something to create it? >> >> Best regards, >> Siegfried >> >> >> > > > -- > Aaron Mason - Programmer, open source addict > I've taken my software vows - for beta or for worse
Re: [OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
Hi Siegfried (Maintainers of the IPSec stack and ISAKMPD are welcome to tear my answer apart) IPSec tunnels are, for want of a better term, entirely transparent - the underlying OS and its clients have no idea that it exists. In order to route across an IPSec tunnel, use gif(4) to create an IP-to-IP tunnel between the endpoints. IPSec will encrypt all traffic that goes across it - from there it's a matter of setting up the static routes on either side. On Wed, Dec 12, 2018 at 7:40 AM Zhi-Qiang Lei wrote: > > I’m building a gateway to encrypt some traffics: > > Client —> Gateway —> VPN Server —> Internet > (192.168.1.16) (10.0.0.2) > > > [Gateway] /etc/iked.conf: > > ikev2 quick active ipcomp esp \ > from 10.0.0.2 to 0.0.0.0/0 \ > local egress peer $vpn_server_ip \ > ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group > curve25519 \ > childsa enc chacha20-poly130 group curve25519 \ > dstid "asgard.local" > > [VPN Server] /etc/iked.conf: > > ikev2 quick passive ipcomp esp \ > from 0.0.0.0/0 to 10.0.0.2 \ > local egress \ > ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group > curve25519 \ > childsa enc chacha20-poly130 group curve25519 \ > dstid "blackjack.local" > > The SA has been established. When I ping 10.0.0.2 on VPN Server and tcpdump > on gateway enc0 I got: > > # tcpdump -envps 1500 -i enc0 -l > tcpdump: listening on enc0, link-type ENC > 03:48:20.778584 (authentic,confidential): SPI 0x7f27bd3b: $vpn_server_ip > > $gateway_ip: $vpn_server_ip > 10.0.0.2: icmp: echo request (id:4656 seq:0) > [icmp cksum ok] (ttl 255, id 60419, len 84) (ttl 50, id 59144, len 104) > 03:48:21.788330 (authentic,confidential): SPI 0x7f27bd3b: $vpn_server_ip > > $gateway_ip: $vpn_server_ip > 10.0.0.2: icmp: echo request (id:4656 seq:1) > [icmp cksum ok] (ttl 255, id 1688, len 84) (ttl 50, id 31496, len 104) > > How can I route the packets from the client to the VPN server on the gateway? > When I was using OpenVPN, I did the routing in pf.conf: > > pass in quick from 192.168.1.0/24 to !192.168.1.0/24 route-to tun0 > pass out quick on tun0 from 192.168.1.0/24 to any nat-to tun0 > > However, there is no tunnel device created after the SA is established on > OpenBSD. Did I miss something to create it? > > Best regards, > Siegfried > > > -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Block udp fragments to a single host while reassembling is on
Dear list, i want to block udp fragments to a specific host while the reassembling is turned on for all other traffic: In pf I would write something like this: # reassemble fragmented packets (default yes) set reassemble yes # scrub all traffic match all scrub (random-id no-df) # block fragments to host 10.0.0.10 block log quick from any to 10.0.0.10 fragment For me, it sounds like this is not possible, because reassembling happens before pf and it is only possible to turn it on or off as a whole, right? Is there an other way to achieve this challenge. Any advice ? Thanks, Joerg
Re: Renew/extend CA created with ikectl
Hello Stuart thanks for the reply, already suspected something along those lines. On 12/10/18 7:14 PM, Stuart Henderson wrote: It's a bit awkward but can be done, you'll find some information at https://serverfault.com/questions/306345/certification-authority-root-certificate-expiry-and-renewal You'll need to get the new CA cert installed on clients anyway though (and I don't suppose the client certs have much longer validity either?) so doing the above might not save you much trouble .. In the end I followed doing something along these lines. As we have quite some clients in the field it was easier to get them to add the new CA. 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? Not without patching the command-line in ikectl code, or generating the cert manually. It's not ideal.. I would be willing to patch ikectl to contain a ca renew, but would like some 'guidance' concerning sane defaults for this. I'd probably recommend using something else to manage your internal CA (or just avoiding X509 if you don't actually need it...). Any suggestions? We used some other CA management SW over the years but enjoyed the clean and simple approach that ikectl gave us so far. Cheers Kim
