Hacker News Reader

Comment by thrwaway1985882 | Hacker News Reader

thrwaway1985882

> Instead of using UDP he reads the firewall log.

Hah! I'd never seen this before, but in a fit of pique driven by ssh scanning one day I did a similar pattern on my OpenBSD router: I added a block in log to a high port in pf.conf, wired up a little shell script that did tcpdump on pflog0 and watched for a packet to come in, then added the IP to the allow port 22 table.

I knocked on the door three times, two of which were testing, and ended up throwing it all out in favor of wireguard & making SSH no longer listen on em0, which seems infinitely less silly.

View on HN

I know its very minor, but are there ergonomic improvements possible to this setup besides shell aliases/functions around pairing `wg-up host && ssh host && wg-down host`?

I agree that ultimately, with wg in the kernel, this is a much simpler setup.

From the OpenBSD perspective, I just populate /etc/hostname.wg0 on my laptop with my wg configuration ... and I can immediately `ssh router` at home or on the road :-)

IOW, why ever down the connection? Why not start your tunnel immediately when the network comes up and leave it running until the network goes down?

I was thinking about doing this to multiple different servers and thought they could all share the same vpn network address for simpler configuration but now that I think about it doing that might run into constant server-key-changed warnings from SSH.

If you need a management vlan, make one.

Wireguard interfaces are _cheap and easy_ - there's no reason not to set up an interface for normal client traffic that sshd doesn't listen on, and an interface for just sshd with different ACLs and routing logic if you want.

You don't really have to do that. Wireguard is very silent protocol. Even when you bring up the interface, unless you are sending anything to that interface, it will not redo the handshake. So you can keep it up all the time.

This is why you sometimes have to enable PersistentKeepalive on peers that are behind NAT and are calling in to the server. Without them keeping up the connection NAT would simply close it down and you wouldn't be able to connect.

Well, tcpdump is explicitely not what you want to do in this case as Moxie points out, but other than that i guess, yes, it's similar.

> Well, tcpdump is explicitely not what you want to do in this case as Moxie points out

Why's that?

E: oh, if you aren't familiar with OpenBSD I might get the confusion – pflogd/the kernel (not me!) watches the actual network device and dumps to a file. So the actual "knocking" daemon I bodged together is one part running as a privsep user watching a log file and giving IPs to the other part which just adds to the pf table allowing access.

My threat model didn't include people who can fuck with pflog(4) to attack tcpdump(8) - I'm sure they're out there, and if they wanted to be they'd already be in my network (or already are).

Ah, that makes sense. I actually didn't know that about openbsd.

Reply on news.ycombinator.com