Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - MatheusPP

#1
That would make sense if the original packet destination was indeed the ONU LLA, but it is only been routed using those.

I gave up on the firewall in front of my network for now, will be making a new setup to test this thing with less devices to narrow it down.
#2
Quote from: dseven on November 20, 2024, 09:55:12 PM
fe80 addresses are link-local. They're not supposed to get routed. It's actually interesting that OPNsense appears to be routing it outbound, if I'm reading what you're doing right.........
I understand link-local address should not be routed, but cant they be used as a gateway of other routes?
Clients on the LAN are getting a default route to the link-local address of OPNsense, and it in turn has a default route to the link-local address of my ONU.
If I plug my windows machine directly on the router, I get these routes and IPv6 works as expected using the link-local as gateway:
ff00::/8                                   ::
fe80::[...]/128              ::
fe80::/64                                  ::
2804:[...]/128 ::
2804:[...]/128 ::
2804:[...]::/64                    ::
::/0                                       fe80::1
#3
I have tried many configurations on the ONU and OPNSense side, after some packet capture I believe I narrowed it down to a routing or rule issue on OPNSense.

I let a ping running pointing at the DNS IPv6 that is advertised by the ONU from a client in the LAN and did a packet capture on the WAN port of the OPNSense, attached is an example.

As you can see the ping go out on the WAN port and gets a response from the ONU, but it isnt been routed back to the client that initiated the request, any idea how do I solve this?

The default rules should allow the response to a ipv6-ICMP to return?

Looking at second attachment for the live view on Firewall > Log Files and filtering for ipv6-ICMP seems that the packet isnt routed back to the client after arriving on the OPNSense, but nothing is blocked.

Edit:
fe80::fb5a:b28c:7e41:f197 - LAN client address
fe80::be24:11ff:fefd:8c5c - LAN OPNsense address
fe80::be24:11ff:fe89:ac7c - WAN OPNseinse address
fe80::1 - ONU address
#4
Quote from: stefan00 on November 20, 2024, 06:06:37 PM
Quote from: MatheusPP on November 20, 2024, 05:59:03 PM
I tried to change the "Child Prefix Mask" to ::/63 and ::/60 but I got "Invalid prefix mask" from the ONU, not sure what the mask should be to get a larger different prefix.
Did you also change the ,,request prefix size" on the WAN interface settings in OPNsense?

You should get at least a /57 prefix out of your uplink router. Some documentation available?

I tried both /63 and /60, but after a reload it always gets a /64 prefix.
#5
Quote from: stefan00 on November 20, 2024, 05:38:20 PM
Quote from: dseven on November 20, 2024, 05:17:07 PM
It seems like you have the prefix, but maybe the "ISP ONU" is not routing it to your OPNsense WAN interface....

Sorry overlooked the working traceroute to opnsense ;-)

But is it even possible that the uplink router would delegate a prefix and NOT route it?

Should check what OPNsense->Interfaces->Overview->WAN->Detail popup says at ,,dynamic IPv6 prefix received"

Dynamic router received
192.168.1.1
fe80::1

Dynamic IPv6 prefix received
2804:xxxx:xxx:xxxx::/64


Quote from: dseven on November 20, 2024, 05:39:54 PM
Maybe try changing "Address/Prefix Assignment Mode" to "DHCPv6"? Just guessing - that interface doesn't look familiar....

After changing it on the ONU and doing a Reload on the WAN interface there were some changes:

IP:
Only got the link-local IPv6

Routes:
Additional route: 2804:xxxx:xxx:xxxx::/64

Connectivity:
On this setup of the ONU IPv6 stop working for OPNsense on the Diagnostics test (Interfaces>Diagnostics>Ping)
I suppose because it do not get an WAN IPv6 address on the interface, only a link-local?

Quote from: dseven on November 20, 2024, 05:44:02 PM
Quote from: stefan00 on November 20, 2024, 05:38:20 PM
But is it even possible that the uplink router would delegate a prefix and NOT route it?

OPNsense will do just that if a downstream router gets a prefix only and not an address for its WAN interface - the fix for that is to add a DHCPv6 reservation for it - then a route (to that address) should be created. Not really relevant here, though. Why OPNsense can't route to the link-local address, I'm not sure. A bit of a tangent for this discussion.... but we don't know what the "ISP ONU" does.....

That seems to be the behavior of not routing upwards, soo for it to work on the OPNSense side I should have something like the below on the WAN Interface?
2804:[...]/128
2804:[...]/64
fe80:[...]/64


Quote from: stefan00 on November 20, 2024, 05:50:56 PM
You get a /56 prefix from your ISP - perfect.

Try DCHPv6 for delegation as dseven said and also try to get a bigger network delegated into OPNsense, maybe /62 or even bigger.

I remember having an issue long time ago when a /64 was not enough, even with request prefix only checked.

@dseven on routing: I meant the uplink router, not the OPNsense box. If the uplink router delegates the network downwards, it MUST route it.

I tried to change the "Child Prefix Mask" to ::/63 and ::/60 but I got "Invalid prefix mask" from the ONU, not sure what the mask should be to get a larger different prefix.
#6
Quote from: stefan00 on November 20, 2024, 05:22:21 PM
Without a bit more information itˋs just guessing, but first things to look at:

1) is IPv4 working correctly? (Ping, WAN access)

2) at first look, your IPv6 stack looks good - your LAN client gets an IPv6 via RA from OPNsense

3) Do you have at least 1 Firewall rule defined on the LAN interface? (No rule = block everything)
1 - Yes, IPv4 is working from inside the LAN, using it right now.
3 - I have the default rules and auto generated rules:
[LAN]
Automatically generated rules (25)
Default allow LAN to any rule
Default allow LAN IPv6 to any rule

[WAN]
Automatically generated rules (20)

I want to expose some services over IPv6 later, but for that I need IPv6 to be reaching out as expected.
#7
Yes, by router I mean the ISP ONU, sorry for the confusion.
I have control over the ONU, but its interface is somewhat limited.

On the Routes column in the WAN Interface of OPNSense I got these routes:
default
177.XXX.XXX.XXX
177.XXX.XXY.XXX
192.168.1.0/24
default
2804:XXXX:X::X
2804:XXXX:XX::X
fe80::%vtnet1/64

I attached the configuration options I have for IPv6 and the WAN info on the ONU.

#8
Hello people, I am new to OPNsense and I am trying to setup a firewall in my homelab for use on my network and having a hard time getting IPv6 to the Internet working from the LAN side.
The LAN side seems to get IPv6 and routes but packets don't go anywhere after the firewall.

I attached the network layout, the Interfaces Overview, a ping test from the firewall itself  that works as expected.

Attached is also some tests from inside the LAN, where you can see the guest gets IPv6, routes but can ping and a traceroute ends up on the firewall.

When I filter the logs on Firewall, Log Files, Live View for the src IP for a ping test it passes on these default rules:
lan > IPv6 RFC4890 requirements (ICMP)
wan < let out anything from firewall host itself

I am at a loss on what to do, IPv6 connectivity worked before I implemented OPNsense by connecting the router to the physical switch in the topology.

I researched quite a lot but could not get it to work as expected, here is my current configuration:

Interface LAN settings:
Block private networks: unchecked
Block bogon networks: unchecked
MTU: 1472 (same as router says, tried with/without)
IPv4 Configuration Type: Static IPv4
IPv6 Configuration Type: Track Interface
Parent Interface WAN

Interface WAN settings:
Block private networks: unchecked
Block bogon networks: unchecked
IPv4 Configuration Type: DHCP
IPv6 Configuration Type: DHCPv6
MTU: 1472 (same as router says, tried with/without)

DHCPv6 client configuration:
Prefix delegation size: 64
Request prefix only: checked
Send prefix hint: checked