ndp-proxy-go: Proxy ISP provided /64 Prefix from WAN to LAN

[Maurice]

I did build ndproxy 3.2.1402000_2 and os-ndproxy 1.1 and can't reproduce the behaviour. It just works, without enabling promiscuous mode, joining a multicast group or enabling promiscuous mode for multicast packets (allmulti).

Did you try a ping from OPNsense itself, setting the source address to the LAN interface address (2003:a:1704:XXXX:XXXX:eaff:fe01:3db4)?

Cheers
Maurice

Code Select Expand

hn0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: LAN (lan)
        options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE>
        ether 00:15:5d:d2:76:3c
        inet6 fe80::215:5dff:fed2:763c%hn0 prefixlen 64 scopeid 0x5
        inet6 fd01:2345:6789:abcd::a prefixlen 64
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=121<PERFORMNUD,AUTO_LINKLOCAL,NO_DAD>

hn1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: WAN (wan)
        options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE>
        ether 00:15:5d:d2:76:87
        inet6 fe80::215:5dff:fed2:7687%hn1 prefixlen 64 scopeid 0x6
        inet6 fd01:2345:6789:abcd:215:5dff:fed2:7687 prefixlen 64 autoconf pltime 14400 vltime 86400
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

[Monviech (Cedrik)]

No my tests always included a client in LAN pinging from their GUA or ULA to a destination on the internet.

We did quite some troubleshooting and checked the source code, and we also have an alternative setup now, which also requires promisc mode in our tests.

So there either must be a difference, or tests influence the result (eg using tcpdump will put interfaces in promisc and ndproxy suddenly works).

Just unsure whats the truth.

https://github.com/opnsense/docs/pull/717

Thank you for getting back to me :)

[Maurice]

Just to make sure it's actually a WAN issue (not a LAN issue), I'd try a ping test from OPNsense itself. Source address: LAN interface address, destination address: something on the Internet. This won't work without ndproxy, but doesn't depend on a client in the LAN.

I made sure the interfaces are not in promiscuous mode when testing (no packet capture running).

Are you only testing with physical Intel NICs? So far, I've done all my testing with VMs. Maybe the driver plays a role in this... ND offloading? Just a guess.

[Monviech (Cedrik)]

Yeah so far I only used physical intel nics with physical DEC750 machines, and the client also has a physical NIC.

I could also test in Hyper-V or Proxmox, though lets wait now for other user reports since the scope of the issue is quite unclear.

If promisc is sometimes needed, and sometimes not, thats also fine in the end as now the user controls it without hidden automatism by the port.

Thanks for your feedback, especially that the MAC should be WAN was quite helpful figuring this out.

[Monviech (Cedrik)]

The discussion in here has been superseded.

I have written my own ndp proxy in lang/go which circumvents all of the issues described here.

I use it myself to proxy my /64 to multiple internal interfaces, and @Maurice tested it as well.

It's now generally available in 24.7.8. Have fun with it :)

[Courier1027]

If you receive a DNS server from your ISP, but want the router to be the sole DNS server, use a Port Forward to force traffic destined to port 53 to the local running Unbound server instead.

I am very new to IPv6 and this is my hobby project so please be gentle. I have already implemented this in IPv4 with port forward to 127.0.0.1. How do I identify the IPv6 address of the local running Unbound server and implement for IPv6? My IPv6 stack is working well with this plugin with LAN configured as  link-local so thanks for this.

[meyergru]

That is a bit tricky: AFAIR, you cannot redirect on a link-local address on IPv6 because of some RFC saying that the responses should not be routed, so "::1" is out of the question.

What I do is something like this:

You cannot view this attachment.

The redirect target IP is an alias, which is a dynamic IPv6 alias on any IPv6-enabled interface with the EUI-64 of that interface (which is the same as the EUI-64 of the link-local IPv6).

Also note that I have an exception for one host alias (BLOB_MAC), which is identified by its MAC, because I cannot be sure if that uses IPv6 privacy extensions. I need it because that host is an ACME client that does DNS-01 verification which Unbound cannot forward.