IPv6 not working when pfsense is behind ISPs Router



  • Hi,

    i am forced to use pfsense as secondary router because the first one is doing VoIP with DECT phones.
    (the more i read in getting VoIP to work when its behind another firewall/router the less i think im gonna be able to get it to work,
    (ports, QoS, ipv6 etc.) hence the router –> pfsense constellation now)

    so far this WAN --> ISPs router --> pfsense constellation works flawlessly, only with a little extra work for port forwarding with ipv4/NAT

    what i can't get to work is ipv6. the first router gets a /56 prefix from the ISP (dual stack) and says it is using /64 for LAN.

    i set pfsense WAN interface to "DHCP6", "Prefix Delegation" to request 64, "prefix hint" enabled and the WAN interface gets an adress (2003:XXX, subnet mask ipv6 is 64 and gateway it says fe80::1)
    i set pfsense LAN interface to "Track interface" WAN but it never gets any ipv6 ip nor get the clients.

    when i connect a client directly to ISPs router it automatically does ipv6 and gets an IPv6 address

    i also tried different settings in WAN interface like "ipv4 parent interface", "request only prefix" etc., nothing changed

    do i need to set anything else to have ipv6 ips for the clients? is it possible that my first router doesn't hand out prefixes? if this is the case, can i somehow do ipv6 NAT with the ipv6 WAN address? or is there a way to let something else handle voip (secondary server or smth) that can also do DECT and a howto to get it working?

    appreciate the help!

    regards



  • Your first router would have to support delegating part of the prefix that the ISP delegated to it on to your pfSense box; i.e., it would have to support the server side of DHCP-PD in addition to (and linked to) the client part. I doubt your average home router does.



  • @razzfazz:

    Your first router would have to support delegating part of the prefix that the ISP delegated to it on to your pfSense box; i.e., it would have to support the server side of DHCP-PD in addition to (and linked to) the client part. I doubt your average home router does.

    do you know of any consumer router that can do it? (i think AVM FritzBox can do that, if i read it correctly)



  • Sorry, I don't. FWIW, pfSense doesn't support re-delegating part of a delegated prefix either, from what I can tell.



  • is it possible that i just set up an dhcp6 server on pfsense and hand out the addresses of the /64 subnet myself? will that get routed? and send to ISP-router?



  • @SigHunter:

    is it possible that i just set up an dhcp6 server on pfsense and hand out the addresses of the /64 subnet myself? will that get routed? and send to ISP-router?

    With pfSense as with m0n0wall the concept is that the LAN side gets another subnetnumber. So suppose you get 2003:babe:face:1::/64 on the 1st router, then the 2nd requires some number say 2003:babe:face:fc::/64.
    An AVM Fritzbox 7360 as a 1st will cooperate in such scenario (provided you use have bits /56 to /64).
    Only then you can have your DHCPd or track-interface.

    Another solution is to use/setup a DMZ which uses the subnet of the 1st router.



  • @SigHunter:

    Hi,

    i am forced to use pfsense as secondary router because the first one is doing VoIP with DECT phones.
    (the more i read in getting VoIP to work when its behind another firewall/router the less i think im gonna be able to get it to work,
    (ports, QoS, ipv6 etc.) hence the router –> pfsense constellation now)

    so far this WAN --> ISPs router --> pfsense constellation works flawlessly, only with a little extra work for port forwarding with ipv4/NAT

    what i can't get to work is ipv6. the first router gets a /56 prefix from the ISP (dual stack) and says it is using /64 for LAN.

    i set pfsense WAN interface to "DHCP6", "Prefix Delegation" to request 64, "prefix hint" enabled and the WAN interface gets an adress (2003:XXX, subnet mask ipv6 is 64 and gateway it says fe80::1)
    i set pfsense LAN interface to "Track interface" WAN but it never gets any ipv6 ip nor get the clients.

    when i connect a client directly to ISPs router it automatically does ipv6 and gets an IPv6 address

    i also tried different settings in WAN interface like "ipv4 parent interface", "request only prefix" etc., nothing changed

    do i need to set anything else to have ipv6 ips for the clients? is it possible that my first router doesn't hand out prefixes? if this is the case, can i somehow do ipv6 NAT with the ipv6 WAN address? or is there a way to let something else handle voip (secondary server or smth) that can also do DECT and a howto to get it working?

    appreciate the help!

    regards

    Let's clear up some facts first: auto IPv6 addresses do not work on anything less than a /64. DHCPv6 has nothing to do with IPv6 autoconfiguration. Since pfsense is getting a /64 from the ISP's router, it cannot break that into smaller subnets and hand out addresses on its (pfsense) LAN side interfaces. That's why it's not working. Some OSs don't like DHCPv6, since technically it's not valid, and prefer to use their autoconfiguration part. Nothing to do with prefixes, delegation, or anything else.

    What you need to do is A)get your ISP to give you a bigger subnet (if you are connecting multiple networks (interfaces) using that subnet, it must be a /48 (so that per interface /64s are assigned, which leads to IPv6 auto configuration working), OR B) you break up the /64 into smaller subnets and use pfsense's DHCPv6 to hand out addresses from those subnets. Depending on what your clients are, it might, or might not work. OR C)forget about autoconfiguration and use static addresses in your clients.

    Anything less that a /64 on pfsense's internal interfaces will break things one way or another.

    It's either choice A, B or C.

    WRT the people steaming "WHAT?DHCPv6 has nothing to do with autoconfiguration?What is this guy smoking?" DHCPv6 and OS level IPv6 autoconfiguration are NOT the same. You CAN get an automatically assigned IPv6 address on an interface that has NO DHCPv6 listening, and that's a fact, from hereby on quoted as being exactly that. DHCPv6 is simply a non-standard way of assigning "auto" IPv6 addresses. Can steer the client into a different subnet, for example, something the OP should look into (since all you get is a /64 that needs to be broken into smaller subnets).



  • @jflsakfja:

    DHCPv6 is simply a non-standard way of assigning "auto" IPv6 addresses. Can steer the client into a different subnet, for example, something the OP should look into.

    As I understand the OP, (on the 2nd router behind 1st) is trying to get another subnet from the ISP assigned bit range /56 tru /64.

    Well, that works with requesting & cooperation from 1st router. OP cannot assign a number by his choice. WAN DHCP6(-PD) is needed. 1st router must know about the 2nd router in series. With then Track-Interface with a /64 prefix and SLAAC his LAN can function. I have such a setup and working OK.



  • @hda:

    As I understand the OP, (on the 2nd router behind 1st) is trying to get another subnet from the ISP assigned bit range /56 tru /64.

    Well, that works with requesting & cooperation from 1st router. OP cannot assign a number by his choice. WAN DHCP6(-PD) is needed. 1st router must know about the 2nd router in series. With then Track-Interface with a /64 prefix and SLAAC his LAN can function. I have such a setup and working OK.

    1st router has nothing to do with interfaces behind the second router, since it doesn't even know about them. All it knows is that if a packet wants to go to X, it has to pass through Y (2nd router).

    The second quoted paragraph is pretty much what I've said. SLAAC ("auto" IPv6) needs a /64. Either get a /64 routed over another smaller subnet to the 2nd router, or use DHCPv6 and manually break up the existing subnet. It's going to get messy, but it will work.



  • @jflsakfja:

    1st router has nothing to do with interfaces behind the second router, since it doesn't even know about them. All it knows is that if a packet wants to go to X, it has to pass through Y (2nd router).

    Sure of course, no issue. And related to what exactly are you stating this ? I can't follow to the OP's related problem.
    (N.B. meant is 1st router on ISP, 2nd on 1st router right ?)

    You have to request with 2nd router other subnet (your IP range bit 48 tru 64) with 1st router, using WAN DHCP6(-PD) and "IPv6 Prefix ID" (0). This requires 1st router cooperation in delegation…



  • @hda:

    Sure of course, no issue. And related to what exactly are you stating this ? I can't follow to the OP's related problem.
    (N.B. meant is 1st router on ISP, 2nd on 1st router right ?)

    You have to request with 2nd router other subnet (your IP range bit 48 tru 64) with 1st router, using WAN DHCP6(-PD) and "IPv6 Prefix ID" (0). This requires 1st router cooperation in delegation…

    To be quite honest, I didn't understand anything from that…

    But I'll have a go anyway.

    1st router was refering to the ISP router, 2nd router to pfsense.

    From the 2nd router, you don't have to "request" anything from the upstream (1st) router. The 1st router just hands over a subnet, with associated routing taken care of, if the router > router "network" is to be considered static. And it should. A router should never change its address within the "internal" network, since it has no reason whatsoever for doing that.

    Don't confuse what the ISP is doing (handing out dynamic addresses) to router>router connections you control. The ISP is doing it for pure convenience, they don't have to go around changing thousands and thousands of IPs. In this particular scenario (thread) only 2 routers exist, and they MUST be static. The less things that exist, the less things that can break.



  • @jflsakfja:

    To be quite honest, I didn't understand anything from that…
    But I'll have a go anyway.

    Why teaching away without asking what you don't understand precisely? Are you talking the theory without the specific setup experience ? Then try for yourself. I am curious to know if you can get the inner LAN (/64) with the same subnet value (position bits 48 (or 56) tru 64) compared to the subnet value of the 1st router's LAN…



  • @hda:

    Why teaching away without asking what you don't understand precisely? Are you talking the theory without the specific setup experience ? Then try for yourself. I am curious to know if you can get the inner LAN (/64) with the same subnet value (position bits 48 (or 56) tru 64) compared to the subnet value of the 1st router's LAN…

    I meant your post wasn't exactly written in plain English, and due to that I didn't quite understand what your post was saying.

    For example, the bolded part above is difficult to understand. Do you mean how to split up a large subnet (1st router assigned /64) into smaller subnets? What's position bits 48 tru 64? Characters in the IP? An IPv6 IP has 128 bits (a /128). A /64 has the last 64 characters (in bits NOT hexadecimal as IPv6 addresses are commonly shown) as "changable" that's why it's a /64. A /48 has the last (128-48=)80 characters "changable". And by changable I mean you can change those bits to those you want.

    The last 64 characters should always be reserved for interface assignments. That's why you split the subnets into /64s.

    The 49-64 characters (in BITS) are "official" subnetting bits. And by that I mean that if you want a subnet, it has to be a /64, which can only come from the /48 (bits 49-54 in the IPv6 address).

    Splitting subnets therefore isn't some voodoo, it's something the Internet as a whole has been doing for a while. A region gets a /8 IPv4, which the regional authority splits into smaller subnets (usually /24s), which are assigned to your ISP, which in turn splits them into /30s for you to get on your router. You just pick a spot and start hacking away until you split it.

    If I made a typo somewhere, please feel free to correct me.



  • @jflsakfja:

    Anyway it is not a theoretical problem, the OP should have a clue by now.



  • @jflsakfja:

    What you need to do is A)get your ISP to give you a bigger subnet (if you are connecting multiple networks (interfaces) using that subnet, it must be a /48 (so that per interface /64s are assigned, which leads to IPv6 auto configuration working), OR B) you break up the /64 into smaller subnets and use pfsense's DHCPv6 to hand out addresses from those subnets. Depending on what your clients are, it might, or might not work. OR C)forget about autoconfiguration and use static addresses in your clients.

    I don't think you quite understand the OP's setup. He has an ISP-provided router on his premises (note the part about VoIP / DECT phones). That router is set up for DHCP-PD; i.e., it gets delegated a /56 dynamically from the ISP; this is a common setup for residential / SOHO internet. He now wants to set up pfSense behind that router; i.e., as a second level of routing in his home. Since the prefix delegated by the ISP is not (guaranteed to be) static, he can't just configure it as such on the pfSense box, and the only way to do dynamic v6 prefix assignment for LANs on pfSense is via DHCP-PD. For that to work, though, his first router (again, this is a router box in his home, not something on the ISP side) would have to re-delegate some part of the /56 it received from the ISP to the pfSense box. His ISP-provided residential gateway may or may not support doing that; like I said, I know pfSense would not.

    (As a side note, why would you think it would have to be at least a /48? Anything larger than a /64 can be sub netted, and most residential ISPs will only give you a /56 or less.)



  • @jflsakfja:

    The 49-54 characters (in BITS) are "official" subnetting bits. And by that I mean that if you want a subnet, it has to be a /64, which can only come from the /48 (bits 49-54 in the IPv6 address).

    No matter how you count, "49-54" is definitely wrong (note that that's six bits). The first 64 bits in a global unicast v6 address are split into n bits of global routing prefix and m bits of subnet ID (with some exceptions). Other than n+m = 64, there is no strict requirement for the size of either; see RFC 3513 and RFC 3587. Residential ISPs typically delegate something between /56 and /60.



  • @razzfazz:

    I don't think you quite understand the OP's setup. He has an ISP-provided router on his premises (note the part about VoIP / DECT phones). That router is set up for DHCP-PD; i.e., it gets delegated a /56 dynamically from the ISP; this is a common setup for residential / SOHO internet. He now wants to set up pfSense behind that router; i.e., as a second level of routing in his home. Since the prefix delegated by the ISP is not (guaranteed to be) static, he can't just configure it as such on the pfSense box, and the only way to do dynamic v6 prefix assignment for LANs on pfSense is via DHCP-PD. For that to work, though, his first router (again, this is a router box in his home, not something on the ISP side) would have to re-delegate some part of the /56 it received from the ISP to the pfSense box. His ISP-provided residential gateway may or may not support doing that; like I said, I know pfSense would not.

    (As a side note, why would you think it would have to be at least a /48? Anything larger than a /64 can be sub netted, and most residential ISPs will only give you a /56 or less.)

    What I would personally do is 1) bridge the ISP router 2) set up pfsense as a transparent firewall. 1 means finding what vlans are using what (voip/video/etc) and letting pfsense handle that, and 2 means accepting that all IPs assigned by pfsense will come from the /64 assigned to the ISP router.

    Without a post from the OP it's very difficult to come up with a working scenario, since all I can do is speculate (and get criticized about it).

    Besides the ISP router not allowing custom routing tables, nothing stops you (besides a broken keyboard) from using any addresses (even addresses not assigned to you) to route anything within your network. The only thing that breaks is traceroute.

    @razzfazz:

    @jflsakfja:

    The 49-54 characters (in BITS) are "official" subnetting bits. And by that I mean that if you want a subnet, it has to be a /64, which can only come from the /48 (bits 49-54 in the IPv6 address).

    No matter how you count, "49-54" is definitely wrong (note that that's six bits). The first 64 bits in a global unicast v6 address are split into n bits of global routing prefix and m bits of subnet ID (with some exceptions). Other than n+m = 64, there is no strict requirement for the size of either; see RFC 3513 and RFC 3587. Residential ISPs typically delegate something between /56 and /60.

    Well spotted. 5 is next to 6  ;)

    RFC3513 has been obsoleted.Following the updated RFCs doesn't specify where you must NOT use /48s.

    RFC3587 (and your post) says exactly what I'm saying. 64 bits end up in the interface, 48 bits end up in the grobal routing, which leaves 16 bits for the subnet. As long as your prefix is withing those bits, it can be assigned to a site. A site is anything that needs more than one /64, in other words a router with more than 2 interfaces.

    They assign the /56s and /60s because most people will never need anything larger than that. A /56 has 256 /64s, which means the router behind it can only have 255 interfaces (1 /64 for ISP router > residential router). A /60 has 16 /64s, which means 15 interfaces. The smallest subnet they can drop to is /63, since it only allows for 2 subnets => 1 "internal" interface.

    It's not as easy to just "drop down" a prefix and be done with it. If prefix 1 was routed to a client A and prefix 2 was routed to client B, if the client wishes to get 2 different subnets, the ISP would need to forget 1, and route 3 and 4. I don't see anything wrong with a /56 and a /60 for most residential users.



  • @jflsakfja:

    … If prefix 1 was routed to a client A and prefix 2 was routed to client B, if the client wishes to get 2 different subnets, the ISP would need to forget 1, and route 3 and 4....

    As I like to read, IF (…) Then (...) Else (...)
    So for (cold or hot) sake, what were you trying to say about subnetting and 2 routers in series ?



  • @hda:

    So for (cold or hot) sake, what were you trying to say about subnetting and 2 routers in series ?

    Take a large subnet and split it in 2. 1 small subnet for the router>router and 1 for the 2nd router's "clients".



  • @jflsakfja:

    Take a large subnet and split it in 2. 1 small subnet for the router>router and 1 for the 2nd router's "clients".

    Yeah right…
    But the question was how-to-do, isn't it ? Your bridging taking and splitting, in this specific OP case, is likely not possible or at least not operational defined.



  • I appreciate everyone's input this far, but nothing is clear on how to actually make this work.

    Please allow me to explain my situation in some detail:

    • ATT uVerse recently enabled ipv6 on some of their RGs, including mine

    • This first implementation appears to support only stateless autoconfig of LAN clients

    • Only /64s are being handed out on the LAN side

    • The RG itself is claiming it has a /60 delegation

    So, assuming that some part of that /60 can be re-delegated to the LAN side of the RG (which is where my pfSense ALIX is plugged in), how would that be done?

    Currently the nibble at bit positions 60-63 is zero.  And all ipv6 addresses handed out on the LAN side always have a zero in that field.  So I'm thinking the LAN side of pfSense would have a value of something other than zero in the 60-63 nibble.

    BTW, I totally get that AT&T's current ipv6 implementation is not "router friendly".  But it could be years (seriously) before many home users will see "correctly" implemented ipv6 in their homes.  I've spent hours with different iterations of static addressing and trying ways to get pfSense to use a subnet of that /60, but I can't ping out from the pfSense LAN side no matter what I try.



  • @gloomrider:

    I appreciate everyone's input this far, but nothing is clear on how to actually make this work.

    Please allow me to explain my situation in some detail:

    • ATT uVerse recently enabled ipv6 on some of their RGs, including mine

    Assuming by RG you mean a router.
    @gloomrider:

    • This first implementation appears to support only stateless autoconfig of LAN clients

    • Only /64s are being handed out on the LAN side

    • The RG itself is claiming it has a /60 delegation

    SLAAC (autoconfig) needs /64s that's why it hands out /64s. A /60 has 16 /64s.
    @gloomrider:

    So, assuming that some part of that /60 can be re-delegated to the LAN side of the RG (which is where my pfSense ALIX is plugged in), how would that be done?

    No stop, that's not the way to do it.
    @gloomrider:

    Currently the nibble at bit positions 60-63 is zero.  And all ipv6 addresses handed out on the LAN side always have a zero in that field.  So I'm thinking the LAN side of pfSense would have a value of something other than zero in the 60-63 nibble.

    BTW, I totally get that AT&T's current ipv6 implementation is not "router friendly".  But it could be years (seriously) before many home users will see "correctly" implemented ipv6 in their homes.  I've spent hours with different iterations of static addressing and trying ways to get pfSense to use a subnet of that /60, but I can't ping out from the pfSense LAN side no matter what I try.

    For simplicity's sake I'll explain it in hexadecimal, so you don't have to fiddle around with converting bits to hexadecimal. Subnet used is the subnet reserved for documentation, as shown in RFC3849.

    /60:
    2001:0db8:0000:0000:0000:0000:0000:0000(first address)-2001:0db8:0000:000f:ffff:ffff:ffff:ffff(last address).
    The blue part is the per client interface part. You should never ever touch unless assigning static IPs.
    The red part shows the /60. It can only contain 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e and f (16 characters=16 /64s (part in blue)).

    Your ISP's router knows that (any of all combinations of red+blue) the blue part above lies somewhere in the red part, and it can reach them through a smaller subnet (ISP's router WAN side).

    What you need to do:
    Let clients pick from 0-9 of the red part. This allows you plenty of growing space.

    Assign a (character) to pfsense's WAN. For simplicity's sake use 2001:0db8:0000:000a:0000:0000:0000:0001 as pfsense's WAN IP, subnet /64.
    Assign b (character) to pfsense's LAN. For simplicity's sake use 2001:0db8:0000:000b:0000:0000:0000:0001 as pfsense's LAN IP, subnet /64.
    Assign c (character) to OPT1 and so on and so forth until f (if needed).

    Create appropriate allow rules in the interfaces.

    IF you are lucky and the ATT router properly implements IPv6 it should work, since IPv6 routers are supposed to "peek" around them and figure out the routing.

    If you are unlucky, you'll need to tell the ATT router that the default gateway to networks b-f is pfsense's WAN IP.

    Use DHCPv6 (if needed, SLAAC should get you going) internally on pfsense.

    Admittedly I haven't tested this exact scenario. Don't stone me to death, just say I'm wrong.

    EDIT:
    On second thought, use 0-7 (red part) for the ISP's router LAN (a /61), b for pfsense's WAN (/64) and for pfsense's LAN c,d,e and f (/62). Technically that's more valid that what I said above. It also leaves 8,9 an "a" as spares.



  • @gloomrider:

    So, assuming that some part of that /60 can be re-delegated to the LAN side of the RG (which is where my pfSense ALIX is plugged in), how would that be done?

    In theory you might have nibble=2^4=16 subnets with your Residendial Gateway. BUT this depends on the RG cooperating though. What I have done, in cooperation with a "ATT free" router:

    SET: pfSense WAN / DHCP6 / Prefix Delegation size: =64 / Send IPv6 prefix hint =True
    This should get your WAN a /64 address that looks as follows: the first 64 bits the same as your RG (-LAN group) and the last 64 bits the MAC from your pfSense WAN iface.

    SET: pfSense LAN / Track Interface / IPv6 Prefix ID: =0
    This should get you your LAN a /64 address where only first 60 bits are the same as your RG(WAN). The bits 61 tru 64 are different are delegated and decided by the RG. The last 64 bits are the MAC of your LAN iface.

    Then this LAN iface can play SLAAC and accept all the clients in your pfSense LAN. Thats it !
    Your RG-LAN is now as a DMZ w.r.t. the pfSense.

    As evidence: My "RG"(AVM FB7360) has subnet value :1: and my pfSense has subnet value :ff:



  • @hda:

    @gloomrider:

    So, assuming that some part of that /60 can be re-delegated to the LAN side of the RG (which is where my pfSense ALIX is plugged in), how would that be done?

    In theory you might have nibble=2^4=16 subnets with your Residendial Gateway. BUT this depends on the RG cooperating though. What I have done, in cooperation with a "ATT free" router:

    SET: pfSense WAN / DHCP6 / Prefix Delegation size: =64 / Send IPv6 prefix hint =True
    This should get your WAN a /64 address that looks as follows: the first 64 bits the same as your RG (-LAN group) and the last 64 bits the MAC from your pfSense WAN iface.

    SET: pfSense LAN / Track Interface / IPv6 Prefix ID: =0
    This should get you your LAN a /64 address where only first 60 bits are the same as your RG(WAN). The bits 61 tru 64 are different are delegated and decided by the RG. The last 64 bits are the MAC of your LAN iface.

    I've done exactly this and the pfSense LAN interface never gets an ipv6 address.
    EDIT: I see this in the system log (vr2 is the pfSense LAN interface): radvd[32948]: no auto-selected prefix on interface vr2, disabling advertisements

    My assumption is that because the Residential Gateway is using SLAAC (not DHCPv6, that option is currently greyed out on the RG) on its LAN interface (which maps to pfSense WAN interface), the whole "track interface" paradigm won't work.



  • @gloomrider:

    My assumption is that because the Residential Gateway is using SLAAC (not DHCPv6, that option is currently greyed out on the RG) on its LAN interface (which maps to pfSense WAN interface), the whole "track interface" paradigm won't work.

    Ah yes, that can be the issue. In my "streetrouter" network settings w.r.t. IPv6 I can set:

    "Enable DHCPv6 server in the "streetrouter" for the home network"

    "Announce "streetrouter" as DNS server via DHCPv6. Parts of the IPv6 network assigned by the Internet service provider are passed on to downstream routers"

    At least now you have a spec. for ATT  ;)



  • @jflsakfja:

    Your ISP's router knows that (any of all combinations of red+blue) the blue part above lies somewhere in the red part, and it can reach them through a smaller subnet (ISP's router WAN side).

    Note that with DHCP-PD, in the general case, your WAN-side prefix does not have to be in any way related to the delegated (LAN-side) prefix. Point in case, as of right now, my WAN prefix is of the form 2001:558:…/128, while my delegated prefix is 2601:9:.../60.

    What you need to do:
    Let clients pick from 0-9 of the red part. This allows you plenty of growing space.

    Assign a (character) to pfsense's WAN. For simplicity's sake use 2001:0db8:0000:000a:0000:0000:0000:0001 as pfsense's WAN IP, subnet /64.
    Assign b (character) to pfsense's LAN. For simplicity's sake use 2001:0db8:0000:000b:0000:0000:0000:0001 as pfsense's LAN IP, subnet /64.
    Assign c (character) to OPT1 and so on and so forth until f (if needed).

    … except the delegated prefix is assigned dynamically with DHCP-PD, so a static setup like you suggest is not feasible. And as I mentioned earlier in the thread, the only way (to my knowledge) to dynamically assign prefixes to downstream interfaces in pfSense is via DHCP-PD / "track interface".

    Admittedly I haven't tested this exact scenario. Don't stone me to death, just say I'm wrong.

    Done.



  • so since i probably can not make ipv6 for the client network work with my current setup i want to get ridd of the ISPs router (speedport w724v) completely and let pfsense handle everything solely (as it was before we switched to voip).

    what i need is some sort of DECT base station that does VOIP or can "forward" VOIP to a asterisk (i'm not exactly sure how this would look like, voip is new to me)
    are there all-in-one boxes that can do this and don't require to be the main router to the internet?  (so i just have to open the ports for it in the firewall/NAT)
    i could also set up an VM with asterisk, but i somehow need the hardware to connect the phones via DECT and if the hardware has to be plugged in the server it has to work when on pci-passthrough on vmware esxi