New article: blog.daveeddy.com/2026/07/06/illumos-doors

extrowerk: that's awesome, I love that there's a rust crate for doors

... though I do just keep thinking in my head the whole way through... BUT WHAT ABOUT door_knob

._.

is that ptsd? it might be ptsd

There is also, for completeness, github.com/robertdfrench/rusty-doors

Who'd have thought we'd have so many people working on rust+doors on illumos.

I keep chuckling every time I see 'cow-path.cc' built while building gcc.

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?

So I have st up a etherstub according to this guide : antranigv.am/posts/2024/02/omnios-mirror-one

From the NGZ I can ping the GZ, but pinging a 3rd party host from NGZ is unsucessful. Is this expected?

I belive it should work.

the instructions don't mention turning on ip forwarding in the GZ

you can do that with routeadm

sommerfeld: thanks for the hint!

After a "routeadm -e ipv4-forwarding" and "routeadm -u

it shows now IPv4 forwarding enabled enabled

however it is still not working. maybe i need routing aswell?

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

let me see

routing updates the routing table with routes learned via the routing protocol. forwarding pushes packets between interfaces.

if you want to do nat you need to enable forwarding.

next thing to look at would be the default route in the NGZ

is there one?

default 10.10.0.1 UGZ 3 55 dns0

this is a partial NGZ netstat -r -n output,

in the GZ: ipadm show-ifprop -p forwarding

and

ipadm show-prop -p forwarding ipv4

sommerfeld: paste.omnios.org/?becfd625f6a3b58e#…FkZnjd3qrU5cZ1pZa1DH1h2RsNPq2c1QwC8

dns is NGZ, backup is GZ

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?

I see lines like: 152.53.64.1 -> 8.8.8.8 ICMP Echo request (ID: 4095 Sequence number: 5)

the sequence number increasing

also in ipnat output:

MAP 10.10.0.2 <- -> 152.53.64.1 [8.8.8.8]

so I think you have the nat rules incorrect

looks like the GZ' address is 152.63.64.73, and 152.53.64.1 is its default router

you need to rewrite the internal addresses to the GZ's address

GZ is 152.53.67.73/22, its gateway is 152.53.64.1

cat /etc/ipf/ipnat.conf

map vioif0 10.10.0.0/24 -> 152.53.67.73/22

oh.

should be

map vioif0 10.10.0.0/24 -> 152.53.67.73/32

with the /22, it gives it a whole prefix to rewrite into

YAY, ping works now

Thank you very much!

Glad to be able to help.

Grazie mille!

extrowerk yeeeeey

and thank you for finding these missing parts, I'll add them to part one

Thanks mate!

now i need to figure out why my naive firewall rules in GZ blocks dns resolution in NGZ:

dig works without the last block

adding that breaks the communication

have you looked at the log of dropped packets?

(you may need to update syslog.conf to route local0.info to a log file)

see ipmon(8)