Rootless with capabilities: iptables not needed?

[o-alquimista]

Following the wiki page for running udp2raw rootless, I've tested whether it could work without the -a option and without manually adding the iptables rule, and surprisingly it did. So, is the CAP_NET_RAW capability the sole requirement? At least on Linux, of course. If so, I believe the wiki page needs an update.

If not, I'd appreciate if you could help me figure out why it's working. The capability allows it to bypass the firewall?

To make sure there is no rule allowing port 4096 in, I ran sudo iptables -L | grep 4096, and it returns nothing - nada. Initially I had a rule for it.

• I use UFW on Raspberry Pi OS bookworm
• A system user named _udp2raw was created to run the binary

The systemd unit I'm using:

[Unit]
Description=Start udp2raw as a server
After=network.target

[Service]
Type=simple
User=_udp2raw
ExecStart=/usr/local/bin/udp2raw -s -l [::]:4096 -r [::1]:51820 -k "my_password" --raw-mode faketcp -a

[Install]
WantedBy=multi-user.target

[wangyu-]

The capability allows it to bypass the firewall?

no, that's not the case.

iptables is still needed either by -a or manually.

udp2raw might work without iptables, depend on ISP, but stability might be compromised.

I believe CAP_NET_RAW shouldn't make difference other than root or not.

[o-alquimista]

Sorry, I neglected to mention that I'm testing the client from inside my home network - where the server is running. That could be why it's working.

So, udp2raw generates the following iptables rule:

iptables -I INPUT -p tcp -m tcp --dport 4096 -j DROP

I'm ignorant on iptables. Is this equivalent to ufw allow 4096 in ufw? If not, what this does?

---

EDIT

Ok, it seems ufw allow 4096 creates the rule:

ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:4096

And udp2raw creates this:

DROP       tcp  --  anywhere             anywhere             tcp dpt:4096

They seem to do opposite things. One accepts, the other drops. I don't understand why would udp2raw want to drop the connection.

[wangyu-]

iptables -I INPUT -p tcp -m tcp --dport 4096 -j DROP

They seem to do opposite things. One accepts, the other drops. I don't understand why would udp2raw want to drop the connection.

The DROP blocks linux kernel's build-in tcp handling, so that udp2raw can take full control of the given port (4096 in the example).

Iptables works at level 3 (IP level), DROP only affects level 3 and above.  udp2raw receives packets at level 2, DROP doesn't affect udp2raw's receiving packet. DROP stops packets from being passed to the kernel TCP stack.

[o-alquimista]

I think I understand. So, the only rule needed is the DROP, right? That means the ACCEPT rule I was adding is not needed. Is that correct?

[wangyu-]

I think I understand. So, the only rule needed is the DROP, right? That means the ACCEPT rule I was adding is not needed. Is that correct?

correct.

The ACCEPT should be removed, you cannot actually do both ACCEPT and DROP. If you keep both, one will overwrite the other depending on the order.

[o-alquimista]

@wangyu- I finished setting it up to run without root on both client and server, but I started seeing a substantial amount of packet loss. Performance is restored to normal if I run it as root. Could you help me figure this out? Should I open a new issue for this?

[wangyu-]

I don't think root or not is the cause of performance difference.

[o-alquimista]

I will test it again soon.

I'm applying the DROP rule automatically through ufw:

/etc/ufw/after.rules

#
# rules.input-after
#
# Rules that should be run after the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-after-input
#   ufw-after-output
#   ufw-after-forward
#

# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-after-input - [0:0]
:ufw-after-output - [0:0]
:ufw-after-forward - [0:0]
# End required lines

# don't log noisy services by default
 -A ufw-after-input -p udp --dport 137 -j ufw-skip-to-policy-input
 -A ufw-after-input -p udp --dport 138 -j ufw-skip-to-policy-input
 -A ufw-after-input -p tcp --dport 139 -j ufw-skip-to-policy-input
 -A ufw-after-input -p tcp --dport 445 -j ufw-skip-to-policy-input
 -A ufw-after-input -p udp --dport 67 -j ufw-skip-to-policy-input
 -A ufw-after-input -p udp --dport 68 -j ufw-skip-to-policy-input

# don't log noisy broadcast
 -A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input

+ # udp2raw
+ -A ufw-after-input -p tcp -m tcp --dport 4096 -j DROP

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

And the process is started by systemd:

[Unit]
Description=Start udp2raw as a server
After=network.target

[Service]
Type=simple
User=_udp2raw
ExecStart=/usr/local/bin/udp2raw_arm_asm_aes -s -l 0.0.0.0:4096 -r [::1]:55820 >

[Install]
WantedBy=multi-user.target

This server is a Raspberry Pi (arm64). The clients are amd64.

It appears to work. Output of iptables -L | grep 4096:

DROP       tcp  --  anywhere             anywhere             tcp dpt:4096

EDIT: I think it's worth trying the binary that doesn't have hardware acceleration. The poor Raspberry Pi 4B doesn't have cryptography extensions.

[o-alquimista]

@wangyu- Now I'm running Wireguard on an OpenWrt router. I need help with something.

The server is installed as /usr/bin/udp2raw. I got it from the released binaries, and created a service to start and manage it. It appears to work, and clients can connect to it -- they get to a "ready" state. But the connection is lost as soon as you try to send wireguard traffic (probably due to missing capabilities?).

OpenWrt doesn't come with setcap installed, so I've found the packages libcap libcap-bin from the repository, and they provide the needed utilities.

But when I run setcap cap_net_raw+ep /usr/bin/udp2raw, it fails:

Failed to set capabilities on file '/usr/bin/udp2raw': Not supported

EDIT: Sorry, I realized I should be asking this on the OpenWrt forums.