Re: FreeBSD 12.3-p5: problems vnet on if_bridge
On Tue, 24 May 2022 09:52:46 + Ole wrote: Hello, > Hello, > > could you solve the problem? I think I ran into the same problem. > I opened a Ticket. I couldn't solve the problem. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264198 > > I seems to be related to IPFW and effects vnet-Jails and also bhyve VMs. There is also a PR regarding vnet/if_bridge/routing issues, at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240106 but I can not guarantee this PR is in any way similaror adjacent to the problem of mine (and probably yours). For reasons not to be discussed here I'm bound to FreeBSD 12.3-RELENG (XigmaNAS base) and running several boxes of different hardware grades with the very same XigmaNAS version gives different results. The host in question in my case has Intel NICs, the box with a very similar setup and vnet jails also on the same NIC the LAN resides on, has a Realtek NIC (it is a very small home NAS). Another has a dedicated NIC into another network (diffrent IP of the NIC and the vnet jails bound to that NIC compared to the LAN/host itself - Intel i350 NICs all over the place, no problems. Another case, our build platform, is running CURRENT and hosts about almost 15 jails on a NIC, which is part of the same network as the main host's NIC - no problem. All of our FreeBSD boxes uses IPFW as their IP filtering facility. Have you checked the MAC addresses of you vnet jails / vnet hosts? I have had on 12-CURRENT a serious issue with the very same MAC address on all jail-belonging parts of the epair vnet interface. I haven't checked this on our 12.3 (XigmaNAS) installations, I remember this issue as I writet this email, it could be a hint to look after ... > > regards > Ole Kind regarads, O. Hartmann > > > Wed, 11 May 2022 20:47:55 +0200 - FreeBSD User : > > > On Tue, 10 May 2022 21:21:29 +0200 > > FreeBSD User wrote: > > > > > Hello, > > > > > > I ran into serious trouble setting up a FreeBSD 12.3-RELEASE-p5 > > > host having a second NIC and vnt jails attached to that second NIC > > > (basically, the host is a recent Xigmanas with Bastille jails, but > > > the issue also occurs on a vanilla FreeBSD 12.3). > > > > > > The host is compromised of two NICs, em0 (management only) and igb0 > > > (service/jails). Both, the server and the jails as well as the igb0 > > > interface are residing on the same network, but both NICs are > > > connected to two different ports on a switch, to which we do not > > > have access (part of the campus infrastructure). > > > > > > Both NICs are attached with a IPv4 of the same network, the host is > > > listening on both NICs for services, i.e. port 22 for ssh. No > > > problem to connect to both(!) addresses via ssh. igb0 is member of > > > an if_bridge. The box also hosts a bunch of vnet jails, each jail > > > does have an if_epair created via "jib" and these vnet epairs are > > > members of the bridge, to which ifb0 is also member. > > > > > > Problem: while any service bound to NIC igb0/IPv4 residing on igb0 > > > is accessible flawlessly, accessing an jail is almost impossible. > > > Pinging a jail does work after a while the ping initiating host has > > > been waiting, in ery rare situations someone can access the sshd of > > > the jail, but any access of that kind is highly erratic. From 5 > > > jails, at most two are responding to pings, the other don't and it > > > is non-deterministic which host will respond. > > > > > > Following some advices found on the web, the following sysctl > > > settings are provided to if_bridge: > > > > > > deviceif_bridge > > > net.link.bridge.ipfw: 0 > > > net.link.bridge.allow_llz_overlap: 0 > > > net.link.bridge.inherit_mac: 0 > > > net.link.bridge.log_stp: 0 > > > net.link.bridge.pfil_local_phys: 0 > > > net.link.bridge.pfil_member: 0 > > > net.link.bridge.ipfw_arp: 0 > > > net.link.bridge.pfil_bridge: 0 > > > net.link.bridge.pfil_onlyip: 0 > > > > > > We do not have access to the switch the box is connected to, so I > > > don't have access to any logs revealing a problem either to a > > > conceptual misunderstanding of networking of mine and so a > > > misconfiguration or a probelm with Layer 2 or the switches > > > themselfes. > > > > > > I'd like to ask whether someone has a similar setup up and running > > > and could report this > > > - or give a hint of the problem I possibly made (igb0 is attach
NPTv6: prefix doesn't change in IPFW when prefix changes on dynamic interface
Hello, running a small routing/firewall applicance based on 13-STABLE and IPFW, I face a problem with NPTv6. The external IPv6 is changing dynamically. While ipfw in-kernel NAT catch up with dynamical changes of the IPv4, NPTv6 doesn't seem so. I'm neither an expert in networking nor IPFW. After a couple of days tun0 (the exterior PPP interface, uplink connection managed via mpd5) has a lot of IPV6 addresses, all but one are marked "deprecated". When restarting every 24 hours mpd5, only one official IPv6 address/prefix is assigned to tun0 (I'm neglecting the ULA and link-local, they are allways present). Since a couple of weeks for now, restarting mpd5 results in a crash of FreeBSD 13-STABLE, so my ISP is changing the IPv6 and this results in the "deprecated" prefixes. I was wondering if the IPFW NPTv6 facility isn't getting automatically the new, non-deprecated prefix or do I have to trigger this by restart ipfw as well? In case nor mpd5 is restarted or the exterior interface is assigned with several IPv6 addresses of which all but one are marked deprecated, pinging the outside world via IPv6 will take the wrong IPv6 - IPFW doesn't seem to catch up with the changes. How to fix this? Thank yo very much in advance, O. Hartmann -- O. Hartmann
Re: NPTv6: prefix doesn't change in IPFW when prefix changes on dynamic interface
Am Fri, 25 Nov 2022 10:40:31 +0300 "Andrey V. Elsukov" schrieb: > 24.11.2022 18:27, FreeBSD User пишет: > > Hello, > > > > running a small routing/firewall applicance based on 13-STABLE and IPFW, I > > face a problem > > with NPTv6. The external IPv6 is changing dynamically. While ipfw in-kernel > > NAT catch up > > with dynamical changes of the IPv4, NPTv6 doesn't seem so. > > > > I'm neither an expert in networking nor IPFW. > > > > After a couple of days tun0 (the exterior PPP interface, uplink connection > > managed via > > mpd5) has a lot of IPV6 addresses, all but one are marked "deprecated". > > > In case nor mpd5 is restarted or the exterior interface is assigned with > > several IPv6 > > addresses of which all but one are marked deprecated, pinging the outside > > world via IPv6 > > will take the wrong IPv6 - IPFW doesn't seem to catch up with the changes. > > > > How to fix this? > > Hi, > > probably the easiest way to solve your problem is periodically running > some script that will find and delete deprecated addresses from an > interface. > > Then NPTv6 module will use first global prefix on the interface. > I realized some strange behaviour and I wasn't able to come along with it. From the net behind the firewall/router after either the router appliance has been rebooted or ipfw restarted, "ping -6 freebsd.org" works from any host, but not from the router/firewall itself. After my ISP has changed both the IPv4 AND IPv6 and tun0, the exterior-pointing PPP interface has got at least one deprecated IPV6 address (it is also a "temporary IPv6 address" created to hide the MAC of the exterior interface), the router itself is capable of pinging IPv6 addresses in the outside world. But no host within my LAN is. Simply deleting all "deprecated" marked IPv6 addresses from the tun0 interface doesn't change anything. NPTv6 is configured to use tun0, not an IPv6 prefix. IPv6 routing on the router done via its link-local fe80... address, if this is of interest. I think I have to investigate the packet flow within IPFW and would like to ask wheter there is a kind of monitor? Thanks and kind regards, O. Hartmann -- O. Hartmann
IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW
Hello, running a small nanoBSD firewall/router appliance, the WAN interface (tun0) is confugred via SLAAC when it comes to IPv6. The allpliance is running in-kernel compiled IPFW. The OS is FreeBSD 13-STABLE, compiled on a recuurant weekly basis. On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN interface. We use NPTv6 to translate ULA addresses for the inner IPv6 networks. We use IPv6 privacy on the tun0 interface. The router/firewall is operating after a reboot or restart of mpd5 correctly, IPv6 and IPv4 networks have conection to the internet. When the ISP rotates it IPs, the IPv6 address is configured using SLAAC and mpd5 seems to act weird: - the IPv4 address is always set correct, IPFW and in-kernel NAT route/filter traffic correctly - sometimes old IPv6 address is dumped and only a new IPv6 address - in such a case, the old IPv6 is gone, the new pair (temporary and MACified address are the only IPv6 addresses attached to the interface. - sometimes the old IPv6 address set (= temporary) are marked "deprecated" and/or "detached" and a new set is attached to the interface tun0, in some rare occassion also an IPv6 address WITHOUT its "temoprary" sibbling is attached. In any of the cases above, IPFW's NPTv6 gets confused, routing isn't working properly anymore. In any cases of a change of the IPv6 address, IPFW has to be restartet! In cases with marked deprecated and/or detached addresses, IPFW has to be restarted, AND the deprecated and/or detached IPv6 addresses has to be deleted manually. Otherwise - so it seems to me - NPTv6 takes the wrong (outdated) prefix. NPTv6 should not take any deprecated, detached prefix if a valid prefix is available. Even deleting the deprecated IPv6 requires a restart of IPFW. No matter how long I wait, NPTv6 never gets the changed prefix by itself. Kind regards, Oliver -- O. Hartmann
Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW
Am Sun, 19 Feb 2023 13:30:13 +0300 "Andrey V. Elsukov" schrieb: > 18.02.2023 18:42, FreeBSD User пишет: > > On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN > > interface. We use NPTv6 to translate ULA addresses for the inner > > IPv6 networks. We use IPv6 privacy on the tun0 interface. The > > router/firewall is operating after a reboot or restart of mpd5 > > correctly, IPv6 and IPv4 networks have conection to the internet. > > When the ISP rotates it IPs, the IPv6 address is configured using > > SLAAC and mpd5 seems to act weird: > > > > - the IPv4 address is always set correct, IPFW and in-kernel NAT > > route/filter traffic correctly - sometimes old IPv6 address is dumped > > and only a new IPv6 address - in such a case, the old IPv6 is gone, > > the new pair (temporary and MACified address are the only IPv6 > > addresses attached to the interface. - sometimes the old IPv6 address > > set (= temporary) are marked "deprecated" and/or "detached" and a new > > set is attached to the interface tun0, in some rare occassion also an > > IPv6 address WITHOUT its "temoprary" sibbling is attached. > > > > In any of the cases above, IPFW's NPTv6 gets confused, routing isn't > > working properly anymore. > > > > In any cases of a change of the IPv6 address, IPFW has to be > > restartet! > > Hi, > > I assume you are using ext_if option in your NPTv6 instance configuration. That is correct. > > I think there might be several problems that lead to your situation: > > 1. NPTv6 tracks IPv6 addresses deletion, but since an old IPv6 address > that was used as external prefix kept on the interface, it ignores > appearance of new IPv6 address. > > 2. Then, even if you delete old IPv6 address by hand, NPTv6 won't try to > peak another one until there won't appear new address. > > 3. There should be some logic that takes into account presence of > temporary and deprecated addresses on the interface. > -- O. Hartmann pgpZFZalHYCyW.pgp Description: OpenPGP digital signature
IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)
Hello, I've got a problem with recent CURRENT, running vnet JAILs. FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET 2024 amd64 Main Host has IPFW configured and is open for services like OpenLDAP on UDP/TCP and ICMP (ipfw is configured via rc.conf in this case, host is listening on both protocol families IPv4 and IPv6). The host itself has openldap-server 2.6 as a service. The host's interface is igb0 with assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces via a bridge with the same physical device as the host (igb0). After a while (the time elapsed is unspecific) the jail is unable to contact the host via IPv6: neither UDP, TCP nor ICMP sent from the JAIL is reaching the host. IPv4 is working like a charme! No problems there. When pinging the Jail from the main host via ping -6, the jail is responding! After the first ping -6, the jail now is able to ping -6 the main host. After a fresh reboot, the problem is not present and occurs after a while and it seems to happen first to very active jails. Kind regards, oh -- O. Hartmann
Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)
Am Mon, 8 Jan 2024 01:33:53 +0100 (CET) Felix Reichenberger schrieb: > > Hello, > > > > I've got a problem with recent CURRENT, running vnet JAILs. > > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET > > 2024 amd64 > > > > Main Host has IPFW configured and is open for services like OpenLDAP on > > UDP/TCP and ICMP > > (ipfw is configured via rc.conf in this case, host is listening on both > > protocol families > > IPv4 and IPv6). > > > > The host itself has openldap-server 2.6 as a service. The host's interface > > is igb0 with > > assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces > > via a bridge > > with the same physical device as the host (igb0). After a while (the time > > elapsed is > > unspecific) the jail is unable to contact the host via IPv6: neither UDP, > > TCP nor ICMP > > sent from the JAIL is reaching the host. IPv4 is working like a charme! No > > problems there. > > > > When pinging the Jail from the main host via ping -6, the jail is > > responding! After the > > first ping -6, the jail now is able to ping -6 the main host. > > > > After a fresh reboot, the problem is not present and occurs after a while > > and it seems to > > happen first to very active jails. > > > > Kind regards, > > > > oh > > > > > > -- > > O. Hartmann > > > > Hello, > > This behavior might be caused by IPFW blocking some IPv6 neighbor > discovery/advertisement > messages. > After some time, the link layer addresses of the IPv6 neighbors in the NDP > cache may expire, > making the associated IPv6 addresses inaccessible. > Do your IPFW rules allow ICMPv6 messages to and from IPv6 multicast addresses? > > Regards. > Thank you for responding. Thank you for his valuable hint! The jail(s) itself/themselfes as well as the host use the regular ipfw rc setup script as provided with the base system, adding simply those ports open which provide services - a plain and simple approach. Checking the jails on the host in question (jails are contacting OpenLDAP server on host, OpenLDAP server configured for test purposes to listen only on IPv6) leaves me with inconclusive results. Assuming a jail, called host-git, and a host, master. Deleting the NDP entries aon hostgit via "ndp -c" leaves me with the initial reported issue here, the solution is to ping the host-git first from host-master to "magically open" the IPv6 connection. After that, ldapsearch or any other IPv6 connections originating on the host-git work again. That seems odd. jails are vnet. Jails reside on a bridgeXX interface, sharing the physical NIC of the master host. Just for the record. I use a similar setup on a XigmaNAS host (13.2-RELEASE-p8), also with active IPFW on the master host's side as well as IPFW enabled on the Jail's side. Difference to the above mentioned setup: The jail is located on a different host, contacting master-host via a switched network. Regards, oh -- O. Hartmann
FreeBSD serious problems with vnet on if_bridge (probably ARP related?)
Hello, I ran into serious trouble setting up a FreeBSD 12.3-RELEASE-p5 host having a second NIC and vnet jails attached to that second NIC (basically, the host is a recent Xigmanas with Bastille jails). Hopefully, I can gather some answeres here. The host is comprised of two NICs, em0 (management only) and igb0 (service/jails). Both, the server and the jails as well as the igb0 interface are residing on the same network, but both NICs are connected to two different ports on the switch (I assume, we do not have access to the campus network inrastructure). Both NICs are attached with an IPv4 of the same network, the host is listening on both NICs for services, port 22 (ssh) for instance, other services are supposed to be bound to the second NIC (igb0, like NFS, SMB and so on). em0 is only listening for 22/tcp and 443/tcp as it is meant for management only. igb0 is member of a bridge as well as the vnet interfaces (epair) of thr jails, created via "jib" (the host is basically a recent XigmaNAS 12.3.0.4.9047). The igb0 NIC has also an IP from the LAN - some advices to do so, other advice to avoid setting an IP, but the management interface of XigmaNAS forces me to apply an IP. Just for the record. Problem: it seems that in a non predictable way connections are droped, ARP packages reach the vnet and in other cases ARP doesn't reach a vnet. The phenomenon is weird. The host is running 6 jails with regular FQDN and IPv4 addresses. All jails are up, the base NIC (igb0) is also up and running. It is possible, in rare cases, to connect via ssh frome remote sites to at most two(!) of the jails. It is impossible to predict which jail is connecting first and it is like a lottery which one will respond. Pinging the jail from the LAN or remote sites is also weird: as with the ssh connection, sometimes a jail responds immediately as expected, in some other cases it takes 10 - 30 seconds until ping starts to report replies. Connecting to the base host has never been a problem, so i assume the base network to be all right. Connecting to a jail locally via "jexec -l" and performing some tcpdump invstigations reveals weird results: tcpdump -vi vnet0 arp does show ARP a plethora of packets from the local network on a jail that is reposnding quickly to ping or is giving access to ssh, but on those jails which are resilient to connection and ping attempts, ARP packets seem to vanish. By having screens/terminals adjacent of those jails while pinnging and tcpdumping, its obvious that not all "arp: who-has ... tell" requests are evenly distributed to all bridge members as I'd expect. Following some advices found on the web, the following sysctl settings are provided to if_bridge (main host): device if_bridge net.link.bridge.ipfw: 0 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 0 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_onlyip: 0 I also fiddled around with disabling LRO, TSO, RXCSUM and TXCSUM on all physicsal NICs as somewhere recommended due to buggy FreeBSD NIC driver, but without any help. Please see below for some physical details to the NICs on the box. In another department I've setup a similar box (also XigmaNAS), but this time the second NIC is a different type (i350-T2). The physical port which is member of the if_bridge on which the vnet epair of the jails are residing, is also setup with an IPv4 address (as described above), but member of a different network and does not share the same switch/network with the dedicated management port. This box's jails are acting and responding as expected. Thanks in advance, O. Hartmann igb0@pci0:4:0:0:class=0x02 card=0x00028086 chip=0x15338086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf790, size 1048576, enabled bar [1c] = type Memory, range 32, base 0xf7a0, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 5 messages, enabled Table in map 0x1c[0x0], PBA in map 0x1c[0x2000] cap 10[a0] = PCI-Express 2 endpoint max data 128(512) FLR NS max read 512 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 somenumber ecap 0017[1a0] = TPH Requester 1 m0@pci0:0:25:0: class=0x02 card=0x20528086 chip=0x153b8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I217-V' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf7d0, size 131072, enabled bar [14] =
rtadvctl -vv show : Segmentation fault
Hello, I'm running a small 14-STABLE (FreeBSD 14.2-STABLE #11 n270324-8d5d7e2ba3a6: Thu Feb 6 16:56:03 CET 2025 amd64) based router appliance, running rtadvd(8). When stoppimg/starting mpd5 several times, changing the IPv6 prefix, I can almost with a 100% certainty reproduce such an error calling rtadvctl: [...] root@gate:~ # rtadvctl -vv show igb0: flags= status= mtu 1500 DefaultLifetime: 30m MinAdvInterval/MaxAdvInterval: 3m20s/10m AdvLinkMTU: , Flags: , Preference: medium ReachableTime: 0s, RetransTimer: 0s, CurHopLimit: 64 AdvIfPrefixes: no Next RA send: Tue Feb 11 22:36:21 2025 Last RA send: Tue Feb 11 22:30:23 2025 Prefixes (1): Segmentation fault [...] The indication of such a rtadvd failure within our network is no prefix delegation any more, several IPv6 on the (client) hosts's NICs are marked "deprecated" or "detached", but none usable. Checking on the gateway with the command shown above results in a segmentation fault ... funny. To solve this, we have to restart rtadvd. -- A FreeBSD user pgp21vC4W8Nz7.pgp Description: OpenPGP digital signature
rtadvd(8) How to IPv6 tokenize interface identifier
Hello, Linux (especially OpenWRT we use) knows about a concept named "IPv6 tokenized interface identifier". The concept is self explanatory, a interface/router obtains a propagated prefix and the concept allows the explicit definition of the host portion. I haven't managed to accomplish such a behaviour using FreeBSD's rtadvd(8) daemon. I guess this task is subject of and performed through the rtadvd.conf(5) configuration file, but I haven't managed yet to accomplish such a task (to speak simple: I'd like to have a router of a subnet always at IPv6 Network PREFIX:0:0:0:1). The only config tag I can imagine is responsible for what I'd like to achive is the "addr" tag mentioned in rtadvd.conf(5), but whatever I fill this tag with - the desired effect is never achived (i.e addr="::0.0.0.1"). My "FreeBSD homebrewn" router has several networks, attached to vlan. Each interface is subject of an ULA prefix and an IPv6 prefix provided by our ISP. It is possible to pin the ULA toward the desired address, like addr="fd50:c450::1", but then the ISP provided prefix seems not to be set properly or is completely absent. Omitting "addr=" provides the interface with ULA prefix and ISP prefix - but obviously with the randomly generated 64bit host portion. Playing around with mutually suitable tags, like "pinfoflags", "raflags" or "rtflags" and having probed almost every possible combination (with or without some sense), it seems impossible to provide a) both ULA and ISP prefix pin the host portion to a desired 64bit address, like "PREFIX::1". I do not exclude that I'm possibly incapable of comprehension the manpage (the language is and the deeper semantics seem then to be hidden for me). So, if there is a clear expalanation how to achive the desired, please point me towards it (thanks in advance!). Linux has this feature since a while and I can not believe that FreeBSD lacks such a feature. Thank you very much in advance, O. Hartmann -- A FreeBSD user pgpt5rx0UPK1D.pgp Description: OpenPGP digital signature
Re: rtadvd(8) How to IPv6 tokenize interface identifier
Am Fri, 21 Feb 2025 10:44:12 + Bob Bishop schrieb: > Hi, > > > On 21 Feb 2025, at 06:52, A FreeBSD User wrote: > > > > Hello, > > > > Linux (especially OpenWRT we use) knows about a concept named "IPv6 > > tokenized interface > > identifier". The concept is self explanatory, a interface/router obtains a > > propagated > > prefix and the concept allows the explicit definition of the host portion. > > > > I haven't managed to accomplish such a behaviour using FreeBSD's rtadvd(8) > > daemon. I guess > > this task is subject of and performed through the rtadvd.conf(5) > > configuration file, but I > > haven't managed yet to accomplish such a task (to speak simple: I'd like to > > have a router > > of a subnet always at IPv6 Network PREFIX:0:0:0:1). > > Isn’t sufficient just to give the router a static IPv6 address? That’s what > we do here. Hello. The router itself has on all inbound NICs static ULAs, ending as desired on "fc:/7-PREFIX::1". Using KAME dhcp6c, software from 2008(!), with a configuration obatined for delegating a prefix, each NIC - except tun0 for whatever reason - gets a prefix, the inbound NICs then seem to get a EUI64 generated IPv6 (although I sepcified "privacy", but this seems to be ignored, sadly ...). > > > The only config tag I can imagine is responsible for what I'd like to > > achive is the "addr" > > tag mentioned in rtadvd.conf(5), but whatever I fill this tag with - the > > desired effect is > > never achived (i.e addr="::0.0.0.1"). My "FreeBSD homebrewn" router has > > several networks, > > attached to vlan. Each interface is subject of an ULA prefix and an IPv6 > > prefix provided > > by our ISP. It is possible to pin the ULA toward the desired address, like > > addr="fd50:c450::1", but then the ISP provided prefix seems not to be set > > properly or is > > completely absent. Omitting "addr=" provides the interface with ULA prefix > > and ISP prefix > > - but obviously with the randomly generated 64bit host portion. > > > > Playing around with mutually suitable tags, like "pinfoflags", "raflags" or > > "rtflags" and > > having probed almost every possible combination (with or without some > > sense), it seems > > impossible to provide a) both ULA and ISP prefix pin the host portion to a > > desired 64bit > > address, like "PREFIX::1". > > > > I do not exclude that I'm possibly incapable of comprehension the manpage > > (the language is > > and the deeper semantics seem then to be hidden for me). So, if there is a > > clear > > expalanation how to achive the desired, please point me towards it (thanks > > in advance!). > > > > Linux has this feature since a while and I can not believe that FreeBSD > > lacks such a > > feature. > > > > Thank you very much in advance, > > > > O. Hartmann > > > > > > -- > > > > A FreeBSD user > > -- > Bob Bishop > r...@gid.co.uk > > > > -- A FreeBSD user pgpqAZSzm8XRS.pgp Description: OpenPGP digital signature
mpd5: How to prevent tun0 getting multiple valid IPv6 addresses?
Hello, Router/Firewall host is running FreeBSD 14-STABLE: FreeBSD 14.2-STABLE #20 n270632-859aa726fb86: Fri Feb 28 19:38:05 CET 2025 I'm using mpd5(8) to connect to our ISP via vDSL. Utilizing an appropriate "link-up.sh" script, which effectively does - restart rtsol on tun0 (rtsol tun0 &) - restart dhcp6c (service dhcp6 restrt) - doing some logging - performing some DDNS adjustments with the appropriate provider mpd5 is configured to obtain IPv4 and IPv6 via ipcp, ipv6cp. While IPv4 has never been a problem, it seems that IPv6 is stuck with SLAAC (I never managed to obtain an IPv6 via DHCP (dhcp6c(8) from ports), always EUI64, privacy mode set). Restarting mpd5 provides only ONE valid IPv6 address on tun0. When ISP is resetting the address assignment usually after 24 hours for both IPv4 and IPv6, I end up very often having at least two or even more, still valid IPv6 addresses (meaning: none of the former assigned IPv6 addresses is marked deprecated or invalid). This renders DDNS useless, since I have no plan how to figure out the valid address. This problem occured recently, I do not know what causes it, I guess it came with a recent STABLE upgrade. How can mpd5 be forced to deprecate an address before obtaining a new one? How to finde out which of the assigned IPv6 addresses is the "old" one and mark it deprecated? I run a simple script searching for "tentative, deprecate and so on" addresses to leave the good one(s) when providing my DDNS provider with the mutually correct IPv6 address of mine. Utilising link-down.sh of mpd5(8) seems a good place to eradicate IPv6 addresses (by filtering out fe80:: or mutually assigned ULA, leaving the valid IPv6 for deletion), but this seems non-conformal to me. A bug or a "feature"? Thanks in advance, Oliver -- A FreeBSD user pgprWZQPei12n.pgp Description: OpenPGP digital signature
mpd5: tun0 always get IPv6 address via SLAAC although not configured
Hello,
I'm playing around with a useful setup of a small router/firewall appliance
based on FreeBSD
14-STABLE and ipfw.
My/our ISP provides (alleged) ::/56 prefixes. The hardware used has several
Intel i210 based
NICs, on of them is facing towards the ISP as usual with a cloned pseudo device
called "tun0"
(in fact a renamed ng0 device).
The ISP is changing both IPv4 and IPv6 addresses after a 24h period!
Obtaining a ::/56 prefix and delegating the proper network prefixes to their
NICs works with
port net/dhcp6 and FreeBSD's board tool rtadvd(8). The setup is textbook like
and straight
forward.
All inward facing NICs do have the same prefix, a individual 8-bit network
portion and a
(sadly not further controllable) 64bit SLAAC host address.
Problem: I never managed to obtain the ::/56 prefix on tun0! When using "rtsol
-i tun0" within
the link-up.sh script of mpd5, the ISP facing tun0 interface _always_ is
configured via SLAAC
(DHCPv6 on tun0 seems not to work in my case) and its prefix is ALWAYS
different fron that
obtained later via net/dhcp6 and delegated via rtadvd. This causes some trouble
identifying my
router for ssh access from the outside world utilizing DDNS.
Well, some internet HowTo's suggest not to provide tun0/ISP facing NIC with any
address
(except IPv4 address, which is done by default via mpd5). So I declared one of
the inner NICs
as the interface for remote access. But there seems an oddity:
no matter what I configure for mpd5, tun0 ALWAYS obtains a SLAAC IPv6 and after
several days
there are several valid (temporary) IPv6 addresses, none of them is marked
"detached" or
"deprecated".
How to make mpd5 to suppress obtaining any IPv6 address?
And: why isn't the IPv6 address deprecated?
In my first attempts configuring the tun0 interface, I used rtsol(8) for
obtaining an IPv6
address which worked very quickly (and provided this address to my DDNS
provider). In roughly 6
out of 10 cases the old IPv6 address is marked deprecated/detached. But in 4
out of 10 cases,
the outward facing tun0 has at least two valid adresses of which one is not
valid anymore from
the perspective of my ISP!
mpd5's link-up script is simply configuring tun0 with:
/sbin/ifconfig ${wan_if} inet6 auto_linklocal -ifdisabled accept_rtadv
-no_radr up
(and if desired having SLAAC IPv6 addr on tun0:
/sbin/rtsol ${wan_if} &
but this is ommited right now).
lin-down.sh does nothing.
Why is deprecating former addresses not working in all cases? Is it a feature
that tun0
magically obtains an IPv6 address via SLAAC on mpd5? How to suppress SLAAC on
mpd5?
Sorry for possible confusions, I'm new to IPv6 and would appreciate any hints
and tipps.
Kind regards and thanks in advance,
Oliver
--
A FreeBSD user
pgpmjsubu_tZ6.pgp
Description: OpenPGP digital signature
rtadvd: rtadvctl -vv show : Segmentation fault - after lots of Link up and downs (ISP)
Hello, when there are often changes of the IPv6 prefix and rtadvd is running, the command rtadvctl -vv show quits with a "Segmentation fault error" after the first vlan interface shown, not showing any subsequent vlan NIC. Prefix delegation is corrupted and so the IPv6 network behind the router. I have to restart rtadvd to mitigate this problem. I run an PCengine APU2 with three physical NICs, the interior NIC has up to 10 vlan configured. The problem can easily be reproduced by restarting mpd5 several times (I was configuring and coding a link-up script and had to restart mpd5 2-3 times a minute over an hour or so). Without the restart of rtadvd, the service remains dead and inoperative. The APU2 is running FreeBSD 14-STABLE: FreeBSD 14.2-STABLE #23 n270736-94f414086075: Tue Mar 11 20:52:07 CET 2025 Kind regards, oh -- A FreeBSD user pgpwOMnVYuHY2.pgp Description: OpenPGP digital signature
