Re: A shell script to create chroot jails
Hi Raf,
Thanks a lot for your help. Now I’ve updated it regarding to your great
advices. Would you mind to take a look again?
https://gist.github.com/siegfried/907904752b1b5db760782f476f44fca4
Sincerely yours,
Siegfried
zhiqiang@gmail.com
> On Apr 20, 2020, at 5:40 AM, Raf Czlonka wrote:
>
> On Sun, Apr 19, 2020 at 08:30:11AM BST, Zhi-Qiang Lei wrote:
>> Hi,
>>
>> I wrote a script to create chroot jails. Please feel free to use and
>> comment. Thanks.
>>
>> https://gist.github.com/siegfried/907904752b1b5db760782f476f44fca4
>>
>
> Hi Zhi-Qiang,
>
> Please test *before* you post!
>
> Where are $JAIL_HOME and $IMAGE_HOME coming from?
>
> You aren't checking for $1 at all.
>
> Why the "example" in mktemp?
>
> Where do the iso files come from?
>
> You use "/bin/sh" but also "function" - bad style IMO.
>
> You aren't checking vnd0 is currently in use or not - please consider
> something like this:
>
> vnd_dev="$(/sbin/vnconfig -l | awk '/not in use/,FS=":" { print $1 ;
> exit }')"
>
> Apart from the MAKEDEV step, you can avoid using cd.
>
> /usr/lib is a built-in system directory so there's no need to pass
> it to ldconfig.
>
> Not an issue here but *not* using '{}' around variable name inside
> a string, will bite you in the arse one day! ;^)
>
> Regards,
>
> Raf
A shell script to create chroot jails
Hi, I wrote a script to create chroot jails. Please feel free to use and comment. Thanks. https://gist.github.com/siegfried/907904752b1b5db760782f476f44fca4 Sincerely yours, Siegfried zhiqiang@gmail.com
Re: Home NAS
I have a HP Gen8 Microserver running as a NAS using OpenBSD. It has been serving well for like 5 months. I choose OpenBSD over FreeBSD because: 1. FreeBSD was my first consideration because of ZFS, but as far as I know, ZFS doesn’t work well with RAID controller, and neither FreeBSD nor OpenBSD has a driver for the B120i array controller on the mainboard (HP is to be blamed). I could use AHCI mode instead RAID which also suits ZFS of FreeBSD, yet there is a notorious fan noise issue of that approach. 2. A HP P222 array controller works right out of the box on OpenBSD, maybe FreeBSD as well but the combination of ZFS and RAID controller seems weird to me. 3. OpenBSD is actually out of my expectation. CIFS and NFS is just easy to setup. The most fabulous thing to me is the full disk encryption. I had a disk failure and the array controller was burnt once because I had some cooling issue. However, I was confident to get a replacement and no data was lost. As the 5TB limitation, I haven’t been there. > On Nov 14, 2019, at 10:26 PM, Jan Betlach wrote: > > > Hi guys, > > I am setting up a home NAS for five users. Total amount of data stored on NAS > will not exceed 5 TB. > Clients are Macs and OpenBSD machines, so that SSHFS works fine from both (no > need for NFS or Samba). > I am much more familiar and comfortable with OpenBSD than with FreeBSD. > My dilema while stating the above is as follows: > > Will the OpenBSD’s UFS stable and reliable enough for intended purpose? NAS > will consist of just one encrypted drive, regularly backed to hardware RAID > encrypted two-disks drive via rsync. > > Should I byte the bullet and build the NAS on FreeBSD taking advantage of > ZFS, snapshots, replications, etc? Or is this an overkill? > > BTW my most important data is also backed off-site. > > Thank you in advance for your comments. > > Jan >
Re: Write to DVD-RAM
According to https://www.openbsd.org/faq/faq13.html#writeDVD <https://www.openbsd.org/faq/faq13.html#writeDVD>, > A pretty different format is DVD-RAM, which was mainly developed as a data > drive and has advanced packet writing functions, allowing it to be used like > a kind of optical hard disk. I was mainly looking for a method to make the DVD-RAM works like a hard drive. It seems the package is the only option though. Thanks and best regards, Siegfried > On Jul 27, 2019, at 6:42 PM, Brian Brombacher wrote: > > See cd(4): https://man.openbsd.org/cd.4 <https://man.openbsd.org/cd.4> > > It’s not a real block device. You’ll need to use something like the dvd+rw > tools package already mentioned in order to write data to it. The man page > talks about how cd devices are represented as block devices for consistency > with other tools like disklabel and mount. Look at the list of ioctl’s > supported in the man page. It talks of tracks of data (like audio tracks) > and such. > > -Brian > > On Jul 26, 2019, at 8:23 PM, gwes mailto:g...@oat.com>> wrote: > >> >> >> On 7/25/19 7:14 PM, Zhi-Qiang Lei wrote: >>> On Jul 25, 2019, at 10:24 PM, gwes mailto:g...@oat.com>> >>> wrote: >>>> >>>> On 7/24/19 10:19 PM, Zhi-Qiang Lei wrote: >>>>> Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on >>>>> my OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work >>>>> on the drive. Did I miss something? >>>>> >>>>> $ dmesg | grep cd >>>>> cd0 at scsibus3 targ 1 lun 0: ATAPI 5/cdrom >>>>> removable serial.13fd3940302020202020 >>>>> cd0 at scsibus3 targ 1 lun 0: ATAPI 5/cdrom >>>>> removable serial.13fd3940302020202020 >>>>> >>>>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k >>>>> dd: /dev/rcd0c: Invalid argument >>>>> 1+0 records in >>>>> 0+0 records out >>>>> 0 bytes transferred in 0.000 secs (0 bytes/sec) >>>>> >>>>> $ doas disklabel -E cd0 >>>>> cd0> a >>>>> partition: [a] >>>>> offset: [0] >>>>> size: [2236704] >>>>> FS type: [4.2BSD] >>>>> cd0> w >>>>> cd0> p >>>>> OpenBSD area: 0-2236704; size: 2236704; free: 0 >>>>> #size offset fstype [fsize bsize cpg] >>>>> a: 22367040 4.2BSD 2048 16384 1 >>>>> c: 22367040 unused >>>>> cd0> q >>>>> No label changes. >>>>> >>>>> The same drive can be formatted and used on Mac OS X. >>>>> >>>>> Thanks and best regards, >>>>> Siegfried >>>>> >>>> Did you try 2K blocks? The low level of CDROM only works that way. >>>> >>> >>> Blocks larger than or equal to 2k get a "dd: /dev/rcd0c: short write on >>> character device”. Regarding to cd(4) I thought the device is readonly, so >>> dd(1) and disklabel(8) cannot write on it, but fdisk(8) works fine. >>> >>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=2k >>> dd: /dev/rcd0c: short write on character device >>> dd: /dev/rcd0c: Invalid argument >>> 1+0 records in >>> 0+1 records out >>> 512 bytes transferred in 0.008 secs (57960 bytes/sec) >>> >>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=512 >>> dd: /dev/rcd0c: Invalid argument >>> 1+0 records in >>> 0+0 records out >>> 0 bytes transferred in 0.000 secs (0 bytes/sec) >>> >> /dev/cd0 is likely a symbolic link to something else in /dev. >> It's not clear what's going on unless we know exactly what's being used. >> "cd0" is not a usual OpenBSD device access even though one sees >> that in dmesg. >> >> OpenBSD disk-like devices are usually referenced in the very >> old style which distinguishes "raw" [unbuffered direct to device] >> from "cooked" [system buffered]. This differs from at least Linux practice. >> Dunno about other BSDs or Macs. >> Buffered devices are essentially only used to mount as filesystems. >> >> A raw device is /dev/r >> A buffered device is >> /dev/ >> Note that there is always a partition letter. >> The kernel will always emulate a 'c' partition = whole device if necessary. >> >> So the most specific way to refer to your cd device is /dev/rcd0c. >> >> As a convenience and to reduce operator errors, many system maintenance >> programs will deduce /dev/rc from a bare device >> like sd0. This can be confusing to people new to OpenBSD. >>
Re: Write to DVD-RAM
On Jul 25, 2019, at 10:24 PM, gwes wrote: > > > On 7/24/19 10:19 PM, Zhi-Qiang Lei wrote: >> Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on my >> OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work on the >> drive. Did I miss something? >> >> $ dmesg | grep cd >> cd0 at scsibus3 targ 1 lun 0: ATAPI 5/cdrom >> removable serial.13fd3940302020202020 >> cd0 at scsibus3 targ 1 lun 0: ATAPI 5/cdrom >> removable serial.13fd3940302020202020 >> >> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k >> dd: /dev/rcd0c: Invalid argument >> 1+0 records in >> 0+0 records out >> 0 bytes transferred in 0.000 secs (0 bytes/sec) >> >> $ doas disklabel -E cd0 >> cd0> a >> partition: [a] >> offset: [0] >> size: [2236704] >> FS type: [4.2BSD] >> cd0> w >> cd0> p >> OpenBSD area: 0-2236704; size: 2236704; free: 0 >> #size offset fstype [fsize bsize cpg] >> a: 22367040 4.2BSD 2048 16384 1 >> c: 22367040 unused >> cd0> q >> No label changes. >> >> The same drive can be formatted and used on Mac OS X. >> >> Thanks and best regards, >> Siegfried >> > Did you try 2K blocks? The low level of CDROM only works that way. > Blocks larger than or equal to 2k get a "dd: /dev/rcd0c: short write on character device”. Regarding to cd(4) I thought the device is readonly, so dd(1) and disklabel(8) cannot write on it, but fdisk(8) works fine. $ doas dd if=/dev/urandom of=/dev/rcd0c bs=2k dd: /dev/rcd0c: short write on character device dd: /dev/rcd0c: Invalid argument 1+0 records in 0+1 records out 512 bytes transferred in 0.008 secs (57960 bytes/sec) $ doas dd if=/dev/urandom of=/dev/rcd0c bs=512 dd: /dev/rcd0c: Invalid argument 1+0 records in 0+0 records out 0 bytes transferred in 0.000 secs (0 bytes/sec)
Write to DVD-RAM
Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on my OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work on the drive. Did I miss something? $ dmesg | grep cd cd0 at scsibus3 targ 1 lun 0: ATAPI 5/cdrom removable serial.13fd3940302020202020 cd0 at scsibus3 targ 1 lun 0: ATAPI 5/cdrom removable serial.13fd3940302020202020 $ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k dd: /dev/rcd0c: Invalid argument 1+0 records in 0+0 records out 0 bytes transferred in 0.000 secs (0 bytes/sec) $ doas disklabel -E cd0 cd0> a partition: [a] offset: [0] size: [2236704] FS type: [4.2BSD] cd0> w cd0> p OpenBSD area: 0-2236704; size: 2236704; free: 0 #size offset fstype [fsize bsize cpg] a: 22367040 4.2BSD 2048 16384 1 c: 22367040 unused cd0> q No label changes. The same drive can be formatted and used on Mac OS X. Thanks and best regards, Siegfried
Re: IKEv2 Multiple NAT'd Clients
You don’t have to configure /etc/hostname.enc0, I think. How about remove it
and then check if this happen again?
> On Jul 6, 2019, at 3:40 AM, David Anthony wrote:
>
> Hello,
>
> I have an IKEv2 VPN server setup with OpenBSD + IKED + PF. Everything is
> working properly - a single client device will properly route all traffic
> through the VPN and exit from the VPN server via PF + NAT.
>
> However, I experience errors with two clients simultaneously connecting. Both
> clients appear to successfully connect, but I believe NAT issues are
> preventing traffic from leaving the box, or confusing the two client traffic
> streams during NAT. I’m looking for any clues / suggestions which may help
> achieve my use case.
>
> The internet suggests using unique “from CLIENTIPADDR” clauses for each
> potential client in /etc/iked.conf - but I can’t tell ahead of time which
> CIDR ranges my devices will be connecting from (Especially roaming cell
> phones). Also, in some cases I may have two devices connecting from the same
> CIDR range. I’m not even sure it’s an IKED issue, rather NAT.
>
> Respectfully,
> David Anthony
>
> /etc/pf.conf
> set skip on lo
> block return
> match out on vio0 from 10.0.0.0/24 to any nat-to vio0
> pass
> block return in on ! lo0 proto tcp to port 6000:6010
> block return out log proto {tcp udp} user _pbuild
>
> /etc/iked.conf
> ikev2 “inet” esp \
> from 0.0.0.0/0 to 10.0.0.0/24 \
> peer any \
> psk “foobar” \
> config address 10.0.0.64/27 \
> config name-server 10.0.0.1 \
> config protected-subnet 0.0.0.0/0
>
> /etc/hostname.enc0
> inet 10.0.0.1 255.255.255.0 10.0.0.255
> up
>
> /etc/rc.conf.local
> iked_flags=
> unbound_flags=
>
> /etc/sysctl.conf
> net.inet.ip.forwarding=1
> net.inet.esp.enable=1
> net.inet.ah.enable=1
> net.inet.ipcomp.enable=1
Re: TLS suddenly not working over IKED site-to-site - SOLVED?
Mine is resolved by applying a smaller max-mss in pf and disabling ipcomp. Only disabling ipcomp didn’t work. > On Mar 15, 2019, at 3:15 AM, Andrew Daugherity > wrote: > > On Thu, Dec 20, 2018 at 6:54 PM Theodore Wynnychenko > wrote: >> Then, I took the advice above, and disable ipcomp on the tunnel, and, BAHM, >> https (and imaps) were working without an issue from openbsd, Windows 7, and >> Macs! >> >> Just to be sure, I updated this am to the 12/19 amd64 snapshot. >> >> When I turn on ipcomp, https/imaps hangs for most connections; when I turn >> ipcomp off, https/imaps works. > > I can confirm this behavior. I've set up a simple RSA key VPN as > described at http://www.openbsd.org/faq/faq17.html#site2site, which > does not include ipcomp by default, and everything works fine, > including https. After reading this I decided to test enabling > ipcomp, and sure enough, loading an https page across the VPN fails. > With ipcomp I also see some "unprotected" packets when running tcpdump > on enc0, e.g.: > 13:32:19.600062 (authentic,confidential): SPI 0xee345270: > 10.95.10.236.57254 > 10.95.0.233.443: P 273:518(245) ack 5604 win 455 > (DF) (encap) > 13:32:19.614996 (unprotected): SPI 0x5a04: 10.95.0.233.443 > > 10.95.10.236.57254: . 5604:7052(1448) ack 518 win 252 timestamp 61011950 1069884950> (DF) (encap) > > I don't know why that is happening, but as everything seems to work > well and perform decently without ipcomp, I'll be leaving it disabled. > >> I noticed that the last change to sys/netinet/ip_ipcomp.c (I am guessing >> this is the code that is involved) in the log (I think) was about 3 months >> ago, and at this point, I can't recall if my last updated (prior to the one >> where the instability began) was before or after that change. >> >> I was going to try to recompile it with the change undone, but am not sure >> how to do that, or even if it can be done for just that one part of sys. > > Yes, just use git or cvs (whatever you checked out the code with) to > fetch an earlier revision of that file (not the whole repo) and then > build a new kernel. Sometimes you'd need to also revert other related > changes, but that does not appear to be the case here, assuming you're > referring to [1]. Note that some previous commits did touch multiple > files. > >> And, after removing ipcomp from iked.conf, my subjective observation is that >> things load a lot faster than they seemed to in the past with ipcomp on; so, >> I am happy with where I am. >> >> I was just posting my observations in case anyone else has a similar issue. > > Thank you for sharing. I had (I think) been using ipcomp in my old > ikev1 (ipsec.conf/isakmpd) setup but had not yet gotten around to > enabling it in the ikev2 setup. Based on this, I won't bother. > > > -Andrew > > [1] https://github.com/openbsd/src/commit/4b5fa55 >
Re: [OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
GRE(4) is the one to save. GIF(4) might work as well, but my tunnel setting was not correct. Thanks, Siegfried > On Dec 13, 2018, at 10:15 PM, Zhi-Qiang Lei wrote: > > After changed my from-to selectors in iked configuration, the gateway is > almost working. > > [VPN Server] /etc/iked.conf: > > ikev2 quick passive ipcomp esp \ >from 0.0.0.0/0 to 192.168.1.0/24 \ >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" > > [Gateway] /etc/iked.conf: > > ikev2 quick active ipcomp esp \ >from 192.168.1.0/24 to $some_network \ >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" > > This is truly convenient thanks to the transparency. I don’t even have to > mind the route. However, I still have some issues to add more policies: > > I have a blacklist contains the networks I don’t want to apply IPSec. When I > was using OpenVPN, it was done by a pf rule: > > pass out quick from to ! route-to tun0 > > What is the best practice to do the same in /etc/iked.conf? > > My intuitive thoughts were: > > [Gateway] /etc/iked.conf: > > ikev2 quick active ipcomp esp \ >from 192.168.1.0/24 to !$network1 \ > … thousands of from-to … > from 192.168.1.0/24 to !$network8000 \ >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" > > But ! operator and too many flows are causing error. > >> On Dec 12, 2018, at 10:37 PM, Zhi-Qiang Lei wrote: >> >> 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" >>>> >>
Re: TLS suddenly not working over IKED site-to-site
LyR344u3vl7be
vxoi+WPJBhGT+j1gJmg5AiEAwQ3rzH1mmMSYNYKtVNDZMo+l6e8Z35t+X9NDR7Du
gWAAdwCHdb/nWXz4jEOZX73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWBXnEL7AAAE
AwBIMEYCIQCRjvvPARW3J1ENmo2Nz1cxisa1BcbDuqvSrfuXkz8btAIhAPmllqgF
8JjlVHUChiFzghsKVBeTxRagi55tgsAciaoZAHUAu9nfvB+KcbWTlCOXqpJ7RzhX
lQqrUugakJZkNo4e0YUAAAFgV5xCUgAABAMARjBEAiBY6qdNgMoQAqVTl3zRrTmy
+X/1f/esBUczsb3MWdZ1ZgIgXdxZNTrDBgyTzxgbVRObkqU3tZZdaiwsw4WI0xI0
BtQwDQYJKoZIhvcNAQELBQADggEBAGu0uxZD+IRXXlFWLPvknRkXA7J08NyVKG70
M2vDi2xF2YB8qlZgoxW8YiiV86IpwtOhYLZinSO0iCBDQmTf627LTPfuDcF6qOuO
WFTvj1IbplPvGWIu5tNBiFWNQxFAIL2Rf+5vmIe+YezUHTLGGqwRtFa2ImS17IMk
YjZ90LYXXO5qb1RKkFJtAvEBTbJsv8kr+J6Rx+YNJy17LnBX+MbWiyBbvUQoM3sY
MmcWmcaQmECz9ZHWYjZeufSHbHKG6KDYLU8x6DyhgtxK2rsoIMlNnJkNHaLjw+b8
7VCYa+EMWppvVuNyXOk9Jkbx7Q3SEoodT77kkHUX0bF2OkZy6cc=
-END CERTIFICATE-
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance
Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV
Root CA
-BEGIN CERTIFICATE-
MIIEsTCCA5mgAwIBAgIQBOHnpNxc8vNtwCtCuF0VnzANBgkqhkiG9w0BAQsFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowcDEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEvMC0GA1UEAxMmRGlnaUNlcnQgU0hBMiBIaWdoIEFzc3Vy
YW5jZSBTZXJ2ZXIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2
4C/CJAbIbQRf1+8KZAayfSImZRauQkCbztyfn3YHPsMwVYcZuU+UDlqUH1VWtMIC
Kq/QmO4LQNfE0DtyyBSe75CxEamu0si4QzrZCwvV1ZX1QK/IHe1NnF9Xt4ZQaJn1
itrSxwUfqJfJ3KSxgoQtxq2lnMcZgqaFD15EWCo3j/018QsIJzJa9buLnqS9UdAn
4t07QjOjBSjEuyjMmqwrIw14xnvmXnG3Sj4I+4G3FhahnSMSTeXXkgisdaScus0X
sh5ENWV/UyU50RwKmmMbGZJ0aAo3wsJSSMs5WqK24V3B3aAguCGikyZvFEohQcft
bZvySC/zA/WiaJJTL17jAgMBAAGjggFJMIIBRTASBgNVHRMBAf8ECDAGAQH/AgEA
MA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
NAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybDQuZGlnaWNlcnQuY29t
L0RpZ2lDZXJ0SGlnaEFzc3VyYW5jZUVWUm9vdENBLmNybDA9BgNVHSAENjA0MDIG
BFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQ
UzAdBgNVHQ4EFgQUUWj/kK8CB3U8zNllZGKiErhZcjswHwYDVR0jBBgwFoAUsT7D
aQP4v0cB1JgmGggC72NkK8MwDQYJKoZIhvcNAQELBQADggEBABiKlYkD5m3fXPwd
aOpKj4PWUS+Na0QWnqxj9dJubISZi6qBcYRb7TROsLd5kinMLYBq8I4g4Xmk/gNH
E+r1hspZcX30BJZr01lYPf7TMSVcGDiEo+afgv2MW5gxTs14nhr9hctJqvIni5ly
/D6q1UEL2tU2ob8cbkdJf17ZSHwD2f2LSaCYJkJA69aSEaRkCldUxPUd1gJea6zu
xICaEnL6VpPX/78whQYwvwt/Tv9XBZ0k7YXDK/umdaisLRbvfXknsuvCnQsH6qqF
0wGjIChBWUMo0oHjqvbsezt3tkBigAVBRQHvFwY+3sAzm2fTYS5yh+Rp/BIAV0Ae
cPUeybQ=
-END CERTIFICATE-
---
Server certificate
subject=/C=US/ST=California/L=Menlo Park/O=Facebook, Inc./CN=*.facebook.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance
Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3412 bytes and written 326 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher: ECDHE-ECDSA-AES128-GCM-SHA256
Session-ID: FCB725472E0112F95A596012CDD55AB38A73CE46BABF6226978651E9F259C609
Session-ID-ctx:
Master-Key:
A35C3023DE520684DA23B557656DDC3478FCD3C66B5BA677F62B605BCC4CD395C085D3A980587DE72D9C6FFCA988F5F4
TLS session ticket lifetime hint: 172800 (seconds)
TLS session ticket:
- e1 ec 9e 74 56 16 6a 55-7a 80 74 3d 2e 44 3e 0d ...tV.jUz.t=.D>.
0010 - 5f c0 6f 4a 8c d8 ec 2a-2b 27 91 29 de 04 3d 49 _.oJ...*+'.)..=I
0020 - f5 ae 40 d6 86 3e 3c 29-66 7b 3f ed c5 ad 80 b1 ..@..><)f{?.
0030 - bb 3e 0b b1 67 6b 07 4b-ac 9f 30 f3 9f 8b ba 3b .>..gk.K..0;
0040 - bf 51 24 e7 25 19 74 d2-c2 b1 c6 12 cb 50 dd 10 .Q$.%.t..P..
0050 - 4f 08 7f 12 36 de 4e 8d-50 05 32 99 71 e4 a0 aa O...6.N.P.2.q...
0060 - a6 35 30 5e ed a9 f1 f5-b4 59 46 62 60 d6 5b 9a .50^.YFb`.[.
0070 - 66 2d 6b 1f 69 ad b4 d3-52 b2 3e 83 16 92 93 38 f-k.i...R.>8
0080 - 59 70 9c 4c e7 f1 a4 e0-89 d4 6e 9b 47 f6 b5 be Yp.L..n.G...
0090 - bd 60 9c a1 3e ae 1d f1-0e d6 43 cb 0a 61 37 5d .`..>.C..a7]
00a0 - 9f f5 6d 46 e8 8a 75 3e-ea b6 8f c6 02 5e 67 1a ..mF..u>.^g.
Start Time: 1544866854
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
closed
Thanks and best regards,
Siegfried
> On Dec 14, 2018, at 1:59 PM, Zhi-Qiang Lei wrote:
>
> I’m having the same issue on OpenBSD 6.4. My iked.conf is similar to Rachel’s:
>
> include "/etc/iked/macros.conf"
>
> ikev2 quick active ipcomp esp proto gre\
>from 192.168.1.0/24 to $iked_server \
>local egress peer $iked_server \
>ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group
> curve2551
Re: TLS suddenly not working over IKED site-to-site
I’m having the same issue on OpenBSD 6.4. My iked.conf is similar to Rachel’s: include "/etc/iked/macros.conf" ikev2 quick active ipcomp esp proto gre\ from 192.168.1.0/24 to $iked_server \ local egress peer $iked_server \ ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519 \ childsa enc chacha20-poly130 group curve25519 \ dstid "asgard.local" Sites are reachable by ping, but https doesn’t respond at all. I was wondering if it is because the GRE part, will do more experiments. > On Dec 11, 2018, at 9:04 AM, Theodore Wynnychenko wrote: > > I would like to re-title this as something like "pf and iked instability on > recent snapshots," but don’t know if doing so would break the mailing list > thread, exiso, I left the subject unchanged... > >> -Original Message- >> From: Theodore Wynnychenko [mailto:t...@uchicago.edu] >> Sent: Saturday, December 08, 2018 4:03 PM >> To: misc@openbsd.org >> Cc: 'Rachel Roch' >> Subject: RE: TLS suddenly not working over IKED site-to-site >> >>> > . > . > . >> I now find I can no longer connect to with TLS/SSL over the iked tunnel >> (the original behavior that seemed to have corrected itself). Also, >> icinga continues to be unable to verify the status of the remote hosts >> over port 5665. >> >> I don't have time right now to try using s_client and s_server and >> watching enc0 to see what is happening, but I will when I can. >> >> If anyone has an ideas on what may be happening, please let me know. >> >> Thanks >> Ted > > > Hello again; > > So, I am at a complete loss to understand what is going on. > Today, I tried using openssl s_client and s_server to make a connection > through the iked vpn (as I described in my last post). However, with NO > changes to iked.conf or pf.conf, today I had several connection attempts that > completed correctly. I have not included any output from those sporadic, > completely functional connections. > > Rather, today, most of the connections by s_client are not even acknowledged > by the s_server on the other side of the iked vpn. > > For example: > On the s_client machine: > > # openssl s_client -state -connect "remote.host":https > SSL_connect:before/connect initialization > SSL_connect:SSLv3 write client hello A > ... and nothing more ... > > But on the s_server machine today all I see is: > # openssl s_sever -state -accept https ...certificate options... > Using auto DH parameters > Using default temp ECDH parameters > ACCEPT > ... and no connection attempt is ever acknowledged ... > > (Yesterday, at least this first part of the connection was received by the > s_server: > Using auto DH parameters > Using default temp ECDH parameters > ACCEPT > SSL_accept:before/accept initialization > ... and nothing more yesterday ...) > > > So, today using tcpdump on the outgoing interface of the s_client machine and > the incoming interface of the "local" iked vpn endpoint shows: > > 16:43:05.107524 172.30.1.254.7305 > 172.30.7.205.443: S > 1751796302:1751796302(0) win 16384 6,nop,nop,timestamp 2698316052 0> > > 16:43:05.149146 172.30.1.254.7305 > 172.30.7.205.443: . ack 2119500805 win > 256 > > 16:43:05.149895 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win > 256 > > 16:43:06.648487 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win > 256 > > 16:43:09.648557 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win > 256 > > 16:43:09.948433 172.30.1.254.7305 > 172.30.7.205.443: F 196:196(0) ack 1 win > 256 > > 16:43:15.648712 172.30.1.254.7305 > 172.30.7.205.443: FP 0:196(196) ack 1 win > 256 > > And this traffic (incomplete thought it may be for an ssl handshake) appears > to be passed to enc0 intact: > > 16:43:05.105044 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > > 172.30.7.205.443: S 3570513915:3570513915(0) win 16384 1300,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 2698316052 0> (encap) > > 16:43:05.146122 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > > 172.30.1.254.7305: S 1312941075:1312941075(0) ack 3570513916 win 16384 1300,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 3536824996 2698316052> > (encap) > > 16:43:05.146654 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > > 172.30.7.205.443: . ack 1 win 256 > (encap) > > 16:43:05.147365 (unprotected): SPI 0xef27: 172.30.1.254.7305 > > 172.30.7.205.443: P 1:197(196) ack 1 win 256 3536824996> (encap) > > 16:43:06.645932 (unprotected): SPI 0xef27: 172.30.1.254.7305 > > 172.30.7.205.443: P 1:197(196) ack 1 win 256 3536824996> (encap) > > 16:43:09.646049 (unprotected): SPI 0xef27: 172.30.1.254.7305 > > 172.30.7.205.443: P 1:197(196) ack 1 win 256 3536824996> (encap) > > 16:43:09.945908 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > > 172.30.7.205.443: F 197:197(0) ack 1 win 256 3536824996> (encap) > >
Re: [OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
After changed my from-to selectors in iked configuration, the gateway is almost working. [VPN Server] /etc/iked.conf: ikev2 quick passive ipcomp esp \ from 0.0.0.0/0 to 192.168.1.0/24 \ 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" [Gateway] /etc/iked.conf: ikev2 quick active ipcomp esp \ from 192.168.1.0/24 to $some_network \ 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" This is truly convenient thanks to the transparency. I don’t even have to mind the route. However, I still have some issues to add more policies: I have a blacklist contains the networks I don’t want to apply IPSec. When I was using OpenVPN, it was done by a pf rule: pass out quick from to ! route-to tun0 What is the best practice to do the same in /etc/iked.conf? My intuitive thoughts were: [Gateway] /etc/iked.conf: ikev2 quick active ipcomp esp \ from 192.168.1.0/24 to !$network1 \ … thousands of from-to … from 192.168.1.0/24 to !$network8000 \ 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" But ! operator and too many flows are causing error. > On Dec 12, 2018, at 10:37 PM, Zhi-Qiang Lei wrote: > > 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: e
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
[OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
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
Booting problem of my OpenBSD 5.7 road warrior
My road warrior has a PPPoE external connection and a tunnel connection, established with OpenVPN, which would encrypt the packets from some special devices. It works so well so far with the help with these rules in /etc/pf.conf: pass in quick on $int_if from $arch to !internal_addresses route-to $tun_if pass in quick on $int_if from $raspbmc to external_addresses route-to $tun_if pass out quick on $tun_if from any to any nat-to ($tun_if) However, every time when I reboot the machine, pf fails to load the rules because the tunnel is not ready. The tunnel generally would take some minutes to establish. Is it possible to defer the loading of pf rules until all interfaces are ready? I also tried to parenthesize $tun_if, but it failed due to syntax errors. pass in quick on $int_if from $arch to !internal_addresses route-to ($tun_if) pass in quick on $int_if from $raspbmc to external_addresses route-to ($tun_if) pass out quick on $tun_if from any to any nat-to ($tun_if) Best regards and thanks, Zhi-Qiang Lei
Re: NFS encoding?
Looks like there is no resolution but replacement. Thanks. http://superuser.com/questions/302407/what-to-do-with-nfs-server-utf-8-and-wi ndows-7 Best regards, Zhi-Qiang Lei On Jul 6, 2015, at 1:56 PM, Johan Petersson vhdlni...@gmail.com wrote: i really wish i could help you out - my girlfriend lives in hong kong so i understand the need to display chinese chars, i do. i have ran NFS for years, but only in a pure UNIX environment - bsd-versions, linux and osx. but i'm not any kind of NFS expert - i'd have to suggest that you try to read as many man-pages as you can. or check out the NFS source code. once you know the encoding, put the question to Microsoft. or simply stop using windows haha good luck! /Johan On Mon, Jul 6, 2015 at 7:36 AM, Zhi-Qiang Lei zhiqiang@gmail.com mailto:zhiqiang@gmail.com wrote: Is there such encoding option in NFS setting? And what encoding does OpenBSD used as default for filenames? Thanks for your suggestion though. Best regards, Zhi-Qiang Lei On Jul 6, 2015, at 1:02 PM, Johan Petersson vhdlni...@gmail.com mailto:vhdlni...@gmail.com wrote: that is not a question for the OpenBSD people if you ask me. win7 is junk, go ask microsoft this kind of questions On Mon, Jul 6, 2015 at 6:58 AM, Zhi-Qiang Lei zhiqiang@gmail.com mailto:zhiqiang@gmail.com wrote: I have an OpenBSD 5.6 server with NFS enabled. When I mount it on my Mac and Raspberry Pi, everything is fine. However, when I map it on Windows 7, all the filenames with Chinese in them cannot be displayed correctly. How can I fix this? Thanks. Best regards, Zhi-Qiang Lei
Re: NFS encoding?
Is there such encoding option in NFS setting? And what encoding does OpenBSD used as default for filenames? Thanks for your suggestion though. Best regards, Zhi-Qiang Lei On Jul 6, 2015, at 1:02 PM, Johan Petersson vhdlni...@gmail.com wrote: that is not a question for the OpenBSD people if you ask me. win7 is junk, go ask microsoft this kind of questions On Mon, Jul 6, 2015 at 6:58 AM, Zhi-Qiang Lei zhiqiang@gmail.com mailto:zhiqiang@gmail.com wrote: I have an OpenBSD 5.6 server with NFS enabled. When I mount it on my Mac and Raspberry Pi, everything is fine. However, when I map it on Windows 7, all the filenames with Chinese in them cannot be displayed correctly. How can I fix this? Thanks. Best regards, Zhi-Qiang Lei
NFS encoding?
I have an OpenBSD 5.6 server with NFS enabled. When I mount it on my Mac and Raspberry Pi, everything is fine. However, when I map it on Windows 7, all the filenames with Chinese in them cannot be displayed correctly. How can I fix this? Thanks. Best regards, Zhi-Qiang Lei
Re: install openbsd to the area made by LINUX's fdisk
Thanks for sharing. Best regards, Zhi-Qiang Lei On Mar 30, 2015, at 2:25 AM, Tuyosi Takesima nakajin.fu...@gmail.com wrote: Hi all. this is my little expirience , it may be useful using openbsd linux in tha same hard disk . I made the openbsd area by LINUX's fdisk. namely fdisk -l /dev/sdb (500GB USB hard disk) Device Boot Start End Sectors Size Id Type sdb1 22528 3891199 3868672 1.9G 82 Linux swap / Solaris sdb2 2048 22527 20480 10M c W95 FAT32 (LBA) sdb3 3891200 842751999 838860800 400G 5 Extended sdb4 842752000 976773167 134021168 63.9G a6 OpenBSD sdb5 3893248 213608447 209715200 100G 83 Linux sdb6 * 213610496 528183295 314572800 150G 83 Linux sdb7 528185344 842751999 314566656 150G 7 HPFS / NTFS / exFAT i want to install openbsd OS into sdb4 . But to install OpenBSD directly is risky . if i fail , i lose all (including linux) . So I changed the strategy. install first on 2G USB. then clone copy to 500G USB sdb4 . After connecting the 2G USB and 500G USB , I boot by openbsd CD . press ctrl + c, I look at the way of 2G and 500G by 'dmesg' . 500G is recognized as sd1. 2G as sd2. i install openbsd OS into ---OpenBSD area---. When sd1 is formatted , i put ctrl + c. my way is always a (/) and b (swap) only . so # mkdir / mnt0 # mkdir / mnt1 # Mount /dev/sd2a / mnt0 # Mount /dev/sd1a / mnt1 # (cd / mnt0;. tar cvpf -) | (cd / mnt1; tar xpf -) clone copy itself is completed. But the boot loader is not . Therefore I will install boot loader . afte unplug the 2G, put 500G only ,then i boot by openbsd CD. Now select the ---upgrade---, When i came to the stage 'bsd.rd etc', i select ---abort---. all is done . by using previos menu.lst , i boot openbsd in 500G by grub4dos . After i launched openbsd , I comment out the xdm in /etc/rc.conf.local. sorry for my poor english --- tuyosi takesima , Japan
Route for a special IP
I have a OpenBSD 5.6 router with two external interfaces pppoe0 and tun0. Generally, all packets will go through pppoe0. However, now I have a special client with IP 192.168.1.200, is it possible to force it to use tun0? Thanks. Best regards, Zhi-Qiang Lei
Re: Route for a special IP
Thank you. This fix my problem. pass in quick from $vip to !192.168.1.0/24 route-to tun0 pass out quick on tun0 from $vip to any nat-to tun0 Best regards, Zhi-Qiang Lei On Mar 12, 2015, at 4:54 AM, Giancarlo Razzolini grazzol...@gmail.com wrote: On 11-03-2015 12:39, Zhi-Qiang Lei wrote: I have a OpenBSD 5.6 router with two external interfaces pppoe0 and tun0. I am assuming the pppoe0 connects directly to the internet and tun0 also has internet connectivity at the other end of the tunnel, right? Generally, all packets will go through pppoe0. However, now I have a special client with IP 192.168.1.200, is it possible to force it to use tun0? Thanks. You can do this with a simple route-to rule: pass in quick from 192.168.1.200 to any route-to tun0 If tun0 has a fixed gateway address you can change the rule to: pass in quick from 192.168.1.200 to any route-to (tun0 gateway) Cheers, Giancarlo Razzolini
Re: Route for a special IP
vip=192.168.1.200 pass in quick from $vip to !192.168.1.0/24 route-to tun0 pass out quick on tun0 from $vip to any nat-to tun0 Best regards, Zhi-Qiang Lei On Mar 12, 2015, at 1:34 PM, Zhi-Qiang Lei zhiqiang@gmail.com wrote: Thank you. This fix my problem. pass in quick from $vip to !192.168.1.0/24 route-to tun0 pass out quick on tun0 from $vip to any nat-to tun0 Best regards, Zhi-Qiang Lei On Mar 12, 2015, at 4:54 AM, Giancarlo Razzolini grazzol...@gmail.com mailto:grazzol...@gmail.com wrote: On 11-03-2015 12:39, Zhi-Qiang Lei wrote: I have a OpenBSD 5.6 router with two external interfaces pppoe0 and tun0. I am assuming the pppoe0 connects directly to the internet and tun0 also has internet connectivity at the other end of the tunnel, right? Generally, all packets will go through pppoe0. However, now I have a special client with IP 192.168.1.200, is it possible to force it to use tun0? Thanks. You can do this with a simple route-to rule: pass in quick from 192.168.1.200 to any route-to tun0 If tun0 has a fixed gateway address you can change the rule to: pass in quick from 192.168.1.200 to any route-to (tun0 gateway) Cheers, Giancarlo Razzolini
Re: Route for a special IP
It was just a router which does NAT for local devices in 192.168.1.0/24. The external interface, of cause, was pppoe0. Now for some reason, I want one of the device with IP 192.168.1.200 communicate with outside through the tunnel interface tun0 created by OpenVPN. Normally I should setup OpenVPN client on that device, but it has a low frequency CPU. Best regards, Zhi-Qiang Lei On Mar 12, 2015, at 4:00 AM, Adam Thompson athom...@athompso.net wrote: On 03/11/2015 10:39 AM, Zhi-Qiang Lei wrote: I have a OpenBSD 5.6 router with two external interfaces pppoe0 and tun0. Generally, all packets will go through pppoe0. However, now I have a special client with IP 192.168.1.200, is it possible to force it to use tun0? Thanks. From route(8): route -v add -inet -host 192.168.1.200 A.B.C.D However, since AFAIK tun(4) interfaces on OpenBSD generally only occur when using OpenVPN you'd be better off letting OpenVPN manage tunnel routes for you. If you've written some userspace daemon that talks to tun0, then 1) WTF are you doing?, and 2) you will need to either execute the above command or its programmatic equivalent - see route(4) for details. -Adam
Re: Remote client cannot mount NFS
Thanks! Setting -mapall=root makes a quick fix! Best regards, Zhi-Qiang Lei On Mar 6, 2015, at 6:59 PM, Raf Czlonka rczlo...@gmail.com wrote: On Fri, Mar 06, 2015 at 10:48:01AM GMT, Zhi-Qiang Lei wrote: It was root. man 5 exports In the absence of -maproot and -mapall options, remote accesses by root will result in using a credential of -2:-2. All other users will be mapped to their remote credential. If a -maproot option is given, remote access by root will be mapped to that credential instead of -2:-2. If a -mapall option is given, all users (including root) will be mapped to that credential in place of their own. # ls -n /mnt It shows nothing. Obviously I missed out 'a' :^) ls -na /mnt Raf
Re: Remote client cannot mount NFS
It was root. # mount -t nfs -o rw 192.168.1.1:/nfs /mnt # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 3.9G 52.3M3.7G 1%/ /dev/wd0k 9.9G4.0K9.4G 0%/home /dev/wd0l 1.7T8.0K1.6T 0%/nfs /dev/wd0d 3.9G4.0K3.7G 0%/tmp /dev/wd0f 9.8G310M9.0G 3%/usr /dev/wd0g 3.9G2.0K3.7G 0%/usr/X11R6 /dev/wd0h 9.8G216K9.3G 0%/usr/local /dev/wd0j 9.8G2.0K9.3G 0%/usr/obj /dev/wd0i 9.8G2.0K9.3G 0%/usr/src /dev/wd0e 9.8G5.5M9.3G 0%/var 192.168.1.1:/nfs1.7T8.0K1.6T 0%/mnt # touch /mnt/h.txt touch: /mnt/h.txt: Permission denied # id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest) # ls -n /mnt It shows nothing. Best regards, Zhi-Qiang Lei On Mar 6, 2015, at 6:12 PM, Raf Czlonka rczlo...@gmail.com wrote: ls -n /mnt
Re: Remote client cannot mount NFS
I have created a new user named nfs for that. :P Best regards, Zhi-Qiang Lei On Mar 6, 2015, at 8:05 PM, Stuart Henderson s...@spacehopper.org wrote: On 2015-03-06, Zhi-Qiang Lei zhiqiang@gmail.com wrote: Thanks! Setting -mapall=root makes a quick fix! -mapall=root? Yikes!
Re: Remote client cannot mount NFS
Now it is weird that it is read only. According to exports manual, it should be read / write as default: The -ro option specifies that the filesystem should be exported read-only (default read/write). The option -o is a synonym for -ro in an effort to be backward compatible with older export file formats. My exports doesnât contain a -ro. # cat /etc/exports /nfs -mapall=nfs -alldirs -network=192.168.1 -mask=255.255.255.0 I cannot write even on the server (192.168.1.1): # mount -t nfs -o rw 192.168.1.1:/nfs /mnt # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 3.9G 52.3M3.7G 1%/ /dev/wd0k 9.9G4.0K9.4G 0%/home /dev/wd0l 1.7T8.0K1.6T 0%/nfs /dev/wd0d 3.9G4.0K3.7G 0%/tmp /dev/wd0f 9.8G310M9.0G 3%/usr /dev/wd0g 3.9G2.0K3.7G 0%/usr/X11R6 /dev/wd0h 9.8G216K9.3G 0%/usr/local /dev/wd0j 9.8G2.0K9.3G 0%/usr/obj /dev/wd0i 9.8G2.0K9.3G 0%/usr/src /dev/wd0e 9.8G5.4M9.3G 0%/var 192.168.1.1:/nfs1.7T8.0K1.6T 0%/mnt # touch /mnt/h.txt touch: /mnt/h.txt: Permission denied Best regards, Zhi-Qiang Lei On Mar 6, 2015, at 2:51 PM, Zhi-Qiang Lei zhiqiang@gmail.com wrote: It works like a charm! Thank you! $ sudo mount_nfs -P 192.168.1.1:/nfs mnt $ df -h Filesystem Size Used Avail Capacity iusedifree %iused Mounted on /dev/disk1112Gi 107Gi 5.0Gi96% 28016815 1310543 96% / devfs 185Ki 185Ki0Bi 100% 6400 100% /dev map -hosts 0Bi0Bi0Bi 100%00 100% /net map auto_home 0Bi0Bi0Bi 100%00 100% /home 192.168.1.1:/nfs 1.7Ti 8.0Ki 1.6Ti 1%1 587389410% /Users/siegfried/mnt Best regards, Zhi-Qiang Lei On Mar 6, 2015, at 12:21 AM, Gabriel Kihlman g...@stacken.kth.se mailto:g...@stacken.kth.se wrote: Zhi-Qiang Lei zhiqiang@gmail.com mailto:zhiqiang@gmail.com writes: $ sudo mount -t nfs 192.168.1.1:/nfs mnt Password: mount_nfs: can't mount /nfs from 192.168.1.1 onto /Users/siegfried/mnt: Permission denied What could be the problem? How can I debug it? Thanks. It used to be that you needed to mount with -P from mac: sudo mount_nfs -P server.address:/path/to/share /path/to/local/directory Not sure if that is still the case but it might be worth a try? /gabriel
Re: Remote client cannot mount NFS
It works like a charm! Thank you! $ sudo mount_nfs -P 192.168.1.1:/nfs mnt $ df -h Filesystem Size Used Avail Capacity iusedifree %iused Mounted on /dev/disk1112Gi 107Gi 5.0Gi96% 28016815 1310543 96% / devfs 185Ki 185Ki0Bi 100% 6400 100% /dev map -hosts 0Bi0Bi0Bi 100%00 100% /net map auto_home 0Bi0Bi0Bi 100%00 100% /home 192.168.1.1:/nfs 1.7Ti 8.0Ki 1.6Ti 1%1 587389410% /Users/siegfried/mnt Best regards, Zhi-Qiang Lei On Mar 6, 2015, at 12:21 AM, Gabriel Kihlman g...@stacken.kth.se wrote: Zhi-Qiang Lei zhiqiang@gmail.com writes: $ sudo mount -t nfs 192.168.1.1:/nfs mnt Password: mount_nfs: can't mount /nfs from 192.168.1.1 onto /Users/siegfried/mnt: Permission denied What could be the problem? How can I debug it? Thanks. It used to be that you needed to mount with -P from mac: sudo mount_nfs -P server.address:/path/to/share /path/to/local/directory Not sure if that is still the case but it might be worth a try? /gabriel
Remote client cannot mount NFS
I simply started a NFS on my OpenBSD 5.6 server as flow: # cat /etc/exports /nfs -alldirs -network=192.168.1 -mask=255.255.255.0 Iâm able to mount it on the OpenBSD server: # mount -t nfs 192.168.1.1:/nfs /mnt # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 3.9G 52.3M3.7G 1%/ /dev/wd0k 9.9G4.0K9.4G 0%/home /dev/wd0l 1.7T8.0K1.6T 0%/nfs /dev/wd0d 3.9G4.0K3.7G 0%/tmp /dev/wd0f 9.8G310M9.0G 3%/usr /dev/wd0g 3.9G2.0K3.7G 0%/usr/X11R6 /dev/wd0h 9.8G216K9.3G 0%/usr/local /dev/wd0j 9.8G2.0K9.3G 0%/usr/obj /dev/wd0i 9.8G2.0K9.3G 0%/usr/src /dev/wd0e 9.8G5.3M9.3G 0%/var 192.168.1.1:/nfs1.7T8.0K1.6T 0%/mnt However, I cannot mount it on my Mac: $ mount -t nfs 192.168.1.1:/nfs mnt mount_nfs: can't mount /nfs from 192.168.1.1 onto /Users/siegfried/mnt: Permission denied $ sudo mount -t nfs 192.168.1.1:/nfs mnt Password: mount_nfs: can't mount /nfs from 192.168.1.1 onto /Users/siegfried/mnt: Permission denied What could be the problem? How can I debug it? Thanks. Best regards, Zhi-Qiang Lei
Re: Remote client cannot mount NFS
According to the FAQ, I think 192.168.1 represents the network 192.168.1.0. http://www.openbsd.org/faq/faq6.html#NFS http://www.openbsd.org/faq/faq6.html#NFS The IP of Mac is 192.168.1.36. And the IP of server is 192.168.1.1. If I run showmount on Mac, I get these: $ showmount -e 192.168.1.1 Exports list on 192.168.1.1: /nfs192.168.1.0 Here is what I found in manual of mount_nfs on Mac: nfsvers=num Set the NFS protocol version number - 2 for NFSv2, 3 for NFSv3 and 4 for NFSv4. The default is to try version 3 first, and fall back to ver- sion 2 if the mount fails. Best regards, Zhi-Qiang Lei On Mar 6, 2015, at 1:26 PM, Philip Guenther guent...@gmail.com wrote: On Thu, Mar 5, 2015 at 6:52 PM, Zhi-Qiang Lei zhiqiang@gmail.com wrote: I simply started a NFS on my OpenBSD 5.6 server as flow: # cat /etc/exports /nfs -alldirs -network=192.168.1 -mask=255.255.255.0 You sure about that 192.168.1, with only three components? I believe that'll be interpreted as 192.168.0.1, which may not be what you mean...and doesn't match your loopback mount below. Iâm able to mount it on the OpenBSD server: # mount -t nfs 192.168.1.1:/nfs /mnt # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 3.9G 52.3M3.7G 1%/ /dev/wd0k 9.9G4.0K9.4G 0%/home /dev/wd0l 1.7T8.0K1.6T 0%/nfs ... 192.168.1.1:/nfs1.7T8.0K1.6T 0%/mnt However, I cannot mount it on my Mac: $ mount -t nfs 192.168.1.1:/nfs mnt mount_nfs: can't mount /nfs from 192.168.1.1 onto /Users/siegfried/mnt: Permission denied $ sudo mount -t nfs 192.168.1.1:/nfs mnt Password: mount_nfs: can't mount /nfs from 192.168.1.1 onto /Users/siegfried/mnt: Permission denied What IP will that Mac be using as its source address? From that Mac, what's showmount -e 192.168.1.1 show? What version of NFS does the Mac documentation say it'll use in this case? Philip Guenther
Load PF after all networks are ready
My router powered by OpenBSD 5.6 is connecting to a WAN via PPPoE. After boot I have to run âpf -f /etc/pf.confâ to get NAT work. Is PF loaded before the PPPoE is ready? How can I fix it? Thanks. # $OpenBSD: pf.conf,v 1.53 2014/01/25 10:28:36 dtucker Exp $ # # See pf.conf(5) for syntax and examples. # Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1 # in /etc/sysctl.conf if packets are to be forwarded between interfaces. # increase default state limit from 10'000 states on busy systems #set limit states 10 set skip on lo # filter rules and anchor for ftp-proxy(8) #anchor ftp-proxy/* #pass in quick inet proto tcp to port ftp divert-to 127.0.0.1 port 8021 # anchor for relayd(8) #anchor relayd/* block return# block stateless traffic pass# establish keep-state # rules for spamd(8) #table spamd-white persist #table nospamd persist file /etc/mail/nospamd #pass in 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 nospamd to any port smtp #pass in log on egress proto tcp from spamd-white to any port smtp #pass out log on egress proto tcp to any port smtp #block in quick from urpf-failed to any # use with care # By default, do not permit remote connections to X11 block return in on ! lo0 proto tcp to port 6000:6010 ext_if=pppoe0 int_if=vether0 lan=$int_if:network pass out on $ext_if from $lan to any nat-to $ext_if Best regards, Zhi-Qiang Lei
Re: npppd ipsec port 500 INVALID_MESSAGE_ID
On Oct 4, 2014, at 5:51 PM, mishve...@rambler.ru wrote: I have OpenBSD 5.4 amd64. I install npppd and configure IPSec(l2tp + password). LAN 192.168.1.1/255.255.255.0 WAN(ISP NET; Connect by MAC ddress) 10.0.0.1/255.0.0.0 ISP GET ME GLOBAL IP SERVER1-Openbsd - 1.2.3.4 WIN 2003 SERVER2 IP - 9.8.7.6 WIN 2003 SERVER3 IP - 192.168.1.100 When server boot # cat /etc/hostname.em0 inet 192.168.1.1 255.255.255.0 # ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 priority: 0 media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) status: active inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 # cat /etc/hostname.re0 dhcp # ifconfig re0 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) status: active inet 10.200.81.220 netmask 0xf000 broadcast 10.200.95.255 # route show Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 10.200.80.1 UGS 6 1439 - 8 re0 10.200.80/20 link#2 UC 1 0 - 4 re0 10.200.80.1 28:6e:d4:6e:0a:e1 UHLc 1 0 - 4 re0 10.200.81.220 localhost UGS 0 0 33144 8 lo0 loopback localhost UGRS 0 0 33144 8 lo0 localhost localhost UH 2 35 33144 4 lo0 192.168.1/24 link#1 UC 2 0 - 4 em0 192.168.1.67 00:1a:13:18:b3:7c UHLc 0 0 - 4 em0 192.168.1.255 link#1 UHLc 3 43 - 4 em0 BASE-ADDRESS.MCAST localhost URS 0 0 33144 8 lo0 # cat /etc/resolv.conf # Generated by re0 dhclient search smilenet.ru nameserver 10.0.1.24 nameserver 10.0.1.13 From LAN i connect win server 192.168.1.100 to 192.168.1.1. From internet i can't connect win server 9.8.7.6 to 1.2.3.4 # cat /etc/ipsec.conf ike passive esp transport proto udp from 192.168.1.1 to 192.168.1.100 port 1701 main auth hmac-sha1 enc 3des group modp2048 quick auth hmac-sha1 enc 3des psk pass ike passive esp transport proto udp from 10.200.81.220 to 9.8.7.6 port 1701 main auth hmac-sha1 enc 3des group modp2048 quick auth hmac-sha1 enc 3des psk pass ike passive esp transport proto udp from 1.2.3.4 to 9.8.7.6 port 1701 main auth hmac-sha1 enc 3des group modp2048 quick auth hmac-sha1 enc 3des psk pass # tail /var/log/daemon isakmpd: message_recv: invalid message id isakmpd: dropped message from 9.8.7.6 port 500 due to notification type INVALID_MESSAGE_ID Please help me connect server2 9.8.7.6 to 1.2.3.4 L2TP over IPsec on OpenBSD 5.5 is very easy for me, you may read my guide. http://siegfried.github.io/unix/openbsd/vpn/ipsec/l2tp/2014/09/29/l2tp-over-ipsec-vpn-on-openbsd-5-5/
Both PPTP and L2TP on npppd?
I’m running a L2TP server using npppd on OpenBSD 5.5. Is it possible to run both PPTP and L2TP using npppd? I tried to append a tunnel for pptp in default configuration then my L2TP could not work. Best regards
