NPTv6: add dynamic source addresses via track interface #5284

bimbar · 2021-10-16T12:14:12Z

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

The problem hear is small site multihoming. It's very nicely described here: https://blog.ipspace.net/2010/12/small-site-multihoming-in-ipv6-mission.html and can pretty much only be done with local ULA addresses and some sort of address translation toward the WAN interfaces. Right now it can only be done via NA(P)T66, which is the very same as NA(P)T44, and I don't think we want that anymore.
Now the implementation problem with it is that with NAT you can do the following:

nat on WAN inet6 from SOME_IP_RANGE to any -> (WAN:0) port 1024:65535

while with NPT (binat) you have to specify a source and a destination network, so some sort of integration into interface newwanipv6 will be necessary.

Describe the solution you like

I would like a "Track Interface" External IPv6 Prefix Option in addition to static External IPv6 Prefix in NPTv6, pretty much just like it is in the interface configuration dialog.
Specified would be:

IPv6 Interface
IPv6 Prefix ID

Describe alternatives you considered

Oh so many ones, but none of them work. The best one in clean IPv6 terms so far is to use two independent routers each with their own GUA prefixes which the independently advertise into LAN, only that works only if RFC3484bis is implemented or asymmetric routing is achieved.
The one that works is to just do it like in IPv4, with local addresses for LAN, and NA(P)T on the outside interface, but that's hardly the right solution.

Additional context

There's even a very nice RFC for that, namely https://datatracker.ietf.org/doc/html/rfc7157 "IPv6 Multihoming without Network Address Translation" but even they concede that NPTv6 is probably needed for now.
For static prefixes this should work nicely with static NPTv6, but if the prefixes are dynamic, it falls down.

The text was updated successfully, but these errors were encountered:

bimbar · 2021-10-16T14:49:45Z

But I'm not sure if that's even possible, it depends on the dhcpcv6 daemon telling someone which prefixess it was assigned.

cnbatch · 2021-10-20T09:10:58Z

Indeed, this feature should be fully supported by OPNSense ASAP.

FreeBSD itself supports such operation with IPFW, see the part of 'IPv6-to-IPv6 NETWORK PREFIX TRANSLATION (NPTv6)':
https://www.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8&format=html

This feature was added on Oct 30 2018: https://reviews.freebsd.org/D17765
by #2544 (comment)

One can use a command like
ipfw nptv6 NPT create int_prefix fd24:ca16:8eb0:5ab6:: ext_if em0 prefixlen 64
to create NPTv6 mappings and let the system monitor the change of IPv6 addresses.

This IPFW feature can also be used in command line console of OPNSense, but not yet supported in Web Interface.

AdSchellevis · 2021-10-20T11:15:01Z

we use pf(4) (https://www.freebsd.org/cgi/man.cgi?pf(4)), sounds similar to #4923, waiting for someone to properly document the feature (opnsense/docs#330 (comment)) before any code will be merged.

bimbar · 2021-10-20T11:39:43Z

Not quite the same, the one is about dynamic firewall rules, the other about dynamic NPTv6 rules

AdSchellevis · 2021-10-20T12:14:18Z

which is about the same concept, addresses should follow dynamic addresses for which aliases might be used.

bimbar · 2021-10-23T14:14:30Z

It likely needs much the same infrastructure in the backend.

marjohn56 · 2021-11-02T17:42:49Z

@bimbar - dhcp6c puts the GUA address on the interface, so you can get the prefix from the GUA address. The trick I think, if I understand NPTv6 correctly - Only looked at this 30 minutes ago - is to assign a ULA address to the interface ( alias is there for that already ) and to use dhcpdv6 and radvd to hand out ULA addresses on the LAN(s). Once you have that done, then would it possible to just NPTv6 the LAN ULA addresses to the GUA prefix for that interface?

bimbar · 2021-11-03T07:12:00Z

The prefix for the WAN interface is different from the prefix we need. Also, this prefix is not going to be set on any interface. It's not that simple.

marjohn56 · 2021-11-03T08:26:08Z

You misunderstood me I think. I am talking about the LAN(s) not the WAN. dhcp6c assigns the addresses to the interfaces, the GUAs that is. I quote you

But I'm not sure if that's even possible, it depends on the dhcpcv6 daemon telling someone which prefixess it was assigned.

That information is already available, In /tmp there is also another file, my wan is igb0, therefore the file is called igb0_pdinfo, that will give you the prefix and size. If it's any use I also have a versiion of dhcp6c that will give you the prefix that is assigned to the LANs, but as I said, that info is aleady available.

bimbar · 2021-11-03T19:46:28Z

Ok, so I have a hypothetical LAN interface with Track Interface WAN and offset 4. Now I want NPTv6 to translate the source prefix to the prefix this hypothetical interface would have been assigned (but it has been given a ULA prefix).

marjohn56 · 2021-11-04T09:28:10Z

It will also have been given a GUA address, you cannot stop dhcp6c doing that - unles we have some sort of virtual interface, but that's a different story. You can add an Alias to give a ULA address, BUT, dhcp6d and Radvd will give out the GUA addresses. If that was altered so that they gave out the ULA addresses then packets coming back to the LAN interface would have ULA addresses and, in theory, would hit the NPTv6 rule.

bimbar · 2021-11-04T13:41:16Z

Why can I not stop dhcp6c giving out GUAs? I can configure the interface with static IPv6 ULA.
Giving out GUAs makes the whole feature redundant.

marjohn56 · 2021-11-10T16:36:31Z

Just messing around to prove a point..

So I am using Track Interface, my test router has GUA prefixes on its LANs.. All OK
I added a VIP to the LAN of the test router using a ULA address. dhcpdv6 on that interface is disabled, I have also commented out the relevent parts of dhcpd.inc so that no GUA addresses are given out, but ULA ones are, this is what radvd.conf looks like:

interface igb1 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
prefix fc01:1::/64 {
DeprecatePrefix off;
AdvOnLink on;
AdvAutonomous on;
};
RDNSS 2a02:6b67:605d:3200:4262:31ff:fe00:c1b0 {
};
DNSSL localdomain {
};
};
It's still using the RDNSS but that doesn't matter in this case.

Then I added an NPTv6 entry, using the GUA /64 prefix from the test router LAN. WAN interface selected. My PC I set to pick up a dhcp6 address and looks like this:

Ethernet adapter traceLAN Test:

Connection-specific DNS Suffix . : localdomain
IPv6 Address. . . . . . . . . . . : fc01:1::2e0:4cff:fe67:7b54
Temporary IPv6 Address. . . . . . : fc01:1::c9a6:14fc:c5b:207c
Link-local IPv6 Address . . . . . : fe80::2e0:4cff:fe67:7b54%17
IPv4 Address. . . . . . . . . . . : 192.168.1.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::4262:31ff:fe00:c1b0%17
192.168.1.1

And the result is:

C:\Users\marti>tracert -6 www.google.com

Tracing route to www.google.com [2a00:1450:4009:817::2004]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms OPNsense.localdomain [fc01:1::1] <- test router LAN
2 <1 ms <1 ms <1 ms xxxx:xxxx:605d:0:20e:c4ff:fed2:8143 <- Primary router LAN
3 2 ms 1 ms 2 ms xxxx:xxxx:0:89::1 <- Upstreeam
4 2 ms 2 ms 2 ms 2a02:6b60:0:1:2::66
5 * 2 ms * xge-0-0-0-8.edge1.ld8.lon.network.as201838.net [2a02:6b60:0:1:1::66]
6 3 ms 3 ms 2 ms 2a02:6b60:0:1:3::62
7 * 2 ms * 2a00:1450:80f9::1
8 2 ms 2 ms 2 ms 2001:4860:0:1::41aa
9 * * 2 ms 2001:4860:0:1::248b
10 2 ms 1 ms 1 ms lhr25s26-in-x04.1e100.net [2a00:1450:4009:817::2004]

Trace complete.

So it works, perfectly possible to use the GUA Prefix on the LAN. And If instead of using an address as the external prefix it could use an alias, in the same way as the firewall rules we were working on earlier this year, then that would solve a few problems.

marjohn56 · 2021-11-11T09:33:42Z

Let's take this a step further. I see the need for the following:

Ability to only enable ULA address handouts in dhcpdv6 and radvd.
Ability to select the LAN GUA prefix ( as an alias ) in NPTv6
Abillity to select the LAN ULA prefix in NPTv6

@fichtner & @AdSchellevis - Does this fit the bill?

bimbar · 2021-11-11T13:00:16Z

Now I'm confused, as far as I can see in your example, you have no GUA prefix on LAN, but only an ULA prefix, yet you write in you conclusion that a GUA prefix on LAN works perfectly.

Anyway, what you tested is pretty much what I was thinking of, only you want to sort of virtually assign the GUA prefix to LAN while not advertising it, which would also be a way to implement it, I guess.

marjohn56 · 2021-11-11T17:43:09Z

That LAN is my PC's LAN, not the LAN of the router. That looks like this. Note I've change the ULA address to fc00 since yesterday.

igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC>
ether 40:62:31:00:c1:b0
inet6 fe80::4262:31ff:fe00:c1b0%igb1 prefixlen 64 scopeid 0x2
inet6 fc00:1::1 prefixlen 64
inet6 xxxx:xxxx:3200:4262:31ff:fe00:c1b0 prefixlen 64
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

It's the way I'd prefer to do it. It makes life much simpler IMHO.

bimbar · 2021-11-11T20:59:31Z

@bimbar - dhcp6c puts the GUA address on the interface, so you can get the prefix from the GUA address. The trick I think, if I understand NPTv6 correctly - Only looked at this 30 minutes ago - is to assign a ULA address to the interface ( alias is there for that already ) and to use dhcpdv6 and radvd to hand out ULA addresses on the LAN(s). Once you have that done, then would it possible to just NPTv6 the LAN ULA addresses to the GUA prefix for that interface?

Going back to your initial statement, I get what you want to do there, but, if you have a GUA and an ULA on the LAN, but advertise only the ULA, and translate that over to the GUA, what use is it to configure said GUA on LAN if it's not used.
It's only used as a NAT pool and as such should not be configured on any real interface.

marjohn56 · 2021-11-11T23:01:16Z

What about ISPs that don't give a GUA on the WAN? What if you want multiple LANs etc? The fact is yes you can get the prefix and size from a file that dhcp6c already creates, but the ability to NPTv6 to the GUA on the same LAN makes it simpler in other ways too. There are many ways to skin a cat.

bimbar · 2021-11-12T09:30:50Z

What about ISPs that don't give a GUA on the WAN? What if you want multiple LANs etc? The fact is yes you can get the prefix and size from a file that dhcp6c already creates, but the ability to NPTv6 to the GUA on the same LAN makes it simpler in other ways too. There are many ways to skin a cat.

You don't understand, instead of configuring some interface as "Track Interface WAN offset 1", you would configure the NPTv6 Destination Prefix as "Track Interface WAN offset 1".

marjohn56 · 2021-11-12T19:34:00Z

I DO understand I just see benefits of using the real interface. I am well aware that if you know the prefix that's been obtained you could just use that.

ivwang · 2021-11-24T11:43:15Z

Let's take this a step further. I see the need for the following:

Ability to only enable ULA address handouts in dhcpdv6 and radvd.

Ability to select the LAN GUA prefix ( as an alias ) in NPTv6

Abillity to select the LAN ULA prefix in NPTv6

@fichtner & @AdSchellevis - Does this fit the bill?

This really sounds nice and what I am looking forward to have.
Any chance to see it in next few releases? Finger crossed.

Thanks
Ivan.

AdSchellevis · 2021-11-24T12:31:10Z

(from #5284 (comment)) we use pf(4) (https://www.freebsd.org/cgi/man.cgi?pf(4)), sounds similar to #4923, waiting for someone to properly document the feature (opnsense/docs#330 (comment)) before any code will be merged.

As long as any change in this area fits the boundaries given earlier, I don't mind that much, I just would advise to keep it simple.

We all seem to get lost in this region quickly, which is only solvable if anything we do add will be explained unambiguously.

Speaking for myself (and likely @fichtner as well), I'm not planning to spend time on this before it's absolutely clear, already spend quite some time preparing everything in https://github.com/opnsense/core/tree/FR_4923, after which everything kept circling back.

bimbar · 2021-11-24T14:53:21Z

I'd propose merging some implementation of something soon, rather than wait for something perfect which may never come.

All with the understanding it may change completely as soon as its shortcomings are understood.

But if nothing is merged, there is no base which can be argued in a wider audience.

Release early, release often.

AdSchellevis · 2021-11-24T14:56:25Z

Not if the fundamentals are unclear, it's rather simple, someone should write it down (design) before starting to build anything, to prevent future issues impossible to fix further down the road. We spend years refactoring a lot of madness and believe me, trouble starts with vague objectives.

bimbar · 2021-11-25T09:04:12Z

Well, there's enough ideas, someone ultimately has to decide what to actually do.

ivwang · 2021-12-01T11:55:56Z

Is it possible to first develop Martin's implementation into a plugin, as a mean to discover what is lacking (if any) down the road?

For my use-case, it's primarily to deploy opnsense and IPv6 reliably with upstream ISPs changing IPv6 PD assignment frequently, in that Insulating LAN side address ranges from those ISPs by NPT and ULA.

So Martin's implementation that

enables dhcp6d/radvd to advertise ULA
allows user to specify NPT by mapping between ULA prefix and IPv6 PD (tracking WAN)
refreshes NPT translation rules automatically when tracked IPv6 PDs are changed.
fits the bill.
If anything not explicitly stated, is that assigning ULA directly to LAN side physical interfaces without the need to create a virtual one.

Thanks
Ivan.

AdSchellevis · 2021-12-01T12:12:02Z

Is it possible to first develop Martin's implementation into a plugin, as a mean to discover what is lacking (if any) down the road?

I assume you mean the work me and Martin did which is waiting in https://github.com/opnsense/core/tree/FR_4923, but no, you can't easily move that to a plugin as you don't have anything to plug it into. (yes, you can develop a plugin offering this functionality, but I don't expect anyone would like to spend the amount of time needed to convert this to a stand-alone feature).

As soon as the concerns in the doc's PR are cleared (opnsense/docs#330), we can start moving code in, as I've mentioned earlier as well.

marjohn56 · 2021-12-01T14:08:38Z

@AdSchellevis - No, he means the ability to select an address range to use within dhcpdv6. At present you can only create one range within dhcpdv6 / radvd, thus is you use tracking you can overide and make your own range but if you have a ULA alias on that inferface you cannot use that, as the existing code picks the GUA. What it would need is the ability to force the range entered so that the sanity check is overridden. I do not see the need to be able to have both ULA and GUA ranges handed out by dhcpdv6, but where both exist on an interface, then the ability to select or specify the range would be useful. I did a bit of hacking and forced the ULA in dhcpdv6 then used NATv6 to translate the ULA to the GUA prefix on the LAN, it worked nicely. It sort of comes back to being able to track the GUA again and automagically compensate for a changing pd.

AdSchellevis · 2021-12-01T14:22:51Z

@marjohn56 ok, clear, sounds like a no as well when it comes to building a plugin.

ivwang · 2022-11-10T11:30:01Z

This is indeed a great addition.
So I take it out for a spin, however, I am not quite sure I configure it right. The NPTv6 prefix "sort-of" works in my setup.

Here is the thing, my ISP assigns an IPv6 /64 GUA to opnsense's wan and delegates a dynamic /64 prefix, this is typical and the prefix my lan interface uses by "tracking interface wan"

After patching, I changed my lan to static IPv6 ULA then under Firewall > NAT > NPTv6 added a rule on wan interface with lan's /64 ULA prefix as internal prefix and left external prefix empty.

Then checking test-ipv6.com from one of the lan hosts indeed gets through since the lower 64-bit of ipv6 address shown by test-ipv6.com matches that of lan host's ULA, however, the prefix is the prefix from the /64 GUA on wan instead of the supposedly delegated /64 prefix.

it looks like I missed something, any thoughts?

Thanks a lot

fichtner · 2022-11-10T11:32:34Z

@ivwang thanks for testing! this is correct if you use /64, but you can actually match the delegated prefix size on the WAN side, which would make the prefix ID "visible" if you use NPT on the full prefix size.

fichtner · 2022-11-10T11:33:57Z

(the ULA might have to match the prefix ID part of the address in order for this to work, I'm not entirely sure)

ivwang · 2022-11-11T11:10:13Z

@fichtner Oh. thanks for the reminder. I think this patch works and I am happy now :)

BTW, for people using fc00::/7 ULA prefixes don't forget to allow bogus networks on the internal interface or the auto-generated rule will block those.

Thanks again.

fichtner · 2022-11-11T11:13:40Z

Nice, thank you. Let’s ship this on 22.7.8 then :)

christiankratzer · 2022-11-11T11:35:02Z

Are we clear that this does not have to be ULA. We could have any valid prefixes on the LAN from which to nat.

use ula on the lan and nat to wan prefix
use PA/PI prefixes from another connection and nat to prefix of other ISP
use PA/PI prefixes from somewhere else because you have those in a VPN and nat to prefix of ISP when going to the internet.

The source can be anything. It does not have to be ULA.

fichtner · 2022-11-11T12:25:47Z

Yes, if you have two prefixes this can make sense. But the internal one needs to be static in one way or another, which is the case for 99% of the users waiting for this. 😊

christiankratzer · 2022-11-11T12:59:57Z

Yes the internal prrefixes are static which is exactly my use case. Just wanted to know that nobody hard coded any other assumptions like them having to be ULA.

My use case is having stable internal prefixes for various vpn tunnels.

fichtner · 2022-11-11T13:14:16Z

Sure, makes sense. There is a possibility to also auto-detect the internal prefix (using an interface selection most likely), but we want to see how auto-detect works in practice first.

RehaagJ · 2022-11-11T18:20:52Z

I have been testing this in a Multi-WAN environment, with mixed results.

Two WAN interfaces, both dynamic (one FTTH on ix0, one DSL on pppoe0). Both are getting /56 prefixes assigned, both get GUA interface addresses assigned that are outside the assigned prefix ranges. There are files ix0_prefixv6 and pppoe0_prefixv6 in /tmp with the correct /56 prefixes.

The internal networks are using /64 ULAs now.

When I use /64 in the NPTv6 rule, the DSL provider routes the packets OK, and I can see the prefix from the interface’s GUA combined with the lower 64 bits of the ULA in test-ipv6.com, just like ivwang describes above. Using /56 in the NPTv6 rule, test-ipv6.com says that I don’t have an IPv6 address, and traceroute6 does not reply anything. Using packet capture, I can see that the prefix ID is indeed used, the translated address now consists of the first 56 bits of the interface’s GUA, followed by the lower 72 bits of the ULA.
The FTTH provider does not route anything in both cases (both /64 and /56 on the NPTv6 rule create addresses like described above, but that provider seems to only route the /128 GUA). Both fail in test-ipv6.com.

I suppose the problem could be solved by using the delegated prefix that can be seen in the /tmp/ix0_prefixv6 and /tmp/pppoe0_prefixv6 files instead of the interface’s GUA prefix when doing the translation. Would that be possible to change, or add as an option?

christiankratzer · 2022-11-11T18:37:05Z

Using the delegated prefix instead of the wan interfaces GUA is definetely the right thing to do.
That is what the delegated prefix is intended for.

fichtner · 2022-11-11T19:27:25Z

I’m unwilling to embed an explicit prefix into the rules for obvious reasons at this stage. Depending on the ISP and network gear you get the PD net on WAN or not and contributors to this issue have proven to be nonexistent 🤷‍♂️

fichtner · 2022-11-11T19:30:36Z

Fixed as in literal as in explicit as per edit. -.-

RehaagJ · 2022-11-11T19:30:53Z

Sorry, misread your comment (fixed vs explicit), so I deleted a comment. What contribution would be needed?

fichtner · 2022-11-11T19:34:23Z

Some sort of sensible progression of gradual improvement and ideas. ;) I suppose we can pick up the prefix from a LAN tracking it. I don’t want to reach for the file or ifconfig as that will be stale after a reload and cause wonkiness or the rule to disappear because the address is not available.

christiankratzer · 2022-11-11T19:43:34Z

The whole idea of prefix delegation is to give the consumer address space to use. The broadband consumer will generally not be able to use anything but the /128 of the prefix on the WAN interface. It is the dynamic delegated prefix that should be used for any kinds of prefix nat.

This is of course also the difficulty as the delegated prefix does not sit on any interface from where it could be picked easily.

There needs to be a trigger that updates the rules when the delegated prefix changes.

I know too little of how opnsense sets these things up to be able to recommend a solution. Trying to help though.

RehaagJ · 2022-11-11T20:08:26Z

Fully agree about the file, I mentioned it just to point out that the information exists somewhere. And indeed, it's not a good source.
The trigger mentioned in the previous post does seem to exist already? Local interfaces using WAN tracking are already being updated when the WAN changes (not sure what exactly triggers the update, is it newwanip?). Anyway, that could be a starting point to update the rules also.
I also don't know enough about the architecture, but I would like to help as well. For now, that'll be testing...

fichtner · 2022-11-11T20:53:57Z

@christiankratzer not sure what you mean. The prefix is effectively on each tracking LAN, but with a /64. however, we do have the prefix size hint from the WAN configuration. I don’t see an issue here.

@RehaagJ the filter might not reload for varying reasons and also PPPoE can be a factor of further difficulty wedged in between. So we can’t rely on the ruleset to be reloaded at all times/at the perfect times. We spent a lot of effort to remove such problems from the generated pf.conf rules over the years actually.

christiankratzer · 2022-11-11T21:18:41Z

@fichtner There are several prefixes involved in this context

The prefix of the WAN interface which is not relevant for this exercise. Generally the only usable address out of the lan prefix is the single /128 on the interface.

The various statically configured prefixes of the LAN interfaces which are always /64.

The dynamic prefix (IA_PD) that is delegated from the ISP through DHCPv6 or PPPoE ( typically a /56 or /48 ).

The task would be to NAT the LAN various LAN prefixes to a subnet of the delegated prefix.

LAN1:: nat to IA_PD:1::
LAN2:: nat to IA_PD:2::
LAN3:: nat to IA_PD:3::

christiankratzer · 2022-11-11T21:24:26Z

@fichtner

on this:

@christiankratzer not sure what you mean. The prefix is effectively on each tracking LAN, but with a /64. however, we do have the prefix size hint from the WAN configuration. I don’t see an issue here.

The whole idea of this use case is to not allow the dynamic delegated prefixes to propage to the LAN interfaces so that one can statically configure them to ULA or other prefixes.

This is why we need prefix NAT to be dynamic to the assigned prefix.

I get the challenge in keeping this in sync. I remember somebody writing that pfsense had a similar feature. We should investigate what they have and how they implemented it.

fichtner · 2022-11-11T21:30:59Z

I still understand the issue but not the challenge after getting a milestone done here. I don’t see a problem improving this as required by certain PD deployments. And you don’t want to look what pfSense did ;)

christiankratzer · 2022-11-11T22:06:52Z

The question I have is does the curent milestone nat to the prefix of the WAN interface or to the assigned prefix ?

What I am trying to say is that natting to the WAN prefix instead of the delegated prefix would not serve any purpose as only the /128 would be usable. That would require ipv4 style hide nats instead of a prefix nat.

I am not aware of any residential deployments where the user could use any iP other than the assigned IP on the WAN prefix.

My current setup is fully static so I am unable to test immediately.
I need to build a lab setup for this with some VM to fully test.

(cherry picked from commit 32c783c) (cherry picked from commit b7a9d0b) (cherry picked from commit f7e64ba) (cherry picked from commit 17ec326)

bimbar mentioned this issue Nov 2, 2021

outgoing IPv6 NAT uses wrong (probably old) address #5325

Closed

2 tasks

OPNsense-bot added the help wanted Contributor missing / timeout label Nov 9, 2022

fichtner self-assigned this Nov 9, 2022

fichtner reopened this Nov 9, 2022

fichtner removed the help wanted Contributor missing / timeout label Nov 9, 2022

fichtner mentioned this issue Nov 10, 2022

Add ULA DHCPDv6 Option #5408

Closed

fichtner closed this as completed Nov 11, 2022

fichtner added a commit that referenced this issue Nov 14, 2022

firewall: allow external dynamic address in NPT #5284

a3683b0

(cherry picked from commit 32c783c) (cherry picked from commit b7a9d0b) (cherry picked from commit f7e64ba) (cherry picked from commit 17ec326)

fichtner mentioned this issue Nov 26, 2022

NPTv6: Use an internally delegated prefix as the external prefix (following 'Track Interface' feature) #6158

Closed

2 tasks

NPTv6: add dynamic source addresses via track interface #5284

NPTv6: add dynamic source addresses via track interface #5284

Comments

bimbar commented Oct 16, 2021 • edited Loading

bimbar commented Oct 16, 2021

cnbatch commented Oct 20, 2021

AdSchellevis commented Oct 20, 2021

bimbar commented Oct 20, 2021

AdSchellevis commented Oct 20, 2021

bimbar commented Oct 23, 2021

marjohn56 commented Nov 2, 2021

bimbar commented Nov 3, 2021

marjohn56 commented Nov 3, 2021 • edited Loading

bimbar commented Nov 3, 2021

marjohn56 commented Nov 4, 2021

bimbar commented Nov 4, 2021

marjohn56 commented Nov 10, 2021

marjohn56 commented Nov 11, 2021

bimbar commented Nov 11, 2021

marjohn56 commented Nov 11, 2021

bimbar commented Nov 11, 2021

marjohn56 commented Nov 11, 2021

bimbar commented Nov 12, 2021

marjohn56 commented Nov 12, 2021 via email • edited Loading

ivwang commented Nov 24, 2021

AdSchellevis commented Nov 24, 2021

bimbar commented Nov 24, 2021 • edited Loading

AdSchellevis commented Nov 24, 2021

bimbar commented Nov 25, 2021

ivwang commented Dec 1, 2021 • edited Loading

AdSchellevis commented Dec 1, 2021

marjohn56 commented Dec 1, 2021 • edited Loading

AdSchellevis commented Dec 1, 2021

ivwang commented Nov 10, 2022

fichtner commented Nov 10, 2022

fichtner commented Nov 10, 2022

ivwang commented Nov 11, 2022

fichtner commented Nov 11, 2022

christiankratzer commented Nov 11, 2022

fichtner commented Nov 11, 2022

christiankratzer commented Nov 11, 2022

fichtner commented Nov 11, 2022 • edited Loading

RehaagJ commented Nov 11, 2022

christiankratzer commented Nov 11, 2022

fichtner commented Nov 11, 2022 • edited Loading

fichtner commented Nov 11, 2022

RehaagJ commented Nov 11, 2022

fichtner commented Nov 11, 2022

christiankratzer commented Nov 11, 2022

RehaagJ commented Nov 11, 2022

fichtner commented Nov 11, 2022

christiankratzer commented Nov 11, 2022

christiankratzer commented Nov 11, 2022

fichtner commented Nov 11, 2022

christiankratzer commented Nov 11, 2022

bimbar commented Oct 16, 2021 •

edited

Loading

marjohn56 commented Nov 3, 2021 •

edited

Loading

marjohn56 commented Nov 12, 2021 via email •

edited

Loading

bimbar commented Nov 24, 2021 •

edited

Loading

ivwang commented Dec 1, 2021 •

edited

Loading

marjohn56 commented Dec 1, 2021 •

edited

Loading

fichtner commented Nov 11, 2022 •

edited

Loading

fichtner commented Nov 11, 2022 •

edited

Loading