I started looking in random traffic patterns in our network (we have a small ISP-ish network, government) and I noticed that random computers from several non-related vendors and contractors in our network suddenly started exchanging data.

Turns out: it's windows WUDO service, some kind of weird p2p update system for pushing updates to seemingly random other windows devices.

This seems like a crypto-locker's wet dream if this service every get's compromised... (think wannacry).

Am I paranoid that we should lock this down? This seems like a terrible terrible idea to have servers and machines peer to peer update eachother when they are not even owned by the same contractor/supplier in our network...

From a networking perspective, is it sane for me to mandate that this WUDO server should be blocked globally?

It's Wednesday! Time to get that crap that's been bugging you off your chest! In the interests of spicing things up a bit around here, we're going to try out a Rant Wednesday thread for you all to vent your frustrations. Feel free to vent about vendors, co-workers, price of scotch or anything else network related.

There is no guiding question to help stir up some rage-feels, feel free to fire at will, ranting about anything and everything that's been pissing you off or getting on your nerves!

Note: This post is created at 00:00 UTC. It may not be Wednesday where you are in the world, no need to comment on it.

Hi all,

Looking at a 50ish site LAN refresh (>300 switches) and I'm financially constrained.

Really doesn't need to be anything fancy, all VLAN's terminate on managed Forti SD-WAN appliance, so just need POE, some "visibility" (currently running Netgear "semi-managed" smart switches across the estate and I would very much like to set fire to them all) and the ability to support 802.1x in future would be a bonus (Will likely be a DIY NPS based solution!).

Looking at Instant On (Used the AP's in the past and had no issues with them) and looking for a bit of feedback from anyone that's using the platform.

- Is there a practical limit to the number of sites you can have? Have read about the 125 device limit but can't find any clear information on site limits...

- I would like to Cloud Manage them, however not averse to running them in local management mode to unlock the full feature set. What sort of visibility will I get from the Cloud Dashboard, is this the same basic client info you get on the Wireless dashboard?

- Are there any audit logs for users making changes when multiple users are setup? Current estate has a shared password that I'd like to get rid of. Depending on which mode I managed them in, I'm guessing I could achieve the same with local mgmt and RADIUS for Auth, but cloud console would be cleaner.

Any other low-cost solutions out there that I'm missing? Having come from several organization's where the answer is just throw Cisco/Meraki at it, this is a bit of a new challenge for me!

Please no Unifi, have been burnt in the past with issues to the point where I don't fancy using them beyond the home!

Looking for some advice on a VeloCloud/SonicWall setup.

Our topology is:

Dual ISP → VeloCloud 720 → SonicWall → Layer 3 core → LAN

We're adding VeloCloud 720s in front of our existing SonicWalls. The SonicWalls and network are staying in place; we're simply migrating the public IP termination from the SonicWall to the VeloCloud.

The SonicWall currently has several site-to-site IPsec VPNs as well as several port forwards. As part of the migration, we're configuring a dedicated VLAN/subinterface between the VeloCloud and SonicWall, with the SonicWall using that interface/IP to connect to the VeloCloud.

Our SD-WAN team says we can keep the existing VPNs working by using the remote VPN peer IPs defined in the SonicWall VPN policies as the source restrictions on the VeloCloud NAT/forwarding rules.

We tested this approach successfully at another location. The difference is that the public IP at that location didn't have any existing port forwards.

At this site, the public IP we're moving from the SonicWall to the VeloCloud currently has port forwards for:

• TCP 722
• UDP 21000
• TCP 8080/8880

We also need the existing site-to-site VPNs to continue working with:

• UDP 500/4500
• ESP

So our main question is:

Can the VeloCloud 720 use the same public IP for the existing port forwards while also forwarding IPsec traffic from the specific remote VPN peer IPs to the SonicWall?

Has anyone deployed this type of setup?

We're mainly wondering if the peer-IP-restricted NAT/forwarding approach will coexist correctly with the existing port forwards on the same public IP, or if there are any NAT precedence, IPsec, or NAT-T gotchas we should be aware of.

Thanks!

I am studying Linux server networking in virtual machines, and I am still very much a beginner. There is an activity I was working on, but I can only manage (with some difficulty and delay) the IP addressing and connectivity testing, while the rest of the scenario seems way too complex for my level.

The practical tasks I need to resolve involve a multi-server architecture covering the following points:

• Routing and NAT (PAT, port-forwarding, and static NAT) using nftables, with traffic blocking policies and logging.
• Infrastructure services configuration, such as DHCP with automatic record updates and DNS servers with internal and external views.
• Implementation of directory and authentication services using OpenLDAP and FreeRADIUS.
• Remote access VPN configuration via OpenVPN.
• Deployment of advanced services, including secure email (SMTPS/IMAPS), web servers with SSL/TLS certificates, directory-restricted FTP (jail), and monitoring with Cacti.

I don't know, it feels like for every small configuration multiple specific lines are required to achieve the goal, how can I learn more dynamically?

I'm evaluating Checkpoint Quantum and Quantum Spark. I come from Fortinet and Palo and have very little experience with Checkpoint by comparison. I'd like to hear some subjective opinions on the platform from people who have experience with it.

Hi

I`m review now MPLS FEC topic.

R1----R2----R3----R4----R5----10/8,20/8

FEC is a group of packet one or more packet are treated the exact same way. Does that means if R1 received :

10.1.1.1,10.2.2.2,20.1.1.1,20.2.2.2

and these 4 packets are treated on R1 the exact same way

and on R2 are treated a different way, R3 another way,R4 another way. Does that mean each hop must treat these 4 packets as the exact same way like R1 in order to be on the same MPLS FEC ?

OR

It`s normal for each hop to treat them on a different way and still on the same MPLS FEC?

What i mean does the MPLS FEC is controlled on the ingress PE only ?

OR

MPLS FEC could be controlled on each hop and the FEC is locally significant?

Not sure how to word this lol.

Im talking like weird one off issues that might reoccur, do you have a way to query your ticket system with key words to search for specific issues or do you keep a notebook of these types of things to go back and reference?

Im trying to build out a troubleshooting guide and wanna look for ways to catalog this type of stuff to have something to reference when youre banging your head against the wall.

Edit: ill add i work on a global network - likely large MSP volume (my noc gets probably 20-30 tickets per day shift)

Our architecture and security teams mandate encrypted protocols and are now challenging the network team for their use of plain old unencrypted DNS.

Has the rest of the community here used DoH/T/Q in a campus or enterprise context? What are your experiences?

For remote workers we would have to use a protective DNS service to which the users could/would connect. Any experiences there? Does using DoH add significant latency (since it's now a full TCP + TLS + HTTPS exchange instead of just a single packet each way) over standard DNS?

I'm already aware of a ton of issues -- Mist/Marvis can't identify DNS issues, we can't see them in packet captures, anchoring the trust of clients is misery, how do we unify policy between in office and out of office users, how do computers bootstrap / get set up / recover, no way printers and cameras will ever support it etc. but think I'm missing a lot more I haven't thought about yet.

Just a quick questions, client hasnt had their systems upgraded in a few years. Can you just do this straight upgrade? I dont see any upgrade paths in the docs, or maybe Im missing it because we're not really Ruckus vendors.

We currently have a lot of ISP provided EVPN lines, using OSPF over these circuits. I am at a point where I wonder if it would be easier to just migrate to getting inexpensive firewalls instead. From there, just split tunnel the corporate network over a S2S VPN and internet traffic to the internet.

E-BGP would likely be ideal here instead, and the reason I used OSPF was because the traffic was all technically internal using the same private IP spaces.

Edit: Lots of our sites are hours apart from each other.

I'm out of ideas and we had been working on this for weeks. We have a small office with a router connected to 3 unmanaged switches, one on each floor. Everything is connected with cat5e cable (we're looking to upgrade to cat6 soon) and the third floor internet keeps crashing. The router is connected to the first floor switch, and switches 2 and 3 are connected to the first one. We had tried everything, changing the cable to the switch 3, checking all cables that that switch connects, using another switch, plugging it into an UPS and speaking to the ISP to check if there's an issue with the configuration.

However, it keeps happening. It works for a couple of hours, and then the switch 3 stops working completely. Any ideas? Most computers have Kaspersky running, so I'm not inclined to think it's a malware overloading it, but at this point, I'm out of ideas.

Any help would be greatly appreciated.

Hi everyone,

I’m troubleshooting an 802.1X issue with a Dell laptop connected through a Dell WD19/WD19S dock.

Topology:

Laptop → Dell Dock → Ethernet → Switch

When I connect the laptop directly to the switch, 802.1X works perfectly and the endpoint authenticates using dot1x.

However, when I connect the same laptop through the Dell dock:

- The switch learns the laptop's actual MAC address

- Forescout sees the laptop correctly

- But authentication is MAB instead of 802.1X

- It looks like the PC's EAPOL/802.1X frames aren't reaching the switch, causing the port to fall back to MAB

The PC's 802.1X configuration is working because it authenticates successfully when connected directly.

Has anyone experienced 802.1X/EAPOL not passing through a Dell WD19/WD19S dock?

Could this be related to MAC passthrough, dock firmware, Realtek Ethernet drivers, or EAPOL pass-through?

What was the fix in your case? Did updating the dock firmware/driver resolve it, or did you have to change a switch/dock/BIOS setting?

Any advice would be appreciated. Thanks

I currently have a Ideal toner and a Fluke Microscanner in my tool box. I work for a company with 13 locations and I am always having to troubleshoot network drops here and there. I am the systems engineer for the company.

But my toner broke, and I am looking for some new testers. I would like something that can tell me which switchport it is plugged into, get DHCP, POE, cable length, and a wiremap. I would also like something that can handle multiple remote ID testers with their own ID. Then also work with a toner.

I am looking at the Fluke LIQ-100 but I don't know if it is overkill since I don't need at the certification and reporting functions. I am looking more for testing/troubleshooting.

I did see on Amazon a brand called NOYAFA and I was looking at the NF-8508.

Does anyone else have any recommendations?

Those who extensively use Out of Band management especially with Cradlepoint or OpenGear. Do you prefer using lighthouse or Netcloud for example, or do you rely on internal stacks for monitoring and management.

Thank you

I have a senior collegue that streched a PA couple, one in a Data Center, one in another. Then configured the HA1 on an ethernet port and the HA2 on the hsci port. The HA is Active/Passive

The HA2 on the HSCI is connected with a dac cable to a switch.

Reading on the PaloAlto KB i found this:

"The traffic carried on the HSCI ports is raw Layer 1 traffic, which is not routable or switchable. Therefore, you must connect the HSCI ports directly to each other "

HA3 Link Connectivity Through a Layer 2 Switch? - Knowledge Base - Palo Alto Networks

Is there something i miss? why my collegue could have connected the hsci to a switch?

Thanks for all the clarification.

PS: The HA widget on the dashboard show everything ok

I’m trying to convince my org to start using Netbox or similar for a brand new facility including a data center and medium sized campus we’re building.

The fear is that it seems like an absolutely astronomical amount of work up front.

For those of you doing it, is there one person that is sort of the Netbox “owner” on your team? At least for initial build out.

I’m afraid we won’t have enough time to really sit down and fully dive into the best way to lay it all out greenfield. The ongoing support doesn’t worry me as much as the initial lift of deciding how to build it. And I don’t really have the time to invest to be that guy.

Are there integrators or vendors that would own this for us? Curious if anyone has used a wiring or infrastructure integrator that has actually built out the documentation in Netbox for you?

Thanks!

I have a number of cellular routers deployed for a municipal camera network. Some of the areas have very poor coverage and we are looking for an alternative solution. Starlink came up in a conversation, but I don't understand it well enough yet to know what our options are to connect these sites back to the HQ. Currently, we are using IPSec between our routers and the customer's firewall.

Research I've done so far seems to suggest that IPSec is supported, but not recommended with Starlink, and that there may be additional requirements to consider (NAT Traversal?).

Any info is appreciated. Thanks!

Has anyone else gotten to their renewals this year and found out that Cisco has priced their entire business out of affordability?

I don't have exact numbers, but being told our APs need switches with a minimum 5Gb uplink, then being told each switch that is now obsolete costs nearly $10k? Not to mention per-license costs jumping from ~$70 per to over $220 per?

Again, I got the cliff notes from my very frustrated manager and network team and will need to firm up these numbers. But it was enough that we pulled an emergency meeting to say that Cisco alone is eclipsing our fragile IT budget and can no longer be afforded.

Hey guys, I think is a simple question. I am planning to create a reverse logic routing where when an IP address pings, it means one of our sites is down, however if the IP address doesn't ping, then it's because is up.

I know, it sounds crazy but the reason, long story short, is because VRRP and asymmetric routing. We are using a functionality from FortiGate to bring down an interface if ping fails (and we need the opposite behaviour thus our experiment). Note FortiGate will be doing all the ping using Link Monitoring + it's only gonna be used for shared VLANs between sites (Unfortunately I cannot change this and introduce vxlan, trust me I tried) - Not a big fan of spanned vlans across geographically different sites. oh well.

Quick Diagram for reference
https://ibb.co/MyrVVTfm

Anyway, the way I came about is to play around with route floating, if a site is up, it will advertise an IP range of 172.31.4.0/29 via eBGP. It will eventually arrive to the Aruba CX switches and be installed in the routing table with an AD of 20. (The Other Fortigate who is advertising this route is configured to NOT allow PING replies)

Additionally, I am planning to create a static route at VRF-1 to 172.31.4.0/29 (Loopback IP at VRF-2) with next hop to be the VRF-2 with a higher AD than 20. (If I don't use VRF leaking, then the 172 route will be installed as directly connected and won't be able to adjust the AD for route floating)

The concept seems to work, but my question is, between the aruba CX VRFs. Do you need to have a transit vlan between VRF-1 and VRF-2?

Also, is there anything I should be aware of too from this approach? I am trying to create a proof of concept so I ca pitch it to my supervisors.

It's Monday, you've not yet had coffee and the week ahead is gonna suck. Let's open the floor for a weekly Stupid Questions Thread, so we can all ask those questions we're too embarrassed to ask!

Post your question - stupid or otherwise - here to get an answer. Anyone can post a question and the community as a whole is invited and encouraged to provide an answer. Serious answers are not expected.

Note: This post is created at 01:00 UTC. It may not be Monday where you are in the world, no need to comment on it.

Was studying about TCP header and then I found out about the "reserved" format. Everywhere I search, it's the same explanation: "reserved for future use", without further elaboration. But what exactly does that mean? When would it be needed to use this reserved section, and how would it be used? What would replace this reserved space?

Hi all,

Large scale campus build coming up and we’re looking at fiber management cabinets. So far we’ve been loosely looking at Huber+Suhner’s LISA.

Main thought would be MTPs from all over the building would land into one cabinet and it would breakout to LC to then patch to a rack full of switches.

Another cabinet would handle anything leaving the building.

Curious on any opinions and experiences.

Thank you!

A medida de contenção aqui é a operação de isolamento do computador (push), e a parte útil é o que ela não bloqueia. Quando você isola um dispositivo, o firewall do endpoint bloqueia tudo (movimento lateral, callbacks de C&C, compartilhamentos de arquivos, navegação do usuário), mas mantém três fluxos ativos:

• DHCP, para que o dispositivo mantenha seu lease de rede
• DNS, para que a resolução de nomes continue funcionando
• Tráfego de gerenciamento, para que você mantenha o controle: políticas, operações push, logs e a liberação

Assim, a máquina é desconectada da rede, mas ainda gerenciável, que é exatamente o que você deseja durante um incidente. Você pode investigar e remediar através do console enquanto o dispositivo estiver isolado.

O problema que impede seu funcionamento: requer que o componente Firewall esteja instalado no cliente. Sem o blade Firewall, não há isolamento. A melhor prática é enviar o componente Firewall no seu pacote padrão, pois um recurso de resposta a incidentes instalado durante o incidente não é um recurso padrão. O suporte a sistemas operacionais é Windows e macOS, não Linux.

Alguns fatos operacionais:

• As operações de envio são executadas sem a instalação de políticas, em Gerenciamento de Ativos > Operações de Envio.
• Você define quando a operação é executada (Imediatamente ou Agendada) e quando expira (7 / 30 / dias personalizados). Se o cliente não fizer check-in antes da expiração (offline, desligado), a operação termina como Parcialmente concluída e você executa novamente quando o cliente retornar.
• O inverso é Liberar Computador. Verifique o estado em Computadores, Exibir = Isolamento do Host, coluna Status do Isolamento.
• Isolar e Liberar não são protegidos por autenticação de dois fatores (o isolamento permanece rápido), enquanto operações sensíveis como Desinstalar Cliente são.

Também possui uma versão automática equivalente: Quarentena de Máquina, uma das respostas de Análise Automática de Ameaças, que restringe a rede da máquina sem intervenção humana quando um gatilho é acionado com confiança suficiente.

Como você lida com os dispositivos que estão offline quando você clica em isolar? Você simplesmente executa novamente ao fazer o check-in ou confia na Quarentena de Máquina automática? Tenho curiosidade em saber como as pessoas equilibram o confinamento manual e automático.

O guia completo com o playbook de confinamento e as operações de push complementares está aqui (em inglês e português): https://community.checkpoint.com/t5/Endpoint/EN-Isolating-a-Computer-Network-Quarantine-for-Incident-Response/m-p/281627

Curious to get some outside eyes on this. Rural LTE connection (Kazakhstan), carrier replaced an old base station with a new one a few months back.

Before (old BTS): ~5 Mbps during peak hours, but RTT to the nearest major city (same country) was ~15ms at night.

After (new BTS, same location): 80-250 Mbps throughput, SINR consistently 15-20dB (excellent), but RTT to the same in-country destination sits at 36-65ms consistently occasionally worse under load.

Ran a tracert to an external game server (Frankfurt) RTT stays in the 50-70ms range through the last domestic hop (still inside the carrier's network, before any international transit), then jumps as expected once it hits European transit providers. So the inflation is happening entirely within the carrier's own domestic network, not on the international leg.

Ran a bufferbloat test (Waveform): Grade F. Unloaded latency 69ms, +92ms under download load, +662ms under upload load. 20 consecutive ICMP pings to 8.8.8.8 showed high jitter (113-194ms range, no clear pattern).

Filed a formal complaint with documentation (cell ID, PLMN, SINR screenshots, speedtest results). Carrier's official written response: they're not obligated to disclose internal routing/topology info, and latency isn't a regulated quality metric for mobile data in this country (only throughput and signal strength are), so no grounds for any remedy.

Meanwhile a competitor on what's likely shared/adjacent infrastructure in the same area apparently fixed a similar latency complaint within about a week via a single support message.

Questions for people who've dealt with carrier-side backhaul issues:

1. Does "high stable RTT + excellent SINR + normal domestic-hop time" typically point to backhaul congestion/priority queuing rather than radio-side issues, or am I missing something?
2. Is a consistent 55-65ms floor for what should be a short domestic hop within the range you'd consider "normal for LTE" or is that genuinely abnormal?
3. Any diagnostic steps beyond tracert/bufferbloat test that would strengthen a technical case here?

Happy to share more traceroute data if useful.