02:44:01 <extrowerk> New article: https://blog.daveeddy.com/2026/07/06/illumos-doors/
03:25:03 <arekinath> extrowerk: that's awesome, I love that there's a rust crate for doors
03:25:22 <arekinath> ... though I do just keep thinking in my head the whole way through... BUT WHAT ABOUT door_knob
03:25:23 <arekinath> ._.
03:27:31 <arekinath> is that ptsd? it might be ptsd
09:48:08 <andyf> There is also, for completeness, https://github.com/robertdfrench/rusty-doors
09:50:18 <andyf> Who'd have thought we'd have so many people working on rust+doors on illumos.
14:11:59 <sommerfeld> I keep chuckling every time I see 'cow-path.cc' built while building gcc.
17:46:31 <extrowerk> I'd like to create a VPN connection (or similar) between my omnios NAS in my lan and my cloud omniOS instance. AFAIK the tun/tap driver is not the most efficient way. What are the alternative options?
18:58:23 <extrowerk> So I have st up a etherstub according to this guide : https://antranigv.am/posts/2024/02/omnios-mirror-one/
18:59:46 <extrowerk> From the NGZ I can ping the GZ, but pinging a 3rd party host from NGZ is unsucessful. Is this expected?
19:05:20 <extrowerk> I belive it should work.
19:08:24 <sommerfeld> the instructions don't mention turning on ip forwarding in the GZ
19:08:49 <sommerfeld> you can do that with routeadm
19:22:15 <extrowerk> sommerfeld: thanks for the hint!
19:25:04 <extrowerk> After a "routeadm -e ipv4-forwarding" and "routeadm -u
19:25:22 <extrowerk> it shows now  IPv4 forwarding   enabled              enabled
19:25:42 <extrowerk> however it is still not working. maybe i need routing aswell?
19:31:32 <wiedi_> no, "routing" will run a routing protocol which is usually not what you need. I'd double check the nat rules and the static routes in both zones make sense
19:34:59 <extrowerk> let me see
19:38:09 <sommerfeld> routing updates the routing table with routes learned via the routing protocol.  forwarding pushes packets between interfaces.  
19:38:25 <sommerfeld> if you want to do nat you need to enable forwarding.
19:38:43 <sommerfeld> next thing to look at would be the default route in the NGZ
19:38:48 <sommerfeld> is there one?
19:39:04 <extrowerk> default              10.10.0.1            UGZ       3         55 dns0      
19:39:30 <extrowerk> this is a partial NGZ netstat -r -n output, 
19:39:49 <sommerfeld>  in the GZ: ipadm show-ifprop -p forwarding
19:40:34 <sommerfeld> and
19:40:37 <sommerfeld> ipadm show-prop -p forwarding ipv4   
19:42:31 <extrowerk> sommerfeld: https://paste.omnios.org/?becfd625f6a3b58e#8foN7wkFPFkZnjd3qrU5cZ1pZa1DH1h2RsNPq2c1QwC8
19:42:57 <extrowerk> dns is NGZ, backup is GZ
19:48:50 <sommerfeld> so next thing to do is see if packets are actually leaving the GZ.   in GZ: "snoop -rd vioif0", while in NGZ: "ping -ns 8.8.8.8".   do you see packets leaving?   do you see flow entries appear in the output of "ipnat -l" in the GZ?
19:53:58 <extrowerk> I see lines like: 152.53.64.1 -> 8.8.8.8      ICMP Echo request (ID: 4095 Sequence number: 5)
19:54:06 <extrowerk> the sequence number increasing
19:54:53 <extrowerk> also in ipnat output:
19:54:55 <extrowerk> MAP 10.10.0.2       <- -> 152.53.64.1     [8.8.8.8]
19:56:03 <sommerfeld> so I think you have the nat rules incorrect
19:56:26 <sommerfeld> looks like the GZ' address is 152.63.64.73, and 152.53.64.1 is its default router
19:56:39 <sommerfeld> you need to rewrite the internal addresses to the GZ's address
19:58:10 <extrowerk> GZ is  152.53.67.73/22, its gateway is 152.53.64.1
19:58:38 <extrowerk> cat /etc/ipf/ipnat.conf 
19:58:38 <extrowerk> map vioif0 10.10.0.0/24 -> 152.53.67.73/22
19:59:06 <sommerfeld> oh.
19:59:13 <sommerfeld> should be
19:59:23 <sommerfeld>  map vioif0 10.10.0.0/24 -> 152.53.67.73/32
19:59:55 <sommerfeld> with the /22, it gives it a whole prefix to rewrite into
20:00:02 <extrowerk> YAY, ping works now
20:00:52 <extrowerk> Thank you very much!
20:11:00 <sommerfeld> Glad to be able to help.
20:12:11 <extrowerk> Grazie mille!
20:15:09 <antranigv> extrowerk yeeeeey
20:15:19 <antranigv> and thank you for finding these missing parts, I'll add them to part one
20:15:37 <extrowerk> Thanks mate!
20:16:10 <extrowerk> now i need to figure out why my naive firewall rules in GZ blocks dns resolution in NGZ:
20:16:54 <extrowerk> https://paste.omnios.org/?a53dc4f861e2e608#7ppyB5Gj7dEafz8NM7qEJyssLJ1CrfsmRcSspTBqh2tq
20:17:25 <extrowerk> dig works without the last block
20:17:38 <extrowerk> adding that breaks the communication
20:30:04 <sommerfeld> have you looked at the log of dropped packets?
20:30:46 <sommerfeld> (you may need to update syslog.conf to route local0.info to a log file)
20:31:11 <sommerfeld> see ipmon(8)