pfSense as subrouter, track interface and routing problems
-
Sure you can. That's what I have here. You should be using SLAAC, unless you have some need for DHCP6. Also, Android devices won't work with it, thanks to some genius at Google.
Here's the configuration for my ISP.
You then configure the Router Advertisements page.
-
@JKnott In the linked post, you say you're using "track interface", not SLAAC for LAN.
When I want to change to SLAAC, here's the message I get:
-
Do you still have DHCPv6 enabled? Try with it off.
-
@JKnott No DHCPv6 as always been disable on LAN, I only use RA.
-
What happens if you connect pfSense directly to your ISP, instead of your other router? Also, sometimes it's easier to start from scratch than trying to find the problem.
-
@Spaylia said in pfSense as subrouter, track interface and routing problems:
When I want to change to SLAAC, here's the message I get:
Did you configure a static address on your LAN? You don't have to with SLAAC.
-
@JKnott said in pfSense as subrouter, track interface and routing problems:
Did you configure a static address on your LAN? You don't have to with SLAAC.
I can do that, but it still doesn't route from LAN to WAN :(
-
@JKnott I managed to make it work temporarily, I could ping internet from the LAN interface, but my clients still couldn't. Oddly enough there was no addresses on the LAN interface.
When I rebooted, LAN address came back and ping wasn't working anymore. I tried both "track interface" and static IP.
-
Maybe you should start over from scratch. You might have made so many changes starting over may be easier. Start with the config I provided for my ISP.
-
@JKnott do I need to add a route or gateway in the first router?
With IPv4, the router keeps a table of the translated address and port and sends the response back where it comes from, to be translated by the second router.
I'm not sure about IPv6. Does the router know where it comes from if it comes from another subnet (behind router 2)?
-
With IPv6, the default route is set automagically. With SLAAC, it's provided by the router advertisements. You can see this, if you capture with Packet Capture, filtering on icmp6.
-
@JKnott I'm not asking about the default route, but a downstream route for Router 1, to send the responses to Router 2
When a client requests something, it goes:
Client -> router 2 -> router 1 -> internetWhen the server answers
internet -> router 1 -> router 2 -> clientDo I need a route from router 1 to router 2 so the answer can be router back?
-
It will know the route to the next router, but not the network behind it. So, you'll have to configure the route for that network.
-
@JKnott Alright, I got it to work, it was a problem with the configuration of R1, after looking at the routes in R1, I noticed it wasn't delegating the prefix properly.
Although devices (mostly debian hosts) under R1 are still advertised with R2 (pfsense) WAN as a default route. Would you know if there's a way to see who advertised a route on debian?
-
Do a Packet Capture, filtering on icmp6. You will, after a few minutes, have some router advertisements, which provide the route. Examine the source MAC address to see where it's coming from.
-
@JKnott Makes sense, thank you!
-
@JKnott well, it comes from pfSense WAN somehow
2023-12-02 23:35:52.560376 xx:xx:xx:xx:xx:5d (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype IPv6 (0x86dd), length 198: fe80::xxxx:xxff:fexx:xx5d > ip6-allnodes: ICMP6, router advertisement, length 1445d is the MAC address/link local address of the WAN interface
-
That's not right. It can only be the LAN interface.
-
@JKnott Since I can't add a deny rule for router advertisement on WAN (I guess hidden rules come before to allow it), I added an ip6tables rule to
deny icmpv6 type 134 (RA) from fe80::xxxx:xxff:fexx:xx5dto all clients in the WAN of pfsense, and I don't get the route anymore. -
Well, I don't know what to say. It's a really strange system you have there. The MAC address comes from the NIC, not pfSense. So, if you're seeing the MAC, that is the 48 bit hardware address, on the LAN side, there must be some other path involved. This is why I asked you to provide the Packet Capture file, so that I can examine it in Wireshark.
