Prefix delegation to second router.



  • I have two APU's one I use for testing and one that is live, both running 2.4. I am having a problem getting the following to work:-

    ISP ( DHCP6 WAN Link Local ) <-> First Router( Allocated /56 Prefix) <-> Second Router (Allocated /64 Prefix)

    Now, clients connected to the First Router work perfectly, no issues at all.

    Clients connected to the second router get an address in the prefix range allocated all good.

    If I get a client to ping say google on 2001:4860:4860::8888, then there is no response, looking at the traffic on Router 1, I can see the ping going out of the WAN, and the reply, but it does not get routed back to the second router.

    Do I manually need to add a gateway and route for the second router on the first router or should this be happening automagically?


  • Netgate

    You should be doing something like routing a /60 out of the /56 to the secondary router for use on local interfaces there.

    This is why the original recommendation for a minimum allocation to an end user was /48 (RFC 3177, unfortunately obsoleted by RFC 6177. And even with 6177 ISPs are woefully clueless).



  • @Derelict:

    You should be doing something like routing a /60 out of the /56 to the secondary router for use on local interfaces there.

    This is why the original recommendation for a minimum allocation to an end user was /48 (RFC 3177, unfortunately obsoleted by RFC 6177. And even with 6177 ISPs are woefully clueless).

    Thanks Derelict, so changing the 64 to 60 it should then work?


  • Netgate

    Not necessarily.

    This is how I delegate /56 prefixes downstream in the lab stack:

    ![Browser Shot-2017-01-13-02-37-13.png](/public/imported_attachments/1/Browser Shot-2017-01-13-02-37-13.png)
    ![Browser Shot-2017-01-13-02-37-13.png_thumb](/public/imported_attachments/1/Browser Shot-2017-01-13-02-37-13.png_thumb)



  • I have the prefixes delegating fine.. I think.

    Here's what I am getting. On the Primary Router LAN address is 2a02:xxxx:xx0:4c00:20d:b9ff:fe3e:d7cd
    Windows 10 client, yes I know W10 is an awkward git                2a02:xxxx:xx0:4c00:5152:1e20:e6e2:81b6

    Test Router WAN interface is                                                    2a02:xxxx:xx0:4c00:20d:b9ff:fe44:7270 
    Test Router LAN interface is                                                      2a02:xxxx:xx0:4c02:20d:b9ff:fe44:7271

    Windows 10 client on that LAN                                                  2a02:xxxx:xx0:4c02:7:3415:fd94:2f33

    I can manually add a gateway and route to the primary router, then it works, is that the norm or am I completely wide of the mark?

    edit:

    Think I am getting my head around this. dhcp6c puts a /64 prefix on the LAN, which means that in my case, with a /56 prefix the last eight bits of the prefix on my LAN are always going to be 0. Any /64 prefix delegation on my LAN will be be using those eight bits, thus giving my my 256 sub nets.

    The question therefore is this, should dhcpd ( or pfSense ) be adding a gateway and route to the LAN side of the primary server to route any traffic not destined for the '0' subnet to the delegated subnet? With a static WAN allocation this would not be much of an issue, but with a DHCP PD it will be. Ah, just found this after a quick search, seems someone else has fallen foul of this:

    http://serverfault.com/questions/527336/prefix-delegation-and-route-creation

    and that leads me onto quagga - Something else to get my head around!


  • Netgate

    Three ways to assign IPv6 to a host:

    Static
    SLAAC
    DHCPv6

    Two ways to assign IPv6 to a router:
    Static
    DHCPv6 with a prefix delegation.

    What happens on the second router's LAN and what it does with the PD is up to that router.

    SLAAC and DHCPv6 do not set "default gateways" like in IPv4. They are set using router solicitations/advertisements unless statically.configured.



  • Yes, i've found that out.  :)

    As i said, the ping goes all the way out to the wan as router 2 knows where to forward the packets to. On the reply,  router 1 receives  the packet but does not know to forward it to the 2nd router.

    For now I've added a static route and gateway and it's working. Its not a configuration I intend to use often, but I'm playing with dibbler and needed it configured that way for testing.


  • Netgate

    A proper PD from the first router should also create a route for that PD to the downstream router's WAN interface.

    My DHCP6 server is 2.3.2_1, however. Should be 2.4 real soon now. In fact. This is as good a time as any.



  • @Derelict:

    A proper PD from the first router should also create a route for that PD to the downstream router's WAN interface.

    My DHCP6 server is 2.3.2_1, however. Should be 2.4 real soon now. In fact. This is as good a time as any.

    Running 2.4 on both routers, not there yet or if it is, mine doesnt work!


  • Netgate

    Haven't gotten there yet but also have not heard oany problems there so it's probably something you've done.



  • @marjohn did you get to the bottom of this ?



  • Nix…



  • It should be noted that if router 1 gets its IPv6 prefix from your ISP via DHCPv6-PD, pfSense is not set up to subdelegate parts of that prefix to downstream routers (unless this has changed in 2.4; it doesn't work in 2.3.2).

    For example… if you get a /56 or /60 from your ISP via DHCPv6-PD, you can't sub-delegate /64's to downstream routers on your network.


  • Netgate

    I don't see why you couldn't slice out a piece of the delegated prefix for dhcpv6 downstream PD.

    You would need at least one interface outside that set as track interface or the PD will not happen.

    You would also have to manually change the DHCPv6 PD config if the ISP gave you a different PD.

    Haven't tested though. All my DHCPv6 server PDs are from a static /48 here. (HE)



  • @Derelict:

    I don't see why you couldn't slice out a piece of the delegated prefix for dhcpv6 downstream PD.

    You would need at least one interface outside that set as track interface or the PD will not happen.

    You would also have to manually change the DHCPv6 PD config if the ISP gave you a different PD.

    Haven't tested though. All my DHCPv6 server PDs are from a static /48 here. (HE)

    And indeed you can, but you'll need to manually set that route and gateway up. I've been through 2.4's code and I cannot see anywhere where DHCPD or any hooks from dhcpd will set up that route and gateway for you.

    As I said, not a major issue or me anyway, and I know for a fact that the ISP's supplied routers are not capable of anything like that at present. Maybe down the road it will happen.


  • Netgate

    Not a problem in 2.4.

    Just routed a /56 to a 2.4 VM and set up /60 PDs behind it. Client is also 2.4.

    Routing table:
    2001:470:xxxx:7df0::/60 2001:470:xxxx:7e01::32a2 UGS 0 1500 xn0

    DHCPv6 leases:
    2001:470:xxxx:7df0::/60
    Routed To: 2001:470:xxxx:7e01::32a2



  • I take it back :)

    The question is then, what I am I doing wrong that you are doing right, or maybe it just won't work were LAN IPv6 tracks the WAN interface.


  • Netgate

    The client VM there is a default config with DHCPv6 on WAN and tracking LAN.



  • So what does your prefix delegation range entry look like on the dhcp6 server and RA when you have selected /60 as the prefix delegation size?


  • Netgate

    Routed subnet: 2001:470:xxxx:7d00::/56

    Prefix delegation range:
    From: 2001:470:xxxx:7d00:: To: 2001:470:xxxx:7df0::
    Prefix delegation size: 60



  • Ah, I think I see the error of my ways.

    I'll confirm that shortly.



  • Indeed yes… Thank you Derelict. Simple error on my part.



  • Care to share your settings in the GUI ?



  • What for IPv6? or are you still trying to get v4 to work arse backwards? :P



  • IPv6

    I realised after your tutoring that my IPv4 looback idea would just stupid :-)



  • Not too difficult though. You could  forward  port 80 on the Wan of the  second router to the lan address of the 2nd router, you'll need to create the relevent rules.

    Why you would want to do it is what i am unsure about.

    I can think of a more secure way of doing it though. Port forward 'x' port on the primary to 'x' port on the secondary and have openvpn listen on that 'x' port on the secondary, then you'll have a vpn to the secondary LAN side and can do whatever you like.



  • @marjohh:

    I can manually add a gateway and route to the primary router, then it works, is that the norm or am I completely wide of the mark?

    edit:

    Think I am getting my head around this. dhcp6c puts a /64 prefix on the LAN, which means that in my case, with a /56 prefix the last eight bits of the prefix on my LAN are always going to be 0. Any /64 prefix delegation on my LAN will be be using those eight bits, thus giving my my 256 sub nets.

    I have exact the same problem. Data going through WAN into internet and answers are received on WAN and not forwarding to LAN. Can you explain the gateway and route you have added in detail, please?


  • Netgate

    OK. The first image here is from my edge. That firewall has the HE.NET tunnel configured.

    One of the interfaces on it is XENWAN which goes to the virtual infrastructure. That network is the WAN interface for the test boxes (172.25.228.0/24 in the diagram in the sig.)

    There is also dual stack STATICALLY CONFIGURED to a downstream router (::11). That is the CARP VIP of an HA cluster.

    To that router I route two /56 prefixes. One is 2001:470:XXXX:7d00::/56 the other is 2001:470:XXXX:7e00::/56 .

    I use 2001:470:XXXX:7d00::/56 to break into /64s to STATICALLY assign to the inside interfaces on the downstream test router. On LAN I also defined a range for the DHCPv6 server there.  In that DHCP server I also used 2001:470:XXXX:7e00::/56 for /60 prefix delegations. Second image.

    DHCPv6 clients that connect to that LAN get an address from the DHCPv6 server and a /60 automatically routed to them if they request one.

    Note that all of the interfaces need to pass all of the necessary routed subnets, etc.

    ![Screen Shot 2018-01-31 at 11.06.26 AM.png](/public/imported_attachments/1/Screen Shot 2018-01-31 at 11.06.26 AM.png)
    ![Screen Shot 2018-01-31 at 11.06.26 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2018-01-31 at 11.06.26 AM.png_thumb)
    ![Screen Shot 2018-01-31 at 11.01.24 AM.png](/public/imported_attachments/1/Screen Shot 2018-01-31 at 11.01.24 AM.png)
    ![Screen Shot 2018-01-31 at 11.01.24 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2018-01-31 at 11.01.24 AM.png_thumb)



  • Thanks for answer. The solution seems to be switch from TRACKED LAN by WAN and RA (which I using, because IPv6 changing on reconnect even IPv4 changed) to STATICALLY LAN and DHCPV6-Server?

    Additionally I have to use a cable modem to connect to ISP, which is a Fritzbox 6490 Cable. That has its own limitation and can only delegate a 62 network. Other requests failed. Getting prefix through IPv4 does not work, too.

    May be there is no solution using IPv6 subnets on this configuration?

    ISP: Got rotating IPv4 and IPv6/56 after some reconnects

    Connection: FritzBox 6490 Cable

    pfSense WAN: Static IPv4 / DHCP6 / Request only an IPv6 prefix / DHCPv6 Prefix Delegation size: 62 (no other works) / Send IPv6 prefix hint / Reserved Networks: Both checkboxes off

    pfSense LAN: Static IPv4 / Track Interface (IPv6) / IPv6 Interface: WAN / IPv6 Interface ID: 0 (1,2,3)

    DHCPv6 Server & RA - LANRouter Advertisements: Unmanaged or Assisted or Stateless working, but wit same results

    All other reseted to default!

    LAN-Client -> pfSense LAN -> pfSense WAN -> Fritzbox -> Network request: OK
    Network replay -> Fritzbox -> pfSense WAN … ends here and nothing revives on pfSense LAN!

    2.4.2-RELEASE-p1 and it the same problem 'marjohh' has described on page 1! He seems to be a solution in this scenario by adding a route manually.


  • Netgate

    Why the hell would you need to delegate prefixes to the inside if all you have is dynamic in the first place?



  • pfSense cannot handle it? Ok …


  • Netgate

    Good luck.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy