pfSense as subrouter, track interface and routing problems
-
@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.
