freifunk / icvpn-meta Goto Github PK

Following network is announced by herne even when the network was not delegated by ruhrgebiet to it.

• 10.162.0.0/16 ASN 64880

@fragstone, @DaCHRIS

The networks are set in ICVPN to 65529. But instead 4242420022 is used for them this currently breaks ROA checks on other BGP peers. icvpn's mkroa uses the data from icvpn-meta to generate this table. The icvpn-meta information must therefore be in sync with ASN used for the announcements.

• 10.26.48.0/20 ASN 4242420022
• 10.26.64.0/18 ASN 4242420022
• fdef:17a0:ffb1:ffff::/64 ASN 4242420022

Maybe this could be used as an example for find a workaround for other communities like

• 10.31.0.0/24 ASN 4242421279
• fda1:384a:74de::/48 ASN 4242423214

The roa tables generated by icvpn's mkroa (using icvpn-meta) currently set the max prefix length to 24. But there are communities which are announcing more specific networks.

celle @ffce

• 10.252.63.192/26 ASN 64861

gera-greiz @joerg-d

• 10.181.0.11/32 ASN 65181
• 10.181.0.12/32 ASN 65181

This has to be fixed either by the communities or by the way the tables are generated

Is there an easy way to extract all given IPs from this repository?

I would just pick any new IP and search for this IP in this repositroy and hope it is free? but that seems a bit rude

for example 10.88 seems to be free, but it seems to be taken by Frankfurt Großenried aloready???

Just noticed that one of the FFV servers (vogtland3) had a full HDD and the reason for that was a rather big daemon.log. The "culprit" was bird which logged a lot of connection requests from unknown peers. Unfortunately, the log on this server cannot be used anymore - but I've checked on vogtland1 and vogtland4 for the same error messages via

sudo grep 'Unexpected connect from unknown address' /var/log/daemon.log|sed -e 's/.*Unexpected connect from unknown address//' -e 's/port.*$//'|sort|uniq -c |sort -n

I found following IPs:

• misconfigured servers?
  • tuttlingen @kpanic23
    • 10.119.0.8
  • ulm @kerlerm
    • 10.33.80.1
  • franken @RedDog99
    • 10.83.252.14
    • fec0::a:cf:0:17 (why was it removed in 3c89032?)
• unknown and most likely unrelated to icvpn
  • 198.20.87.98
  • 45.55.21.184
  • 71.6.135.131
  • 80.82.77.139
  • 80.82.77.33
• entries which were disabled during the "Grossreinemachen" #507 @kpanic23
  • hamburg @7adietri
    • 10.207.0.61
    • fec0::a:cf:0:3d
  • nord @rubo77 @Tarnatos
    • fec0::a:cf:b:c

The first two points are not actually a problem of icvpn-meta. But the last point is the interesting part. Should these be re-added or should there certificate be removed from the icvpn tinc keys repository? And should fec0::a:cf:0:17 be re-added for franken?

Moin moin,

ich finde das eigentlich nicht so richtig prall, dass die Zuteilung IP-Netz / ASN nun hier über das Repo erfolgen soll, aber man kann sich dem nicht entziehen.

Als ich nun unsere Community Netze anlegen wollte, (zu denen mir gesagt wurde ich müsste diese einzeln anlegen, da jede Community eine eigene ASN hat und mehrere ASN pro File nicht zulässig sind) rannte die Prüfung direkt auf nen Hammer, da es anscheinend ebenfalls nicht zulässig ist mehrere ASN in unterschiedlichen Files über das selbe Gateway zu routen.

Was nun?

Sieh PR #101 #102

10.31/16 ist eigentlich für Berlin reserviert.
@mmunz hat das jetzt für Hameln nochmal registriert:

openwrt/luci@69ecfff

Es wäre schön, wenn nicht das ganze 10.0.0.0/8er Netz für "öffentliche" Freifunk-IPs genutzt würde, sondern wenn ein kleiner Teilbereich (z.B. /12) für private LAN genutzt werden könnte ohne einen Adresskonflikt zu provozieren.

Facts:

• vfnnrw used the domain first
• but not in icvpn; never assigned nameservers for it
• current state of affairs is that ffwk resolves via icvpn to westkueste

Please resolve this collision as soon as possible.

westkueste:

efd34682 (olliff 2015-05-15 07:39:15 +0200 13) domains:
efd34682 (olliff 2015-05-15 07:39:15 +0200 14)   - ffwk
efd34682 (olliff 2015-05-15 07:39:15 +0200 15) nameservers:
c3d590ca (olliff 2015-05-17 16:46:54 +0200 16)   - 10.13.1.1
efd34682 (olliff 2015-05-15 07:39:15 +0200 17)   - fd23:dead:beef::ff01

vfnnrw

eb3c3ad6 wermelskirchen (Jan-Philipp Litza 2014-09-01 12:42:05 +0200 45) domains:
eb3c3ad6 wermelskirchen (Jan-Philipp Litza 2014-09-01 12:42:05 +0200 46)   - ffwk
cfae1a85 vfnnrw         (xlizard           2014-12-23 12:43:59 +0100 47)   - ffgro
eb3c3ad6 wermelskirchen (Jan-Philipp Litza 2014-09-01 12:42:05 +0200 48) # FIXME: Nameserver eintragen

rhein-neckar is currently using nazco's ASN 76118.
I guess this should be either corrected in the meta file or on their peer.

Hamburg (10.207.0.63) currently anounces out network 10.83.15.0/24. Please stop announcing our network, because it breaks the routing.
@kpanic23 @ohrensessel

Hi,

kiel3 is a v6-only gw according to http://wiki.freifunk.net/IC-VPN, but icvpn-meta/kiel lists the v4 address (10.207.0.59) of bielefeld1.

regards,
ralf

There are AS numbers larger then 16 bit registered:

• luebeck:asn: 201173
• rhein-neckar:asn: 76118

Where are we going with this? The check currently breaks only because of this, so do we want to enforce this at some point or loosen the check?

Opinions welcome!

Neonetwork is implementing dnssec for the neo. tld and both of the reverse zones. As a result, we would like to publish our DNSKEYs inside icpvn-meta so that other members may have access to them.
Any help is appreciated.

Following networks are announced by ennepe-ruhr-kreis even when they were not delegated by ruhrgebiet to it.

• 10.20.128.0/19 ASN 65400
• 10.20.160.0/19 ASN 65400
• 10.20.192.0/19 ASN 65400
• 10.20.32.0/19 ASN 65400
• 10.20.64.0/19 ASN 65400
• 10.20.96.0/19 ASN 65400

@fragstone, @DaCHRIS

This is most likely an old server still announcing this stuff with the wrong ASN. At least this one was used before 3a4a9b2 ("Update rhein-neckar (#475)")

• 10.142.0.0/16 ASN 76118
• 10.142.104.0/22 ASN 76118

This currently breaks the ROA checks on other BGP peers because icvpn's mkroa generates them from icvpn-meta

@nazco, @Nurtic-Vibe

The last commit 763c74e for neonetwork breaks the mkdns script from icvpn-scripts.

Traceback (most recent call last):
  File "/home/admin/clones/icvpn-scripts/mkdns", line 190, in <module>
    [filters[options.filter]] if options.filter else [])
  File "/home/admin/clones/icvpn-scripts/mkdns", line 138, in create_config
    formatter.add_data(domains, servers)
  File "/home/admin/clones/icvpn-scripts/mkdns", line 28, in add_data
    """ % (domain, "; ".join(servers))).lstrip())
TypeError: sequence item 1: expected str instance, dict found

It looks like the script does not like IPv6 addresses with :: at the end.
Changing fd10:127:ffff:53:: to fd10:127:ffff:53::0 seems to fix it.

@RedDog99, @mayosemmel

I am currently seeing ROA check errors in my bird logs on vogtland1:

ROA check failed for 10.50.60.0/22 ASN 4242420205

It seems like either some delegation is missing (see #522) or some dn42 user announces a conflicting range. Please investigate

For example Who is Frankfurt Großenried? The Wiki sais it is there with the IP-Range 10.88.0.0: https://wiki.freifunk.net/IP-Netze :

10.88.0.0/16                Freifunk Großenried - linon 

But ti is not found in this icvpn-meta repository.

since 27. April 2015 there is a hint :

TODO: Die hier aufgeführten Netze müssen geprüft und anschließend in das icvpn-meta Repository übertragen werden.

How can we help to check these communities?
How where these added those to the Wiki?