[swinog] Re: swinog Digest, Vol 219, Issue 11
as of my knowledge, SS7 is the remedy for inband signalling what was abused widely. nevertheless, SS7 is widely known to be vulnerable and nearly 50 years old. since the global telephony system is impossible to get migrated to anything more clever and better shortly, limiting access to well behaving entities is (IMHO) a good approach. network operators HAVE limited access to SS7 for the end user already long ago - I remember it was possible to do nasty things in the early ISDN days sending spoofed messages through the d-Kanal even for end users. this was quickly addressed. the current incident is about someone with deep knowledge to SS7 and it's sensitive spots. that guy provided access to SS7 to (any?) parties as a payed service and (it would not surprise me) consulting about how to exploit it. you won't provide razor blades to toddlers for a good reason - but you can't demand to make razor blades safe for toddlers. ;-) for my understanding, he should have take measures to prevent abusing his service by his customers. since (some) of his customers only used his service for exploiting and he got paid for providing it, he did not seem to 'have a word' with that exploiting customers, instead money was more important. There are (really) a lot of infrastructure services that rely on old insecure technology - just think of tracking 'Santa Claus' on flight radar. this is funny - but in the end just sending spoofed data to ACARS. some infrastructure implementations are too big to allow exploits - and to old and widely spread to make changes. SS7 does (as of my knowledge) not have any security features. limiting access is mandatory. If I'm technically wrong about SS7 and other options I would gladly learn about alternatives. Schönes WE ;-) Ralph - Am 19. Mai 2023 um 22:42 schrieb f_sfetea--- via swinog swinog@lists.swinog.ch: > Hmm, instead of securing their networks and pushing for better security > standards they'll cut access to one fish. Is that an ideal strategy? Some > other > bigger meaner fish will still use those vulnerabilities. > I was wondering if the GSMA is or should regularly perform security audits. > > https://www.gsma.com/security/gsma-mobile-security-research-acknowledgements/ > > Or perhaps award publicly visible badges of honor to those mobile networks > that > are not vulnerable to similar attacks. > > I mean how many companies do we know? that publicly stated: Hello our mobile > users btw. we fixed those vulnerabilities in our network! You should now be > better protected. > > I never got any such information from any of my providers. Did you? > > Beste Grüsse, Regards si s-auzim de bine > Florin Sfetea > > > Today's Topics: > > 1. Re: Sicherheit von SS7 - mit Schweiz-Bezug (Ralph Krämer) ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] Re: Sicherheit von SS7 - mit Schweiz-Bezug
nice : https://www.spiegel.de/netzwelt/netzpolitik/andreas-fink-mobilfunkverband-geht-gegen-schweizer-ss7-dienstleister-vor-a-d012c1dd-afb7-4ead-9571-59653abc17e1?sara_ref=re-xx-cp-sh about time ;-) - Am 15. Mai 2023 um 13:31 schrieb Florin Sfetea via swinog swinog@lists.swinog.ch: > Hello all, > > I was reading this old(2018) ENISA Report [ > https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7-diameter-5g/@@download/fullReport > | > https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7-diameter-5g/@@download/fullReport > ] > Might help in some way but reading it had reminded me of ARP > spoofing/poisoning > attacks which even today are still used and work in a lot of networks that I > have been. :) > > One year later I had open a case with Salt where I requested a public > statement > that they had fixed/mediated the issues discovered up to that time(March 2019) > or at least that a remediation plan was in place. > > Someone from Support answered that " The introduction of 5G will only take > place > if data security is guaranteed for our customers and we can assume that the > security issue will not lead to a delay in the introduction of 5G. " > > I was not satisfied ::)) with the answer and requested an escalation > > They eventually closed my case in July 2019 with: > > " Dear Sir, > > > Salt follows industry best practices in terms of security for its entire > mobile > infrastructures and improves constantly the protection of its mobile > infrastructures and customers. The case you mention is known and has been > addressed accordingly. > " > No public statement nor such other mentions of which fix was exactly > addressed. > > I don't have anything with any mobile provider. At that time it was just > happen > to be Salt. I move from time to time to different other ones. > > I think we should have here in Switzerland more or less a same similar to > ENISA > organization that should supervise and perform regular audits on mobile > providers. Melani/NCSC would that fit your bill? > > I never really had time to further test if any of those vulnerabilities or > newer > where actually fixed. Someone should definitely do it. Free for fame or payed > from a government branch is to > [ > https://www.gsma.com/security/gsma-mobile-security-research-acknowledgements/ > | > https://www.gsma.com/security/gsma-mobile-security-research-acknowledgements/ > ] > > > Regards, > Florin > > ___ > swinog mailing list -- swinog@lists.swinog.ch > To unsubscribe send an email to swinog-le...@lists.swinog.ch ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] Re: switch started blocking whois queries?
Hi Benoît, the whois-service is a hierarchical service like DNS. It starts at IANA and IANA delegates responsibility for ccTLDs towards the country's NIC. In respect to this, the 'official' entry point for .ch queries is the whois service on whois.nic.ch. Switch itself is only the reseller for .ch domains, therefor the switch.ch whois service redirects everything switch.ch is not responsible for to the ccTLD's whois service what is whois.nic.ch. see ==> https://www.iana.org/whois?q=imp.ch I'm aware that switch.ch and nic.ch are often considered to be like the same because a while ago, switch.ch has been the only registration service to register domains within the .ch ccTLD. Today, the resellers of ccTLD domains need to have a valid contract with the authority where a specific ccTLD has been assigned to by IANA to register a ccTLD domain. Depending on the contract, smaller resellers tend to use the ccTLD's 'official' whois service where bigger resellers run their own whois servers and the ccTLD's authoritative whois service delegates there. Because it became a common misbehavior to collect (privacy sensitive) information by abusing whois to collect data for datamining, a lot of whois services restrict the number of queries coming from 'unidentified' clients to some few queries within a time frame - or, if the specific whois server is not authoritative for answering the query, does not answer at all but redirects to IANA's whois and from there to the ccTLDs whois service (what might then point you to the registrars whois service). Switch is likely answering your query on IPv4 for legacy reasons because the IPv4 address your query originates from is known as privileged from the time Switch has been the official authoritative registry for .ch and also IPv4 address space. Your IPv6 address seem to be not considered to be 'privileged' and you are redirected to whois.nic.ch. Compare it to 'recursion' in DNS - some IPs are allowed for recursion and for all else, queries for DNS names where the DNS server that is queried is not authoritative, you'll get thrown back to the root servers. imp.ch is not registered with Switch, but inic.ch and whois.switch.ch is not authoritative to answer the query. whois.switch.ch answers 'on behalf' (like DNS recursion) for your IPv4 address, but not for the IPv6 address since the IPv6 address was assigned to you after authority for .ch ccTLD was moved to nic.ch and your IPv6 address is not on Switch's privileged list to allow recursion ;-) kind regards Ralph - Am 17. Okt 2022 um 15:43 schrieb Benoit Panizzon benoit.paniz...@imp.ch: > Weird, switch only seems to support legacy ip. > > whois.nic.ch has address 130.59.31.241 > whois.nic.ch has IPv6 address 2001:620:0:ff::b > > $ whois -h 130.59.31.241 imp.ch > This information is subject to an Acceptable Use Policy. > See https://www.nic.ch/terms/aup/ > > Domain name: > imp.ch > [...] > > $ whois -h 2001:620:0:ff::b imp.ch > Requests of this client are not permitted. Please use > https://www.nic.ch/whois/ > for queries. > > Mit freundlichen Grüssen > > -Benoît Panizzon- > -- > I m p r o W a r e A G-Leiter Commerce Kunden > __ > > Zurlindenstrasse 29 Tel +41 61 826 93 00 > CH-4133 PrattelnFax +41 61 826 93 01 > Schweiz Web http://www.imp.ch > __ > ___ > swinog mailing list -- swinog@lists.swinog.ch > To unsubscribe send an email to swinog-le...@lists.swinog.ch ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] Re: Contact: geoiplookup.net
Hi Benoit, just my 5 cents ... It's not the customer's responsibility to cover issues of their TSP using an unreliable source of geoIP information. The TSP would be able to whitelist exceptions to cover the gap between their unreliable data source and reality until their geoIP source has corrected their data. If it's a business customer, they will have a SLA with the TSP and since it's the fault of the TSP there is no question who is violating SLAs. I'm pretty sure RIR's would allow MaxMind to query the original source of data, either for the IP or for the AS announcing the prefix to bgp. But RIR's will charge a service fee for that - what is legit from my perspective. If MaxMind spares this fee and delivers a shitty service then, the TSP should consider to switch to a more reliable source of data - it's them who is violating SLAs with their customers. ;-) cheers Ralph - Am 13. Okt 2022 um 8:46 schrieb Benoit Panizzon benoit.paniz...@imp.ch: > Short update on that issue... > >> Does anyone know who operates geoiplookup.net and how to contact them? > > It looks like they source their Data from MaxMind but are solver > implementing corrections and therefore lacking behind corrections > published there. > > The issue we have is not with content, but with services. > > There is one SIP telephone service provider which fences his customers > to Swiss IP addresses only and provides services to businesses. > > So if the static routed IP addresses of the business customer is locate > outside Switzerland, this is an effective denial of service to the > telephony of that customer. > > This happens for the 3rd time within only a couple of weeks to the > same customer of us now. > > The TSP in question blames us for assigning foreign ip addresses to the > customer in question and recommends the customer should get a new > Swiss ip range from us. This of course is not feasible, as this would > require lots of changes on the customer side. > > Customer in question has an own transparent RIPE entry with country: ch > since 2016! > The range in question was never (since 2003, ripe does not provide > prior data) assigned to an ISP or customer outside Switzerland. > > What I am trying to do now, is set up an ISP bulk location feed to > MaxMind and trying to persuade them to put a lock on our ip ranges > so only we can provide locations for those and noone else. (Has anyone > done this successfully?) > > I am also pressing them to disclose how the same ip ranges now > repeatedly got put back to Germany shortly after we successfully > submitted corrections. > > But all I get now is: > > * Please use the online correction form. > > * Thank you for submitting the correction, which we will push in our > next update. > > Still waiting for a human reaction related to that specific issue. > > Mit freundlichen Grüssen > > -Benoît Panizzon- > -- > I m p r o W a r e A G-Leiter Commerce Kunden > __ > > Zurlindenstrasse 29 Tel +41 61 826 93 00 > CH-4133 PrattelnFax +41 61 826 93 01 > Schweiz Web http://www.imp.ch > __ > ___ > swinog mailing list -- swinog@lists.swinog.ch > To unsubscribe send an email to swinog-le...@lists.swinog.ch ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
Re: [swinog] Survey : which console/terminal servers are you using for Out-of-band mgmt ?
I'd strongly recommend to also have a serial console server around for oob. Best pick in my opinion is the avocent/cyclades series. They come in various variants with different amounts of serial ports. connection is RJ45 (use the normal patch infrastructure (within lengths limits) with a specific wired adapter for the device to manage. IPMI, iLO and all these others help you well if it's a server - but with dead switches, routers, appliances, ... it's wise to have serial console access over ssh to the terminalserver. and - just keep the "segregation of duty" in mind... in large installations, server operators are mostly not happy providing accounts to use a serial port on their server. A dead switch is out of interest for a windoze admin - they just want you to keep the SLAs. Sad - but mostly true. OOB depends... size of the team, devices to care of, ... for smaller setups I fully agree to Jeroen's suggestions. cheers, stay away from Delta and don't breed Epsilon ;-) Ralph - Am 29. Jul 2021 um 16:30 schrieb Jeroen Massar jer...@massar.ch: > Of course OOB, depending on location and requirements various options: > > - IPMI built-in to many hosts (SuperMicro >X10 have Redfish and thus HTML5 > KVM) > then you can always fix that host and continue from there if serial connected > etc. > - PCEngines APU ( [ https://pcengines.ch/apu2.htm | > https://pcengines.ch/apu2.htm ] ) > connected over serial and/or ethernet for a nice management entry > (APU6 with SPF [ https://ipng.ch/s/articles/2021/07/19/pcengines-apu6.html | > https://ipng.ch/s/articles/2021/07/19/pcengines-apu6.html ] is coming!) > - Michael Stapelberg's FreeTServ: [ https://freetserv.github.io/ | > https://freetserv.github.io ] > for serial lines > - "the other host in the same rack" with ethernet + serial cross-connected > > Do note that OOB is only fully OOB if you can mess up prod completely and > still > reach your OOB devices, that means if a switch is involved in your IPMI setup, > it should not be the main switch, but a separate one (so that one can kill the > main one, and use the OOB to fix it again). That also means that you need > separate connectivity (borrow an IP from a friendly ISP in the same rack) or > use 4G/5G if available in the DC. > > If using 4G, remember that one can do a wireguard mesh OOB to a non-own VM > somewhere for OOB too. Ensure that you have ACLs and static IPs to connect > from > them too. Tor is also a fine option for low-bandwidth access in more hostile > networks, then people need to know the onion fingerprint to get to your SSH. > > > In DCs you will also find opengear or airconsoles btw. > > As noted, depends on requirements, budget and many more things. > > Greets, > Jeroen > > > > > On 20210729, at 15:29, Félix Curinga < [ mailto:fe...@curinga.ch | > fe...@curinga.ch ] > wrote: > > Hi all, > > I am starting a small project with a student of the Technical School in > Lausanne > ETML-ES (for his diplom work), it will end up as a mobile kit for remote > staging. > I would like to collect some experience from you folks, will be kept 100% > anonymous. > If you agree, can you drop me an email directly and answer these questions: > > - do you have Out-of-Band console management for your network equipment ? > - if no : how do you manage your network equipment ? > - if yes: which product (brand/model) ? > - if yes: which interfaces on the equipment side ? (RJ45, USB, etc..) > > Thanks in advance. > For the people providing answers: I will send you the survey result without > company or people's names. > > Best regards > --félix > > -- > Félix Curinga > +41 79 446 38 11 > > > > ___ > swinog mailing list > [ mailto:swinog@lists.swinog.ch | swinog@lists.swinog.ch ] > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Coop.ch geoblocking?
all, from what I saw within the last years, more and more companies us cloud based proxy services (like e.g. McAfee Cloud proxies). Since these proxies are sometimes misused to produce nonsense (do evil things) on the internet through these proxies, site admins block IPs belonging to that individual proxy - leaving he other IPs belonging to the local (country assigned)cluster's proxies alone, some of the nodes work for certain sites and some not ... - Am 3. Mrz 2021 um 22:04 schrieb Roger ro...@mgz.ch: > yeah .. blocking connection from an proxy, i step more and more in such > crazy sites, mostly i close the session and forgett about it > > there are a lot of reason to use a Proxy, i think this is a similar > paranoia based behaviour as filtering ICMP echo or worse ICMP at all. > i think its just die idea to keep other Admin busy with investigate why > the users are not able to open the Page, other explanation i dont have. > i will be shure they would even call telnet to www.blick.ch 80 as evil > and insecure :D, because Telnet is insecure, they read on PC Bild :D > > Roger > > On 03.03.2021 10:44, Benoît Panizzon wrote: >> Follow up on this. >> >> They use this service: >> https://www.brightcloud.com/tools/url-ip-lookup.php >> >> Which list the affected IP in 'high risk' category 'proxy'. >> >> I opened a case with them to find out the cause. >> >> They delistet 157.161.57.65 but not 157.161.57.70. Maybe I should >> change the PTR of the later one :-). That only was an exit for very >> short time (immediate abuse complaints). >> >> Also 'Tor' is a separate category. So if my experiments with Tor >> triggered that issue, why didn't they list it as 'Tor' which they have >> as a category. >> >> Another cause might be, that I use a transparent proxy to cache some >> content in my LAN. But that only is accessible from my LAN, but of >> course this might inject HTTP header indicating the proxy connection. >> >> Also L2TP and PPTP is accessible, so I can access my private ipv4 space >> from outside. So did they scan for those services and flag it as >> 'proxy'? >> >> I'm looking forward for their reply. >> > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Spam from 'Rocketmails.ch'
just my 5cts... would it break something if those who are spamed from them simply cut them off by nullrouting 185.176.152.0/22 ? a static route to localhost on the receiving MX would do the trick. That ISP is obviously hosting SPAMers and I wouldn't expect to have useful communication to/from that prefix... 8-) - Am 15. Okt 2020 um 21:21 schrieb Marc SCHAEFER schae...@alphanet.ch: > On Thu, Oct 15, 2020 at 08:54:32PM +0200, Peter Rohrer wrote: >> I sent him registered letters to both his "Sandro Achilles Photography >> Corporation" (in 2019) and to "ACHILLES ??? Management & Marketing >> Consulting" (he received it about 2 Months ago) and did not get any >> response so far. I also called his phone number, he claimed someone >> else is handling those request for him. > > If you do not get any reply after one month, I think that then it should be > escalated to the proper authorities, as this looks a violation of Swiss law. > > So far everyone has replied in the legal delay. I sent normal mail (and then > registered mail when RocketMails played the `it's not us, it's > RocketMountain'). > > If someone knows more about the legal procedure to follow when there is no > reply, I would happily know about it. > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Announcement of 'china government' routes 125.208.4[567].0/24 forbidden?
Hi Benoit, from sunrise FTTH in Pfaeffikon/sz it looks "not too bad": $ traceroute 125.208.4.1 traceroute to 125.208.4.1 (125.208.4.1), 30 hops max, 60 byte packets 1 fritz.box (192.168.1.1) 0.647 ms 0.637 ms 0.715 ms 2 xdsl-31-165-201-1.adslplus.ch (31.165.201.1) 6.064 ms 5.898 ms 5.808 ms 3 oer02pe10.ge2-1-13.bb.sunrise.net (195.141.216.166) 6.476 ms rap31pe02.ge3-0-9.bb.sunrise.net (195.141.216.154) 5.718 ms 6.239 ms 4 * * * 5 zur01pe20.100ge-2-0-0.bb.sunrise.net (212.161.247.129) 5.636 ms 5.473 ms oer02pe20.100ge-2-0-0.bb.sunrise.net (212.161.247.133) 6.098 ms 6 et-0-0-17.bar1.Zurich3.Level3.net (213.242.67.149) 5.936 ms 2.198 ms 2.496 ms 7 ae-2-52.ear1.LosAngeles6.Level3.net (4.69.210.97) 154.041 ms 153.142 ms 153.365 ms 8 ffm-b1-link.telia.net (62.115.141.241) 18.508 ms CHINA-NETCO.ear1.LosAngeles6.Level3.net (4.26.2.166) 165.020 ms ffm-b1-link.telia.net (62.115.141.239) 18.399 ms 9 219.158.117.13 (219.158.117.13) 361.929 ms 361.874 ms 219.158.45.29 (219.158.45.29) 265.678 ms 10 219.158.3.133 (219.158.3.133) 368.084 ms 368.033 ms 360.478 ms 11 * 219.158.3.133 (219.158.3.133) 232.447 ms * 12 219.158.8.121 (219.158.8.121) 297.611 ms 286.350 ms * 13 219.158.7.225 (219.158.7.225) 299.828 ms 125.33.185.226 (125.33.185.226) 383.848 ms 124.65.194.22 (124.65.194.22) 246.454 ms 14 61.148.157.110 (61.148.157.110) 250.196 ms 124.65.194.78 (124.65.194.78) 289.955 ms 61.48.75.178 (61.48.75.178) 397.433 ms 15 61.148.157.110 (61.148.157.110) 302.523 ms * * 16 125.208.16.238 (125.208.16.238) 383.800 ms * * 17 125.208.16.218 (125.208.16.218) 243.419 ms 125.208.16.238 (125.208.16.238) 256.912 ms 257.021 ms 18 125.208.15.82 (125.208.15.82) 267.987 ms 125.208.4.1 (125.208.4.1) 387.041 ms 387.076 ms cheers Ralph - Am 27. Aug 2020 um 17:33 schrieb Benoit Panizzon benoit.paniz...@imp.ch: > Well, when I use the Sunrise LG: > > BGP routing table entry for 125.208.47.0/24, version 252176985 > Paths: (4 available, best #1, table default) > > Not advertised to any peer > ^-- see! > > 4134 24151 >193.192.254.35 from 193.192.254.35 (212.161.178.83) > Origin incomplete, metric 20, localpref 80, valid, internal, best > Community: 6730:6200 6730:6222 > 4134 24151 >193.192.254.34 from 193.192.254.34 (212.161.178.93) > Origin incomplete, metric 20, localpref 80, valid, internal > Community: 6730:6200 6730:6223 > 4134 24151 >212.161.178.83 from 212.161.174.11 (212.161.174.11) > Origin incomplete, metric 20, localpref 80, valid, internal > Community: 6730:6200 6730:6222 > Originator: 212.161.178.83, Cluster list: 0.0.3.120 > 4134 24151 >212.161.178.83 from 212.161.174.10 (212.161.174.10) > Origin incomplete, metric 20, localpref 80, valid, internal > Community: 6730:6200 6730:6222 > Originator: 212.161.178.83, Cluster list: 0.0.3.120 > > We don't get them! > > Mit freundlichen Grüssen > > -Benoît Panizzon- > -- > I m p r o W a r e A G-Leiter Commerce Kunden > __ > > Zurlindenstrasse 29 Tel +41 61 826 93 00 > CH-4133 PrattelnFax +41 61 826 93 01 > Schweiz Web http://www.imp.ch > __ > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Looking for a VoLTE-SIP gateway
I just checked ebay for BeroNet boxes and found that there is really a lot... maybe it is helpful to check with a cheap small box before going for the big one ;) - Am 14. Aug 2020 um 13:44 schrieb Jean-Pierre Schwickerath swi...@hilotec.net: > I've been using the Berofix boxes for about 10 years with various modules, > mostly BRI and FXS. I've one running with a GSM module for for voice calls. > Works like a charm. I've never used the SMS API though. > Hardware quality is perfect and as they are based in Berlin, Support is in the > same timezone and in German if ever need something. > > > On 14.08.20 12:19, Stanislav Sinyagin wrote: > > > > cool, thanks, this looks nice. I'll ask them for a quote. Do you have them in > operation? > > > > On Fri, Aug 14, 2020 at 10:28 AM Jean-Pierre Schwickerath < [ > mailto:swi...@hilotec.net | swi...@hilotec.net ] > wrote: > > > > Hi Stan > > You should take a look at the Beronet VoLTE SBC: [ > https://www.beronet.com/gateway/volte-sbc/ | > https://www.beronet.com/gateway/volte-sbc/ ] > > It does all you want, up to 6 SIM slots, SIP routing, SMS via REST-API and > there > is an "app marketplace" where you can install OpenVPN as client or server on > the box. > > Feel free to contact me if you need someone to import one :-) > > > Best Regards > > Jean-Pierre > > > On 12.08.20 09:43, Stanislav Sinyagin wrote: > > > > hi all, > > Swisscom will discontinue the old GSM service soon, so I'll need to replace an > old gateway. > > Any recommendation will be appreciated. I'm looking for a ready-made voice > gateway, as follows: > > * 4 or 5 SIM card slots > * support for VoLTE and UMTS (in Swiss frequency bands) > * Voice calls routed via SIP > * API for receiving SMS > * Nice to have: support for OpenVPN or some other VPN. > > > thanks, > stan > > > > > -- > Stanislav Sinyagin > Senior Consultant, CCIE #5478 > [ mailto:ssinya...@k-open.com | ssinya...@k-open.com ] > +41 79 407 0224 > > ___ > swinog mailing list [ mailto:swinog@lists.swinog.ch | swinog@lists.swinog.ch > ] [ > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog | > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ] > > > > -- > HILOTEC Engineering + Consulting AG - Langnau im Emmental > IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, > VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls > Tel: +41 34 408 01 00 - [ https://www.hilotec.com/ | https://www.hilotec.com/ > ] > > ___ > swinog mailing list > [ mailto:swinog@lists.swinog.ch | swinog@lists.swinog.ch ] > [ http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog | > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ] > > > -- > Stanislav Sinyagin > Senior Consultant, CCIE #5478 > [ mailto:ssinya...@k-open.com | ssinya...@k-open.com ] > +41 79 407 0224 > > ___ > swinog mailing list [ mailto:swinog@lists.swinog.ch | swinog@lists.swinog.ch > ] [ > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog | > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ] > > > > -- > HILOTEC Engineering + Consulting AG - Langnau im Emmental > IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, > VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls > Tel: +41 34 408 01 00 - [ https://www.hilotec.com/ | https://www.hilotec.com/ > ] > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Weird Bluewin Error: 'Unable to verify MX-Record for domain'
e.g. I do not accept delivery attempts where IP's in-addr.arpa record does not match the forward lookup of the returned hostname's for this IP AND does not match what the delivering MX claims to be regarding the helo info AND if SPF and/or DKIM matches. and ... yes, I still have mails successfully delivered ;-) I don't see why the receiver (with a compliant configuration) should weaken the proper configuration because senders do 'weird' things. Always fix at the root cause, don't go for workarounds :-) Ralph - Am 31. Mrz 2020 um 11:36 schrieb Jeroen Massar jer...@massar.ch: > On 2020-03-31 10:13, Andreas Fink wrote: >> your reverse DNS is not matching for 157.161.57.26 as it returns >> aleka.scout.ch. >> >> list.scout.ch. is not the same as aleka.scout.ch >> You could do instead >> >> >> list.scout.ch MX 50 aleka.scout.ch >> >> or >> >> list.scout.ch CNAME aleka.scout.ch. > > Please, please, please, for your own sanity: NEVER EVER point an MX to a > CNAME. > > > Sendmail, which some people still use (oh heck my inbound MX's are sendmail), > will mess up the domain that way and nicely replace it. > > Thus a mail to: someth...@lists.scout.ch would be replaced by sendmail with > someth...@aleka.scout.ch, which likely will not end up in the same place, and > will cause other expected. > > > > Also RFC refs why not to do it: > > https://tools.ietf.org/html/rfc1912#section-2.4 > 8< > Don't use CNAMEs in combination with RRs which point to other names like MX, > CNAME, PTR and NS. > ... > ->8 > > > http://tools.ietf.org/html/rfc2181#section-10.3 > > 8< > 10.3. MX and NS records > > The domain name used as the value of a NS resource record, or part of the > value > of a MX resource record must not be an alias. Not only is the specification > clear on this point, but using an alias in either of these positions neither > works as well as might be hoped, nor well fulfills the ambition that may have > led to this approach. This domain name must have as its value one or more > address records. Currently those will be A records, however in the future > other > record types giving addressing information may be acceptable. It can also have > other RRs, but never a CNAME RR. > ->8 > > and there are others that detail this problematic setup. > > > > In general actually: avoid CNAMEs where possible; just pre-process your > records. > > Greets, > Jeroen > > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] MELANI / GovCERT.ch
I would suggest to use recent information to file such a mail. For me it looks like the are relying on stale information collected a long time ago. whoever is hosting this stale information ... you simply could query the live DNS and the RIPE whois server ... I agree with Andreas ... they do not carry out professionality. - Am 18. Feb 2020 um 9:08 schrieb Silvan M. Gebhardt gebha...@openfactory.ch: > So what I suspect happened is this > > > On 2/18/20 1:51 AM, Andreas Fink wrote: >> 2. The single IP address in the report is not in my network (I used to >> have that IP range in the past but I sold it in 2016. So long long ago. ) > > it might still be registred to you via shadowservers.org OR another org > like this > >> 3. The abuse email they sent the report to is not in the whois of that >> network. > it might be becuase it shows it to belong to you via shadowservers.org > instead. >> 4. The DNS name used in the report is not the reverse PTR of that IP. >> Nor does the forward DNS point to that IP. >> 5. The DNS name points to a host in my network but that host is >> definitively not a IoT device which has any kind of default password. >> Its a solid Linux machine with a up to date distribution with 2 >> usernames only on it with very secure passwords and only one specific >> application running which doesn't talk to outside my network at all. >> If that machine would have gotten hacked, it would surprise me very >> much. At least I have found nothing unusual on that IP. No unexpected >> network activity, CPU load, processes etc. > > > it looks to me like there is something going wrong with > shadowservers.org and any other report like this. seems they just > forwarded it without fact checking, which, is kinda not their job either > (would swamp them massively I guess) > > > so yeah, guess you'd have to ask which source the report came from? > > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Telegram group
why telegram and not signal or threema? - Am 11. Feb 2020 um 17:46 schrieb Massimiliano Stucchi m...@stucchi.ch: > Hi everyone, > > I created a telegram group for Swinog. It is meant to be a place to > have discussions that are more informal than what you could have on the > mailing list or simply for something more interactive. > > The link to join is https://t.me/SWINOG > > I've created a similar group for ITNOG almost two years ago and it > proved to be a good initiative, now with about 450 members and with > daily discussion on different topics. Maybe we can make it happen also > for Swinog. > > Keep in mind this is just a personal initiative and not an official one > from Swinog. If it works out and it's positive, we'll see if we can > make it more official. > > If you have any question or comment, please feel free to approach me. > > Ciao! > -- > Massimiliano Stucchi > MS16801-RIPE > Twitter/Telegram: @stucchimax > > > > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Yahoo Mail Delivery Issues
Hi Dominic, what's wrong with that? global operating companies do that for a good reason. they use geoIP on your client address to figure out the nearest server for you and put it into the reply to your request. you will be able to connect with much less latency than connecting to another server on another continent sometimes dns is also used to achive some kind of loadbalancing - just to keep in mind ;-) cheers Ralph - Am 16. Sep 2019 um 15:51 schrieb Dominic Schlegel dominic.schle...@hostpoint.ch: > Hi All > > We are experiencing problems delivering mails for domains having their MX > record > set to mx-eu.mail.am0.yahoodns.net (for example yahoo.it, yahoo.de, > yahoo.co.uk). So far we have figured out that Yahoo’s DNS servers send > different responses. Depending on the DNS response we are able to establish > SMTP connections. Below example shows 2 servers from their DNS that seems to > accept SMTP connections: > > [root@x1:~] # dig a mx-eu.mail.am0.yahoodns.net @yf2.yahoo.com +short > 188.125.72.73 > 188.125.72.74 > > [root@x1:~] # telnet 188.125.72.73 25 > Trying 188.125.72.73... > Connected to mtaproxy1.free.mail.vip.ir2.yahoo.com. > > [root@x1:~] # telnet 188.125.72.74 25 > Trying 188.125.72.74... > Connected to mtaproxy2.free.mail.vip.ir2.yahoo.com. > > On the other hand we sometimes get other replies from the “same” (the > id.server > chaos record tell’s us it’s a different one) DNS server with different A > records that do not accept SMTP connections: > > [root@x1:~] # dig a mx-eu.mail.am0.yahoodns.net @yf2.yahoo.com +short > 188.125.73.87 > 212.82.101.46 > > [root@x1:~] # telnet 188.125.73.87 25 > Trying 188.125.73.87... > telnet: connect to address 188.125.73.87: Operation timed out > telnet: Unable to connect to remote host > > [root@x1:~] # telnet 212.82.101.46 25 > Trying 212.82.101.46... > telnet: connect to address 212.82.101.46: Operation timed out > telnet: Unable to connect to remote host > > > We have so far confirmed this behaviour from different AS (Hetzer, OVH). Does > anybody else experiencing the same behaviour? > > We have tried to contact their postmaster address and few others we found on > the > internet. Unfortunately so far no one was really able to help us. The Yahoo > Small Business Phone Number that has been posted on this list back in October > 2009 seems no longer to be in operations too. Therefore if you know how to get > in touch with their technical staff that would be much appreciated. > > > Best Regards > Dominic Schlegel > > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] PTR records with CNAME ?
Per, I just want to throw in the following: In case you want to subdelegate a part of a PTR zone, this seems to be the recommended way to do it: https://simpledns.com/kb/77/how-to-sub-delegate-a-reverse-zone jeroen, any comment on this? cheers Ralph - Am 30. Mai 2018 um 16:44 schrieb Per Jessen per.jes...@enidan.ch: > According to RFC1034 and 2181, a PTR record using a CNAME is not > permitted. I believe this to still be correct, postfix certainly > doesn't work with a CNAME when it does a reverse lookup. > > > Any comments? > > > thanks. > Per > > -- > Per Jessen, Zürich (28.6°C) > http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. > > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Hi Markus, it looks like Microsoft has configured their DNS zones in a creative way and I would expect them to come up with an RFC that justifies their creative way to "rape" DNS at a later time. For now, the way they have set it up looks unsupported to me and I doubt that they get any mails beside from servers using their own s*it that might be compatible to that approach. To get this solved, I would recommend to open a ticket with Microsoft and file a bug. Sorry, I've given up on debugging the outcome of DNS rapists ;-) cheers Ralph - Am 19. Feb 2018 um 13:46 schrieb Markus Wild swinog-l...@dudes.ch: > Hello Ralph > >> [TL;DR] ;-) > > sorry about that, but it's not about an MX to a CNAME, it's about the domain > part being resolved > directly via a CNAME (kind of like having a domain-level CNAME to another > domain, except _THAT_ isn't allowed > due to shadowing NS and SOA records). With something like > "accountprotection.microsoft.com" they're probably > not breaking that rule though. > > When you have time, I'd welcome an answer to my question ;) > > Cheers, > Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Hi Markus, [TL;DR] ;-) a MX record pointing to a CNAME is generally not supported and a bad idea. I am sure this is mentioned somewhere in one of the RFCs - but I currently have no time to look this up. A MX should always point to a A record. kind regards Ralph - Am 19. Feb 2018 um 8:57 schrieb Markus Wild swinog-l...@dudes.ch: > Hi there, > > I've just come across a weird mail reception problem of some mails from > Microsoft. Our servers insist that > a specified MAIL FROM address can be resolved correctly, and this usually > boils > down to the following checks > on the domain-part of the email-address specified: > - is there an MX? Does the target resolve using an A record (not a CNAME), and > does it resolve to a publically > reachable address (not RFC1918 or localhost etc) > - if there is no MX, is there an A record that fulfils the same criteria as > the > MX target above? > - if none of these are true, the address is considered to be invalid and mail > is > rejected > > Since about Feb 15, I've now come across mails from > account-security-nore...@accountprotection.microsoft.com that > get rejected. When I manually perform the above steps, I can see why, and I > also > see a first: the domain part is > actually a CNAME, something I've not encountered mentioned in standards as > being > a legal way to perform address > resolution when delivering email. But, I also don't recall reading about rules > that explicitly deny this, contrary > to the very explicit rules that for example deny having MX point to CNAME. The > domain setup here is borked in multiple > ways however: > > $ host -t mx accountprotection.microsoft.com > Host accountprotection.microsoft.com not found: 3(NXDOMAIN) > > $ host -t a accountprotection.microsoft.com > Host accountprotection.microsoft.com not found: 3(NXDOMAIN) > > BUT: > > $ host -t cname accountprotection.microsoft.com > accountprotection.microsoft.com is an alias for mail.msa.msidentity.com. > > and even if we should allow use of a CNAME here, we'd have to apply the same > rules as stated initially on the > CNAME target, and these fail as well: > > $ host -t mx mail.msa.msidentity.com. > Host mail.msa.msidentity.com not found: 3(NXDOMAIN) > > $ host -t a mail.msa.msidentity.com. > Host mail.msa.msidentity.com not found: 3(NXDOMAIN) > > So, what's your take on this? Does someone see a legal way to resolv this > sender, that I've missed? Am I right in > considering these addresses to be unresolvable and thus reject these mails? > Who > would I have to report this to at > Microsoft to have any chance of a human person looking at the issue? > > Cheers, > Markus > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Offtopic: Servers that companies throw out? :)
Hi Mihai, ... needless to mention that vendors often offer special trade-in prices for "old" equipment if a company is life-cycling their stuff. some of the equipment gets refurbished and sold through brokers, some gets shreded to salvage some gold and I strongly believe that most of the equipment that was initially in mid-europe and ran there for 3 to 5 years gets a second life in eastern europe, africa or south america ;-) br Ralph - Am 12. Sep 2016 um 18:15 schrieb Mihai Tanasescu mi...@duras.ro: > On 12/09/16 12:46, Per Jessen wrote: > >> Mihai Tanasescu wrote: >> >>> Hi guys, >>> >>> I am shooting an offtopic, wild question.. though I kind of guess what >>> the answers might be. Where are the big companies recycling / >>> throwing away their servers? >> In my experience, many servers are given to staff who subsequently sell >> them off on Ricardo. Many others are recycled by the supplier, maybe >> sold again as refurbished etc. > Seems to be quite a good business in this regard from what you're saying :) > I was always wondering where Swisscom/UPC/etc are throwing away their > stuff as they have quite a lot of equipments. >> >> >> > > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] inno.ch goes LIR
Hello Markus, asuming you are connectet to SwissIX (or will connet to), please have a look on the SwissIX Website, especially on the Link https://www.swissix.ch/infrastructure/available-carriers/ that list available carriers to peer with :-) br Ralph - Am 23. Jun 2015 um 8:29 schrieb Markus Meier swi...@inno.ch: Hello everybody We are just a small IT company and host some services. I recently decided to apply as LIR and to run our own AS with our own IPv6- and IPv4-Prefixes and last week it became true, almost :-) Now I try to get into the whole peering, BGP, IP transit business. I'm a complete newbie and had to find out that it's quite difficult to get in touch with the right people at possible ISP partners. If someone has time and joy to help us getting connected, any support is very much appreciated. We may pay in Beer/Mate, CHF/EUR/USD or good karma ;-) Greetings Markus Meier -- Innotronic Ingenieurbüro GmbH Informatik | Telekommunikation Lerzenstrasse 27, 8953 Dietikon, Switzerland Telefon +41 44 997 17 27 Web http://www.inno.ch/ ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Analysis of Email Domain protection for .ch
Hi, ja, aber prinzipiell ne doofe Idee ... viele MXe nehmen nur Mails von anderen MXen an - als SPAM Vermeidung. = nix MX-Record = nix Mail annehmen fG Ralph - Ursprüngliche Mail - Hi On Sun, 19 Apr 2015 10:45:53 + Bohren, Andres a.boh...@icewolf.ch wrote: http://blog.icewolf.ch/archive/2015/04/19/analysis-of-email-domain-protection-for-ch.aspx What do you think about it? »Bei rund 90% der .ch Domains wurden MX Einträge gefunden und können für Email benutzt werden.« Minor correction: domains without MX record can be used for email as well, an example is the sender domain of this email: henk.geekmail.org No MX, only an A record, but it still works, see https://tools.ietf.org/html/rfc5321#section-5 Apart from that it’s a nice little overview. Thanks for sharing! Best regards henk -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] PI address space needed [Solved]
the /22 will be PA - just in case you did not know ;-) - Ursprüngliche Mail - Hi as always asking for help on Swinog results in a huge amount of helpful replies, thank you very much! For example I did not know that you get a /22 automatically if you become a LIR: Why should I become a member? If your organisation needs IPv6 address space and AS Numbers, and/or makes assignments to End Users or customers, you should become a RIPE NCC member. RIPE NCC members are also eligible to receive a one-time allocation of a /22 of IPv4 address space from the last /8 of IPv4 address space for their LIR account. Any legal entity or natural person can become a member of RIPE NCC. So that will be the way to go. Thanks for the nice tips and mails! Andre On Mo, 2015-04-13 at 08:38 +0200, Andre Timmermann wrote: Hi, currently we (local.ch) are hosted in two different datacenters, each with a dedicated uplink. In order to improve the reliability and to dissolve single points of failure I want to do a proper BGP setup. One step of the whole thing is getting a PI space. As I do not want to become a LIR (too tedious, too much work) we want to buy a /24 for our setup. Can anyone point me into the right direction (or even sell a /24 ;))? Greetz, Andre ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RFC1918 IP's im Internet-Trace outbound - eine Unsitte - oder liege ich falsch ?
Hallo Stephan, ja, unschön ist das sicherlich - aber verboten ist es meines Wissen nach laut RFC nicht. Technisch spielt es für den Normalkunden auch keine Rolle - die wenigsten Kunden kennen die RFC1918 überhaupt. Ein richtig professioneller Internet-Anschluss (auch für zuhause) wäre ein eigenes AS mit Peering (z.B. zu Sunrise oder UPC CC, ...) Alles Andere ist ein mehr oder weniger guter Kompromiss zwischen Aufwand und Kosten. Wenn jetzt aber jeder private Kunde anfängt sein eigenes AS zu bauen (bzw. die Routerhersteller das aus Standard für die privaten Router einführen würden) reichen die verfügbaren AS Nummern nur für wenige Anschlüsse ;-) Im Übrigen: Mobiltelefone bekommen seit Langem nur eine RFC 1918 Adresse im GSM zugewiesen - was zu so Erweiterungen wie VPN-Passtrough und NAT-Traversal geführt hat. == nicht schön, aber für 99.9% der Kunden schön genug - es ist eben ein Massenmarkt mit Preiskampf und echte IPs kosten am Ende echtes Geld. lG Ralph - Ursprüngliche Mail - Hallo Swinog, seit gestern bin ich mit meinem 2. Internet-Homefeed wieder Sunrise Kunde. Die haben nun RFC 1918 IP's im Trace, was ich als falsch empfinde. Bisher hatte bis vor rund 1 Jahr die Unsitte nur Cablecom. Nun auch wieder Sunrise. Daher hier mal einfach eine Frage hierzu / Meinungen: Ich finde es FALSCH, im Internet auf Routern RFC1918 IP's zu verwenden. (ausser auf Management IP's die NICHT in Traces etc zu sehen sind) Siehe unten. Vielleicht liege ich auch ja falsch, oder sehe es zu kleinkariert - daher hier meine offene Frage, um erstmal vor meiner (Wissens-) Türe zu kehren. Ist das meine best practice, KEINE RFC1918 IPs im Internet zu verwenden, oder liege ich da falsch ? Eigentlich sollen diese nach RFC auch nicht geroutet werden im Internet. Klar kann man das abschalten - aber ich finde das NICHT korrekt diese im Internet zu Routen. Danke für eure Erleuchtung meinerseits z.B. Sunrise seit gestern: Outbound: Routenverfolgung zu adminsrv4.admin.ch [162.23.39.73] über maximal 30 Abschnitte: 1 1 ms 1 ms 1 ms [192.168.208.254] interner Router 2 1 ms 1 ms 2 ms [192.168.178.254] Sunrise Fritzbox / ext IP 62.167.73.175 (und nun gehts los...) 3 13 ms 10 ms 11 ms 10.136.71.241 4 12 ms 11 ms 11 ms 172.16.22.150 5 11 ms 11 ms 12 ms 172.16.18.177 6 11 ms 11 ms 12 ms 194.230.109.141 7 * * * Zeitüberschreitung der Anforderung. 8 * * * Zeitüberschreitung der Anforderung. 9 * * * Zeitüberschreitung der Anforderung. 10 16 ms 15 ms 18 ms 212.161.180.50 11 16 ms 16 ms 16 ms 194.230.36.210 12 20 ms 18 ms 22 ms pos20-bebun3isp-ipe1.inetbb.admin.ch [162.23.16.254] 13 19 ms 19 ms 18 ms gi03-bemon74isp-ipe1.inetbb.admin.ch [162.23.16.245] 14 19 ms 19 ms 18 ms gi101-befll15a-sge-ice1.inetbb.admin.ch [162.23.17.250] 15 * * * Zeitüberschreitung der Anforderung. Inbound: traceroute 62.167.73.175 traceroute to 62.167.73.175 (62.167.73.175), 30 hops max, 60 byte packets (snipp) 10 r1gva3.core.init7.net (77.109.128.66) 8.529 ms 8.689 ms 8.773 ms 11 gw-sunrise.init7.net (82.197.163.10) 3.891 ms 3.828 ms 3.795 ms 12 * * * 13 * * * 14 oer02lsr01.xe-5-0-2.bb.sunrise.net (212.161.180.201) 7.590 ms zur01are02.xe-4-0-0.bb.sunrise.net (212.161.180.206) 8.383 ms 195.141.215.45 (195.141.215.45) 7.451 ms 15 * * * 16 * * * 17 adsl-62-167-73-175.adslplus.ch (62.167.73.175) 17.696 ms !X 20.152 ms !X 19.375 ms !X VG Stephan ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] someone from Swisscom/bluewin there ?
how about calling their hotline 0800 800 800 first? scnr ;-) - Ursprüngliche Mail - Hello Swinogers, I have some problems with some bluewin based customers, Is there someone at bluewin who can contact me offlist please ? naz If *I* had a hammer, there'd be no more folk singers. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] someone from Swisscom/bluewin there ?
they won't - but you can always open a ticket and ask them to transfer your question to s/o with deeper knowledge. - Ursprüngliche Mail - Hello Ralph, I am not sure they will be able to understand the request at this number . Anyway, thank you for the advise ;) naz qu'ils n'en suivront pas moins les memes errements, dusses-tu en crever marc aurele -Message d'origine- De : swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] De la part de Ralph Krämer Envoyé : jeudi 4 décembre 2014 13:21 À : naz Cc : swinog@lists.swinog.ch Objet : Re: [swinog] someone from Swisscom/bluewin there ? how about calling their hotline 0800 800 800 first? scnr ;-) - Ursprüngliche Mail - Hello Swinogers, I have some problems with some bluewin based customers, Is there someone at bluewin who can contact me offlist please ? naz If *I* had a hammer, there'd be no more folk singers. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Swiss VoIP providers
how many people/phones/numbers? without going into details, I suggest to run your own Asterisk (or Callmanager) connected through a redundant SIP-Trunk to an VoIP Provider. cheers Ralph - Ursprüngliche Mail - Dear colleagues, I have come to ask for your help regarding VoIP providers based in Switzerland. Our telephony is currently managed by our landlord (EPFL) but we are moving offices very soon and will need to switch to a VoIP option. We initiated a few contacts but are not very impressed with what we have been seeing so far… We are just looking for a hosted VoIP infrastructure provider able to cater to small companies in an efficient way. It needs to be configurable by us as much as possible. We also need to be able to obtain a contractual SLA for management reasons as you can expect. Ideally, we would like to have a demo account set up by next week because I'm off on holiday after that and I would like to concerned parties to be testing it during that time. I guess this should not be an issue for an efficient provider ;-) So, do you have any feedback regarding such offers ? Thank you in advance for your help, Antoine ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] upc cablecom - mail.upccablecom-emailbilling.ch
Hallo Thomas, nicht nur für Dich, das Ding ist wohl wirklich tot. $ telnet 195.141.83.72 25 Trying 195.141.83.72... telnet: connect to address 195.141.83.72: Connection refused lG Ralph - Ursprüngliche Mail - Hello, does anyone else experience delivery issues for reading confirmation mails of upc cablecom billing mails? some of our outbound mta seem to be blocked because of the amount of reading confirmation mails, we tried to deliver. kind regards Thomas Lademann Swisscom (Switzerland) AG telnet 195.141.83.72 25 Trying 195.141.83.72... telnet: Unable to connect to remote host: Connection refused - upccablecom-emailbilling.ch. 3162 INMX 10 mail.upccablecom-emailbilling.ch. mail.upccablecom-emailbilling.ch. 66 IN A 195.141.83.72 - Domain name: upccablecom-emailbilling.ch Holder of domain name: Xerox Xerox AG . PO 8500014905 Lindenstrasse 23 CH-8302 Kloten Switzerland Contractual Language: German - inetnum:195.141.83.72 - 195.141.83.79 netname:XEROX-NET descr: Xerox AG descr: Lindenstrasse 23 descr: 8302 Kloten country:CH descr: SSIA5008 admin-c:SIPR1-RIPE tech-c: BG769-RIPE status: ASSIGNED PA mnt-by: AS6730-MNT source: RIPE # Filtered role: sunrise ip registry address:Sunrise Communications AG address:Binzmuehlestrasse 130 address:CH - 8050 Zuerich address:Switzerland abuse-mailbox: ab...@sunrise.net tech-c: MA9163-RIPE admin-c:MA9163-RIPE tech-c: DS3205-RIPE tech-c: DB2502-RIPE tech-c: LZ1685-RIPE tech-c: JJ3998-RIPE tech-c: DM11513-RIPE tech-c: MR13487-RIPE nic-hdl:SIPR1-RIPE remarks: --- remarks:For routing/peering issues, email peer...@sunrise.net remarks:For abuse issues, email ab...@sunrise.net remarks:For our helpdesk, email helpd...@sunrise.net remarks:For BGP community support, see AS-COMMUNITIES remarks:Business homepage: www.sunrise.net remarks:Residential homepage: www.sunrise.ch remarks: --- mnt-by: AS6730-MNT source: RIPE # Filtered ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Cisco router configuration for a Swisscom VDSL subscriber
VDSL is DHCP and BRI is pppoe - Ursprüngliche Mail - Hi list! I have to configure a Cisco router for a Swisscom Business Internet Light 1/1000” subscription via ISDN/VDLS. Does any of you have a example configuration, or can anyone give me the crucial technical specifications/protocols for the WAN side? Thanks a lot in advance, Thomas ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] 2x Cisco 2821 1GB RAM
Sali zäme, hab 2 identische Cisco 2821 (revision 53.51) with 1038336K/10240K bytes of memory. 2 Gigabit Ethernet interfaces 1 Virtual Private Network (VPN) Module DRAM configuration is 64 bits wide with parity enabled. 239K bytes of non-volatile configuration memory. 62592K bytes of ATA CompactFlash (Read/Write) übrig. gut geeignet um sich sein eigenes AS aufzubauen inclusive bgp full table abzugeben gegen Gebot hat jemand Interesse? msg me Gruss Ralph ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
