[SOLVED] OpenBSD PF rdr-to across rdomains

How can I redirect an incoming connection on one rdomain to an IPv4 address existing on a different rdomain?

The following is incorrect but illustrates what I am trying to do on the router:

pass in quick on $ext proto tcp from any to any port 3000 \
        rdr-to 192.168.1.100 port 3000 rtable 11

When I try to connect from the outside to port 3000 on the router it gives a "Connection refused" error rather than forwarding it to the inner machine.

However, I can connect from inside the router to port 3000 at 192.168.1.100 on rdomain 11 using the router route utility. I would like to do that in one step though by connecting to port 3000 on the outside and have it passed through to another machine on the inside.

This is for OpenBSD 6.5-current

Originally Posted by Turbocapitalist How can I redirect an incoming connection on one rdomain to an IPv4 address existing on a different rdomain?

A pair of pair(4) NICs are "patched" together to interconnect rdomains.

I can connect from inside the router to port 3000 at 192.168.1.100 on rdomain 11 using the router utility.

Do you mean route(8)? There is no "router" in OpenBSD, nor can I find any /usr/local/{bin,sbin}/router in any packages.

Yes, I meant the route(8) utility. I've corrected that typo above now.

As a best case, I was hoping that rdr-to alone would suffice. I figure there must be a good way to do this redirection entirely within PF.

The rule syntax includes the optional directive "...on rdomain number" but this is a match restriction just like the directives "in" and "out" or "on interface".

---

You're asking this esoteric OpenBSD question on a Linux-centric forum. For actual answers from either developers or users-with-a-clue, I recommend the Project's misc@ mailing list. As an example, Peter Hansteen wrote this paper on rdomain use, which you may have already seen. Peter is active on misc@, and is as likely to answer this question as any other expert, if you ask it there.

Thanks, I figured I'd try here on the *BSD subforum about BSD usage. PF is in several of the BSDs and this is a usage question not a miscellaneous development task. On the off chance that someone has the answer, that's great. Otherwise, I've at least talked myself through defining the problem.

Anyway, I've tried the following, but even that gives a connection refused error from the outside:

pass in quick on rdomain 10 inet proto tcp from any to ($ext_if) \
        port 3000 rdr-to 192.168.1.100 port 3000 rtable 11

10 is the rdomain of egress and 11 is the rdomain of the other interface.

FreeBSD has a fork of PF, circa 2009. Syntax and usage differs, and in particular, redirects function differently.

OpenBSD has a very small community of users here at this forum. I can count the number of rdomain(4) OpenBSD users here with one finger.

Originally Posted by Turbocapitalist Anyway, I've tried the following, but even that gives a connection refused error from the outside: pass in quick on rdomain 10 inet proto tcp from any to ($ext_if) \ port 3000 rdr-to 192.168.1.100 port 3000 rtable 11

Your syntax looks wrong to me. Try it without the parenthesis around $ext_if.

Here is the OpenBSD pf page. It doesn't show interface macros used in rules as being enclosed:

https://www.openbsd.org/faq/pf/filter.html

I have OpenBSD and FreeBSD boxen and use the same pf ruleset on both with only a slight change to the egress rule for OpenBSD. I don't enclose $ext_if on either.

I'm assuming you've made an interface macro for $ext_if.

Yep. A macro exists for $ext_if. I thought that having it in parenthesis means that PF handles dynamic addresses.

Anyway, here is what works from the outside when connecting from another network:

pass in on $ext_if proto tcp from any to ($ext_if) port 3000

match in on rdomain 10 proto tcp from any to ($ext_if) port 3000 \
        rdr-to 192.168.1.100 port 3000 rtable 11

So that part of the problem is solved. Now I just have to uncomplicate the rest of it so that I may do NAT hairpinning (or whatever the right name is) so that I can continue along from behind the router.

Thanks, both jggimi and trihexagonal, as well as any who also considered the problem.