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, beebeetles@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!
No comments:
Post a Comment