On Fri, Oct 05, 2018 at 12:03:04PM +0200, Toke Høiland-Jørgensen wrote:
> > When you're doing policy routing with packets that are being forwarded
> > by the system -- a router, for example -- then the prerouting table is
> > sufficient. But for locally generated packets, you have to use the
> > OUTPUT table and also probably MASQUERADE. I just reproduced
> > everything here and confirm this works:
> >
> > ip route add default dev wg0 table 2468
> > ip rule add fwmark 1234 table 2468
> > wg set wg0 peer [...] allowed-ips 0.0.0.0/0
> > sysctl net.ipv4.conf.wg0.rp_filter=0
> > iptables -t nat -A POSTROUTING -p tcp --dport 22 -m addrtype
> > --src-type LOCAL -j MASQUERADE
> > iptables -t mangle -A OUTPUT -p tcp --dport 22 -j MARK --set-mark 1234
> 
> Any reason why you can't just do
> 
> ip rule add dport 22 lookup 2468

Yeah, this works, too, and is quite a bit simpler. Jason, any reason why
I wouldn't use this?

To help explain the use-case here, here's what I'm trying to achieve.

We currently require that all admin-level access goes through 2-factor
authentication. For ssh, we require using SmartCard-capable hardware
tokens (Yubikey, Nitrokey), such that the private key for establishing a
connection is never exposed to the main OS -- so all our ssh connections
are inherently 2-factor authenticated.

However, that is not a mechanism we can use for accessing non-ssh things
such as various web-management interfaces on internal networks.
Therefore, we require that the VPN connection itself goes through
2-factor authentication step -- admins put in their password and their
TOTP/HOTP token value when establishing a connection. This works, but is
annoying to have to do when most of the time all an admin needs is ssh.
Every time there is a network blip, the admin loses their OpenVPN link
and, if they don't re-establish it quickly enough (typing in their
username, password, TOTP token value), then their ssh sessions reset.
Quite possibly the worst thing to happen to an admin in the middle of
troubleshooting something.

Similarly, if there's an alert in the middle of the night that requires
checking something out, it's annoying to have to first establish an
OpenVPN connection before being able to ssh in to a system.

So, we're working on a new setup where admins would have an always-on
WireGuard connection to the infra, but that connection only allows ssh
traffic. In this case, don't need 2-factor on the wireguard link, just
packet encapsulation. But should the admin need to bring up the OpenVPN
link for accessing something like an iDrac interface on a Dell, they
need to be able to do this without needing to shut down their WireGuard
tunnel first (since both WG and OpenVPN provide routing to the same
internal ip ranges). Therefore, I was looking for a way to *only* send
port 22 traffic on the wg link.

The following achieves what we need:

[Interface]
PrivateKey = [omitted]
Address = [omitted]
DNS = 127.0.0.1
Table = 2468
PostUp = ip rule add to 10.10.0.0/16 dport 22 lookup 2468
PostDown = ip rule del to 10.10.0.0/16 dport 22 lookup 2468

[Peer]
PublicKey = [omitted]
AllowedIPs = 10.10.0.0/16
Endpoint = [omitted]

This achieves what we need *quite* nicely!

Thanks for your help!

-K