After troubleshooting this a bit more, it appears that adding a default route to rdomain0 is sufficient to make it work. Even if that default route leads to nowhere, the kernel seems to need it to be able to move the return traffic back from rdomain0 to rdomain2.
Without a default route, we can see some icmp unreachable packets: 1557916273.174002 ac:1f:6b:2d:bb:ca 52:54:00:d1:c6:a1 0800 70: 172.30.128.83 > 172.30.128.84: icmp: host 123.123.123.123 unreachable Just adding a default route with a valid IP on rdomain0 solves the problem. It looks like a bug in my opinion, or is it the expected behavior? Thanks, Ben ________________________________ From: owner-m...@openbsd.org <owner-m...@openbsd.org> on behalf of Benjamin Girard <benjamin.gir...@kambi.com> Sent: 14 May 2019 19:46 To: Josh Grosse; misc@openbsd.org Subject: Re: Pf rdr-to and rdomain issue So we did manage to make it work by adding a pair in each rdomain and a default route from rdomain 0 using the pair on rdomain 2 as a gateway but it doesn't the seem correct. Is there any better proper way to make the traffic flowing back from one rdomain to another when using an rdr-to rule in pf? ________________________________ From: owner-m...@openbsd.org <owner-m...@openbsd.org> on behalf of Benjamin Girard <benjamin.gir...@kambi.com> Sent: 14 May 2019 18:02 To: Josh Grosse; misc@openbsd.org Subject: Re: Pf rdr-to and rdomain issue Can't we just use pf to move the traffic, rather than using pair? ________________________________ From: Josh Grosse <j...@jggimi.net> Sent: 14 May 2019 17:42 To: Benjamin Girard Subject: Re: Pf rdr-to and rdomain issue I think pair(4) may come to your rescue.
