February 2022 - Test - lists.nanog.org

Cryptocurrency attack due to BGP hijacking
by Andrew Wesie 11 Feb '22

11 Feb '22

Recently, there was an attack on Klayswap [1] believed to be due to BGP hijacking [2]. From the public data on routeviews, we can see that there were announcements for the hijacked IP ranges, for example: U|A|1643854199.000000|routeviews|route-views.wide|||2497|202.249.2.169|211.249.221.0/24|202.249.2.169|2497 6461 9457|9457||| The weird part is that the path from AS6461 to AS9457 does not show up in any other routes. As far as I can tell from public information, there is no transit nor peering relationship between AS6461 and AS9457. As such, it seems likely a peer or customer of AS6461 was impersonating AS9457. I sent an email to Zayo's abuse email asking if they could provide any additional information but did not receive a response. If anyone has additional information, please reach out. Especially information about where the announcement may have originated. -- Andrew Wesie Theori, Inc. [1] https://medium.com/klayswap/klayswap-compensation-plan-99ec4db6742f [2] https://economist.co.kr/2022/02/07/column/expertColumn/20220207070013230.ht…

1 0

Re: VPN recommendations?
by William Herrin 10 Feb '22

10 Feb '22

On Thu, Feb 10, 2022 at 10:47 AM Juri Grabowski <nanog(a)jugra.de> wrote: > Or buy official supported hardware from https://shop.opnsense.com/ Howdy, Opnsense looks like it might work. I dug through some of the documentation but didn't find something entirely on point for my use case. Are you aware of any documentation which describes: LAN - OPNSense Appliance - (rfc1918) NAT Appliance (dynamic IP) - Internet - (static IP) OPNSense appliance - LAN Where the left-side OPNSense is responsible for establishing and keeping the NAT translations alive without any special configuration on the NAT? Thanks, Bill -- William Herrin bill(a)herrin.us https://bill.herrin.us/

2 1

Re: VPN recommendations?
by William Herrin 10 Feb '22

10 Feb '22

On Thu, Feb 10, 2022 at 10:06 AM Guillaume Tournat <guillaume(a)ironie.org> wrote: > Fortinet firewalls (FortiGate) are a great deal Thanks Guillaume, I found this https://community.fortinet.com/t5/FortiGate/Technical-Tip-IPsec-VPN-between… but it suggests that the dynamic IP fortigate expects to have a public dynamic IP directly on the Fortigate, not be stuck behind a NAT. Are you aware of any documentation that describes: LAN - Fortigate - NAT (dynaimic IP) - Internet - (static IP) Fortigate - LAN Where the Meraki is responsible for keeping the NAT translations alive without any programming on the NAT? Regards, Bill -- William Herrin bill(a)herrin.us https://bill.herrin.us/

1 0

Lumen/Century Link Clue Contact
by Mark Tinka 10 Feb '22

10 Feb '22

Hi all. Grateful if anyone from Lumen with some clue can reach out. They appear to be dropping traffic to our name servers (ns3.seacomnet.com + ns4.seacomnet.com) at our interconnect transit edge with them in MRS. Naturally, this is causing whoever is on their network to fail DNS queries to zones hosted on those name servers, which is causing all kinds of breakage, e-mail included. We can't e-mail them because, obviously, they can't verify our source domain names; and what should be our AM's appear to be on some kind of holiday. If someone from there can reach out to me (ideally from a non-Lumen/CenturyLink/Level(3) e-mail address), I'd be terribly obliged. Thanks. Mark.

1 0

Fwd: 2022 MANRS Ambassadors
by Arturo Servin 10 Feb '22

10 Feb '22

I think that this message hasn't been shared here. Regards as ---------- Forwarded message --------- From: Israel Rosas <rosas(a)isoc.org> Date: Mon, 7 Feb 2022 at 16:12 Subject: [lacnog] 2022 MANRS Ambassadors To: LACNOG <lacnog(a)lacnic.net> Dear all, Happy Monday! I’m reaching out to you to announce that today we are opening the call for applications for the 2022 MANRS Ambassadors program. *Ambassadors are required to be part of a MANRS participant organization*. They'll be responsible for guiding and mentoring a group of Fellows, as well as work together with the MANRS team. The call will remain open from 7-18 February. Selected Ambassadors will be announced on March 4. All the details and the link to participate can be found at https://www.manrs.org/ambassadors-program/ At the end of this month we will start the selection process for MANRS Fellows. In that case, the call for applications will be open to any interested person, not only to MANRS participants. Cheers, *Israel Rosas*, Senior Regional Development Manager rosas(a)isoc.org | Mobile: +52 55 3550 2363 | Pronouns: he/him/his internetsociety.org | @internetsociety My work hours may not be your work hours. Please respond in your own time. _______________________________________________ LACNOG mailing list LACNOG(a)lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

1 0

HULU
by Shon Elliott 09 Feb '22

09 Feb '22

Anyone from HULU on the list that can contact me regarding a network issue? Kind Regards, Shon Elliott Level 3 IP/Routing/Security Network Engineer unWired Broadband, LLC. selliott(a)getunwired.com<mailto:selliott@getunwired.com> [uw-logo] www.getunwired.com<http://www.getunwired.com/> The Valleys #1 Rural High-Speed Fixed Wireless Internet Service Provider

1 0

NANOG 84 Networking Events - N84 Kicks-Off Monday!
by Nanog News 09 Feb '22

09 Feb '22

*NANOG 84 Networking Opportunities * Networking is essential to the health of your career! Take advantage of the opportunity to meet + greet with industry leaders + professionals at next week's networking events at NANOG 84. *Day 1: Newcomers Breakfast Orientation* Monday, Feb. 14 | 9:00am - 9:45am CST Location: Waterloo Ballroom 5-6, Level 5 New to NANOG? Don’t miss our Newcomers Breakfast Orientation happening Monday, Feb 14 at 9:00am at our upcoming meeting, NANOG 84. Have an opportunity to network with fellow newcomers! *REGISTER NOW <https://nanog.org/events/nanog-84/>* *Day 1: NANOG Networking Luncheon * Monday, Feb. 14 | 12:00pm - 1:30pm CST Location: MoonTower Hall, Level 2 Some of the tables at lunch will have "Table Topics" for you to use to chat with others & network around the same topic. - Network Management - Automation - BGP Security - Routing - Traffic Management and Policy - Job Hunting - Peering - Newcomers Networking Follow-up - War Stories - The Time I Thought I'd Get Fired Sponsors: Kentik <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> , Sparkle <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> ,Telescent <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> *SEE AGENDA * <https://www.nanog.org/events/nanog-84/nanog-84-agenda/> *Day 2: Women in Tech * Tuesday, Feb. 15 | 12:00pm - 1:15pm CST Location: Waterloo Ballroom 5-6, Level 5 "What makes NANOG an incredible community, also makes it intimidating - 'courageous women' helping you not feel small" - Jezzibell Gilmore Co-founder of Packetfabric This is a no-pressure space to empower your fellow (wo)man! Join us for an opportunity to meet, network + potentially find your next mentee or mentor in the Women in Tech community. *Sponsor:* AWS <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> *SEE AGENDA <https://www.nanog.org/events/nanog-84/nanog-84-agenda/>* *Peering Forum Applications Still Available * NANOG 84 Peering Coordination Forum tables are still available. The forum provides time for attendees to meet + network with others in the peering community present at NANOG. Sign up for your table today! *SIGN UP * <https://www.nanog.org/events/nanog-84/peering-forum/>

1 0

PeeringDB Hackathon - looking for feature requests
by Steve McManus 09 Feb '22

09 Feb '22

PeeringDB is looking at participating at an upcoming NANOG Hackathon. One of the ideas for a theme is to improve the API. Specifically by adding API calls for common use cases that people need to handle outside of the API. Typically, by dumping the entire database to SQL For example - given two IXes, which networks are present at both? We'd like to make a list of such useful queries such that people don't have to dump the database just to run them. A stretch goal would be to expose into the website instead of requiring API calls. This issue has some more detail, including a few existing ideas: https://github.com/peeringdb/peeringdb/issues/1020 Comments there or in email to me would be super helpful. As always, if there are other feature requests for PeeringDB, feel free to create an issue in github ( https://github.com/peeringdb/peeringdb/issues/new/choose ) or in email, even if they're not strictly Hackathon ideas. They are always appreciated! Thanks! -Steve PeeringDB Product Committee chair

4 4

Re: Authoritative Resources for Public DNS Pinging
by J. Hellenthal 09 Feb '22

09 Feb '22

Not to mention. It is viable traffic to monitor, if I know that I get X number of icmp traffic through a point in tranfer consistently and that starts to drop off considerably that it may be a failing connection due to some circumstance I should start checking that equipment. And if im that connection in the middle... that is money ! On Wed, Feb 09, 2022 at 03:02:19PM +0000, J. Hellenthal wrote: > > Just think of all the smokeping probes that are out there plus services > like UptimeRobot and similiar. > > you can't just put something up as a provider of a service and say ... > ya know im not going to plan for this... traffic for them of any kind is > money... not only to them but to their IX's as well. > > ya just don't willy nilly cut that shit down and not expect a huge > blowup to happen. > > On Wed, Feb 09, 2022 at 03:53:15PM +0100, Łukasz Bromirski wrote: > > > > Yup. And Google folks accounted for the world pinging them all day long. > > > > I wouldn't call using DNS resolvers as best "am I connected to internet over this interface" tool though. A day, year or 5 years from now the same team may decide to drop/filter and then thousands of hardcoded "handmade automation solutions" will break. And I believe that's closer to what Masataka was trying to convey. > > > > — > > Łukasz Bromirski > > > > > On 9 Feb 2022, at 14:23, Mark Tinka <mark(a)tinka.africa> wrote: > > > > > >> On 2/9/22 15:00, Masataka Ohta wrote: > > >> > > >> > > >> Wrong. It is not bad, at least not so bad, pinging properly > > >> anycast DNS servers. > > >> > > >> The point of anycast is resistance to DDoS. > > >> > > >> But, relying on hard coded 8.8.8.8 is not a good idea because > > >> DNS service of the address may be terminated. > > >> > > >> Instead, properly anycast root name servers are authoritative > > >> resources provided for public DNS queries which can be used for > > >> pinging, though pinging so with ICMP should be less painful > > >> for the servers. > > > > > > That's like saying you won't have an egg for dinner because it's typically had for breakfast. > > > > > > Users don't care what infrastructure has been designated for. If they can find another use for it other than designed, which serves their interests, they will use it. > > > > > > We need to allow, and account, for that. > > > > > > Mark. > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

1 0

LLDP Source MAC
by Crist Clark 08 Feb '22

08 Feb '22

Came across some endpoint behavior that caused some confusion with a MAC authentication bypass (MAB) setup, and I was wondering if this is some kind of well known behavior. The endpoints (Pure storage arrays) are using the expected MAC addresses, both fixed and a “virtual” shared MAC for 99.9% of the traffic. The one exception is that the LLDP multicasts have a random-looking source MAC. The source MAC has the non-unique bit flipped on. Is this a well known type of behavior? Quick Google turned up some others noticing this in very different devices. May be more wide spread, but how often would people notice?

1 0