After some digging, what it _appears_ to me that when "af-to" is used
together with "rtable" like the following:
pass in log on re0 inet6 proto {tcp, udp} \
from (re0:network) to 64:ff9b::/96 \
rtable 1 af-to inet from 127.0.0.1
the origin rtable information is not kept in the pf state, and thus the
return packet will be routed using the default rtable (which will fail).
Is my observation correct? And if yes, is this a bug or is it by design?
Thanks!
On 1/18/23 01:41, beebeet...@posteo.de wrote:
Hi misc,
I've been trying to do NAT64 across different rdomains, but haven't had
any success so far. My test setup is as follows:
+-----------------------+
| client |
| . . . . . . . . . . . |
| fd00::2/112 |
+-----------+-----------+
|
Ethernet |
|
+-----------+-----------+
| OpenBSD router |
| . . . . . . . . . . . |
| rdomain 0 |
| re0: fd00::1/112 |
| lo0: ::1/128 |
| . . . . . . . . . . . |
| rdomain 1 |
| lo1: 127.0.0.1/8 |
+-----------------------+
There is a "service" running on the OpenBSD router in rdomain 1,
listening to 127.0.0.1 port 1234:
nc -V 1 -vl 127.0.0.1 1234
The client tries to connect the service via:
nc -zv 64:ff9b::7f00:1 1234
pf.conf only contains the following one line:
pass in log on re0 inet6 proto {tcp, udp} \
from (re0:network) to 64:ff9b::/96 \
rtable 1 af-to inet from 127.0.0.1
packet forwarding is enabled :
net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
In my imagination, the client should be able to reach the service and
get a response, with the NAT64ed packet translated to a packet of
127.0.0.1 -> 127.0.0.1. However, although the incoming packet shows up
on pflog0 (so it does match the pf rule), it is not detected on the side
of the listening nc.
Any insights into why this setup does not work, or is "rtable"
incompatible with "af-to"?
Thanks!
