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.

[Maurice]

My general recommendation for setups which are a little more advanced is to bind services like DNS to loopback interfaces:

- Interfaces: Devices: Loopback, create a loopback interface, name it e.g. "Unbound".
- Assign the interface and configure it with static IP addresses (/128 ULA and /32 RFC1918 is fine).
- Services: Unbound DNS: General, set "Network Interfaces" to this loopback interface (only).
- In the DHCP / RA configuration, set the DNS server addresses to the loopback interface's addresses.
- Optional: If you want to force all DNS traffic to Unbound, forward port 53 to the loopback interface's addresses.

Cheers
Maurice

[Monviech (Cedrik)]

TWIMC: https://github.com/Monviech/ndp-proxy-go/issues/3

I got the proxy working now for PPPoE interfaces as well.

[Monviech (Cedrik)]

Also I just tried the port forward and it works for me without any tricks:

it might not be RFC conform but "hey it works I guess xD"

EDIT: DOESNT WORK!

[meyergru]

Really? I just tried and it did not work for me like that.

I used ::1 as redirect target and used: "nslookup -query=A www.google.de 2001:4860:4860::8888" and got a communications error from a Linux client. The same thing works when I use a routeable IPv6 alias for OpnSense as a redirect target. Note that by using Google's DNS IPv6 explicitely, I force the IPv6 forwarding rule to be applied.

I recently had a dicussion with Patrick over this where he was surprised as well that it did not work.

His posting is here and OpnSense seems to adhere to RFC4291: https://forum.opnsense.org/index.php?msg=246585

Maybe you got an answer over a redundant DNS over IPv4?

[Patrick M. Hausen]

Correct - to pull that link to the FreeBSD source from that other thread so you don't need to go on a scavenger hunt:

https://cgit.freebsd.org/src/tree/sys/netinet6/ip6_input.c?h=releng/14.3#n765

FreeBSD *should* categorically refuse to send a packet with source ::1 to anything but the loopback interface itself if I read that code correctly.

[Monviech (Cedrik)]

Yeah it seems like my assumption was wrong it fell back after not getting an answer:

Vlan:

21:15:23.740664 IP6 2003:a:177f:8463:b40e:4343:1cc8:df32.54262 > 2003:180:2:7000::53.53: 54276+ AAAA? ipv6.google.com. (33)
21:15:25.741343 IP 172.16.1.150.52057 > 172.16.1.1.53: 54276+ AAAA? ipv6.google.com. (33)
21:15:25.751291 IP 172.16.1.1.53 > 172.16.1.150.52057: 54276 2/0/0 CNAME ipv6.l.google.com., AAAA 2a00:1450:4016:800::200e (92)


Loopback doesnt respond:

21:15:23.740672 IP6 2003:a:177f:8463:b40e:4343:1cc8:df32.54262 > ::1.53: 54276+ AAAA? ipv6.google.com. (33)


Good to know, sorry xD