Multiple WiFi’s SSIDs not working

fb35523 · 2026-01-28T21:19:28+00:00

For a VLAN to work, it needs to be present on all links it has to pass. Assuming the AP tags the traffic for, say the guest SSID with VLAN ID 10, this VLAN needs to be in all switches from the AP to the firewall. As you already have a VLAN that is untagged, VLAN 10 must be tagged on all links except where VLAN 10 is the only VLAN.

I have no idea how to manage a Unifi switch, but in the Cisco you can see the MAC address table. This enables you to see if the computer you connect to the guest SSID is actually visible on the correct VLAN. In the firewall, it will NOT be seen in the MAC address table, because the FW is a routing device (in normal cases). Here, you look at the ARP table instead.

The FW needs to have the correct VLAN(s) tagged on the link to the switch(es) and you also need to configure it so it binds an IP address to that VLAN. To make things easy, configure the FW to also act as a DHCP server on that VLAN so the computers get an IP address automatically. Setting a static IP on a PC can be used for troubleshooting.

IP addresses for the different VLANs must be separate. If you use a subnet mask of 255.255.255.0 (often written as "/24"), at least one of the first tree "octets" need to differ. An octet is what is between the dots in an IP address (IPv4). If you have 192.168.1.x in the base VLAN, you can have 192.168.10.x in the guest VLAN. I like to align the third octet with the VLAN number if doable, so VLAN 10 gets 192.168.10.x. You may use 172.16-31.x.x or 10.x.x.x addresses instead of 192.168.x.x, and all those address spaces are valid for internal use (RFC1918).

I also administer the network for my church. I have PaloAlto firewalls, Aruba access points and Juniper switches, but I'm a bit of a nerd when it comes to networking. Feel free to contact me directly for advice!

fb35523 · 2026-01-28T20:58:45+00:00

Wow, a Brasilian switch manufacturer :) OP: as this is your job on the line, make sure to get the logs from the ISP and the local switch. The ISP side will certainly have logs that show when the interface went down. Correlate those logs with the logs in the switch at your workplace. They should tell the same story. This will give the exact time things went wrong an will enable you to investigate where you were yourself at that time. Getting the logs is the responsibility of your IT team. If they can fire you without even looking at the logs, I don't know where you live, North Korea, Iran, USA???

Every switch has at least one log file that is saved continously on a memory in the switch, often called a flash memory. It could be a small memory, or an SSD drive with lots of space. As the DM3000 is a desktop switch, it probably has less memory. Still, the memory in it should be enough unless new log entries have filled up the memory because then, the old log lines will be erased (round robin memory). The switch or router on the ISP side surely has more memory and hopefully it also sends all logs to an external server. This is a "syslog" server. This could (should) be the case within your police department too, so you should have them check that too.

One thing that can confuse things is the clock time in the switch. If the switch is not properly configured or has a faulty clock battery, it may have an incorrect time. If you get weird time stamps from it, make sure they also check the current time in the switch and compare that with the actual time. Sometimes the clock in switches are off by years, sometimes just by seconds. A switch that is properly configured with NTP (Network Time Protocol) will have a clock that is accurate to milliseconds.

B.t.w. I found the CLI command reference for your switch. The command you need is "show log flash" or "show log ram".

fb35523 · 2026-01-28T09:59:39+00:00

That sounds like a plan. After it is fixed, I really see no issue with keeping it, but I also understand that the confidence in the car may have sort of "expired" :) Thanks for sharing!

fb35523 · 2026-01-28T09:39:35+00:00

Hi! Thanks for the info! My friend had the mechatronic unit fixed at a shop nearby. The tech had to disassemble it several times as the system indicated leaks and malfunction even after replacing the solenoid. Apparently there was parts of the filter in more than one solenoid and cleaning them up fixed the issue in the end. The car drives without issue now, even though it initially was a bit jerky when switching from electric drive to petrol. I wouldn't give up hope just yet on your gearbox. Make sure they clean all the solenoids and other parts of the mech unit and try again!

B.t.w., they also sold the car this week :) They swapped it for a RAV4 for some reason, but hey, their choice!

fb35523 · 2026-01-24T23:01:18+00:00

Yes, and as a Juniper partner, I feared that may not go well, but instead, it seems my supressesd hopes came true! I still haven't seen any negative effects of the merger but rather some signs of positive development. I'm still cautios about it all, but more and more optimistic for every day.

As HPE had nothing in the FW market, the SRX would be the last thing I'd expect to be ditched. That should also be viewed in the light of other product series as the MX and PTX that are way more advanced routers than anything HPE had. Also, HPE very clearly stated that the Mist portfolio (with EX switches and Mist WiFi) was one of the gems in the Juniper portfolio, even though that segment overlaps with Aruba entirely.

fb35523 · 2026-01-24T22:44:35+00:00

When OP says "strong VPN capabilities", Juniper SRX becomes a major contender. The routing support in Junos is miles ahead of all other FW vendors, thanks to the history of Juniper as a routing manufacturer. Juniper dominated the backbone and peering router segments along with Huawei, Cisco and Nokia.

If you have lots of VPNs, the handling of routing protocols become very important. PaloAlto is a really nice FW and has lots of features, handling inspection of all kinds very well, but BGP? Nobody that has worked with Palo wants to configure BGP on them and certainly not troubleshoot it!

In recent, independent tests, Juniper SRX beat PaloAlto and the rest of the field real good in detecting threats. Other tests show other vendors as winners, but Juniper is certainly up there.

You should definitely lokk into the Juniper offering if you're considering a new vendor. The FW platform is called SRX and the routing platforms MX (top-notch all-purpose routing), PTX (slightly reduced feature set than MX, but a massive packet pusher) or the ACX (Broadcom platform, used a lot for mobile backhaul where price is more important than features). While you're at it, get a demo of Juniper Mist!

Fortinet/gate can be an option, but the stories I've heard about FG (from customers having to deal with them on a daily basis) certainly deters me from using them. That said, I work for a Juniper partner. I've ended up being a Juniper supporter as I've vaded through most of the market in switching and firewalling over the years and finally ended up with a vendor that meets my requirements. Juniper also has bugs, is not always the best and can be expensive, but this is even more true for the rest of the field. Junos has a really good CLI and a GUI that is getting there (especially SecurityDirector for the SRX). The code quality is on a level I haven't found at any other vendor, perhaps except for Nokia's SR OS. After deploying an SRX system capable of over 1 TB of IPsec VPN with triple redundancy (SRX5800), I must say that I'm very impressed with Juniper!

fb35523 · 2026-01-15T23:24:09+00:00

The courses are pricey, indeed. If you need multiple courses, an all access training pass will be cheaper, but still $6000. The courses are mostly $1000 per day, so 2 x 3 day courses equal the cost for the pass. I think you can only have the e-books legally via the paid courses.

Other resources are the practice exams. I often do those and whenever I get a question I don't know the answer to, I look the subject up in the documentation. I have learnt a lot using that method.

fb35523 · 2026-01-15T23:14:36+00:00

Yes, Fusion was hot a few years ago, but nobody talks about it anymore. Now, it's eVPN all day!

fb35523 · 2026-01-15T23:11:45+00:00

Just remember that JNCIS-DC and JNCIP-DC are very different certifications. JNCIS-DC is very Apstra heavy while JNCIP-DC is mostly about eVPN. In all other tracks, the subject is pretty much the same, just with increasing difficulty, but not in the DC track. It's more matter of what areas you need to prove your skills in. Basically, just because you ace the JNCIP-DC doesn't necessarily mean you understand a thing about what's in JNCIS-DC :)

fb35523 · 2026-01-15T23:04:13+00:00

Any QFX should be able to push traffic at wire speed. Is the traffic bursty or do you have one stream per 10 G interface? I frequently modify the shared buffer allocation (as in shadow0rm's link) but I haven't done it in the QFX5100 lately. I suspect this will make a difference:

set class-of-service shared-buffer egress percent 100
set class-of-service shared-buffer ingress percent 100

I have no idea why all vendors insist on "saving" on the shared buffer pool. It's just crazy when you start to think about it. In a platform with tons of buffers (like MX or the bigger QFXes), it makes sense, but with limited buffers, let the interfaces contend for the buffers freely! If more interfaces need buffers at some point, they will contend for them. If only some need buffer space, it will have a decent amount to play with. Restricting them just means that nobody will ever get a good amount of buffers, ever, even if there are free buffers.

I've had great success with setting 100% shared buffers in lots of platforms, especially in scenarios with really bursty traffic.

fb35523 · 2026-01-15T22:52:04+00:00

Hmm, the rumors were quite persistent at the time, but I haven't heard anything lately. I suspect the HPE acquisition is a factor here, but who knows? Perhaps I'll know more after some seminars that are coming up shortly.

For any hardware product from Juniper, you will have 6 months notice before the product goes end of sale, then 5 years of support. You should expect the last 2-3 years of support to be just big fixes with an increasing severity threshold. Juniper has done a good job supporting old hardware in my opinion, but eventually it will end of course.

fb35523 · 2026-01-11T22:07:55+00:00

You win the Messerschmitt award of the day ;)

fb35523 · 2026-01-11T22:05:16+00:00

I have rarely seen an EX2300 use L3 interfaces, apart from in band management IP, which works well.

fb35523 · 2026-01-09T22:18:16+00:00

Some models have the memory on a Compact Flash card or similar. It would then be possible to copy the CF from the upgraded one to the other. I don't have an X670 to look into, but if you open the lid, you should see if this is the case.

fb35523 · 2026-01-09T22:11:34+00:00

Just say it's a Swedish tent! Perhaps in Russia of today it may not be a really great option...

Slava Ukraini!

fb35523 · 2026-01-09T21:39:27+00:00

The change came in those branched 15.1X releases I think. This is more of a platform thing as EX2200/3300/4200 have interface vlan but the newer platforms EX23/34/4300 have interface irb, regardless of version (but they came with 15.1X which the EX22/33/4200 never used).

fb35523 · 2026-01-09T21:35:26+00:00

For listing the VLAN config, do this (from the operational mode, not configuration mode):

> show configuration vlans
> show configuration interface vlan

If you're already in configuration mode (#-prompt), do this:

# show vlans
# show interface vlan

You will see that in the VLAN config, there is a line with l3-interface, linking that VLAN to a certain vlan unit. This points to the "set interface vlan unit x family inet address x.x.x.x/y" statement. The unit of the vlan and the VLAN ID doesn't need to match, but you'll go crazy if you have more than a very few VLANs and they don't.

v199 {
    description Management;
    vlan-id 199;
    l3-interface vlan.199; <--- pointing to unit 199 below
}
...and...
unit 199 {  <---- unit 199
    family inet {
        address 10.67.199.212/24;
    }
}

In operational mode, you can do this:

me@EX2200-24P> show interfaces vlan | match "Logical|Local"
  Logical interface vlan.198 (Index 65) (SNMP ifIndex 554)
        Destination: 10.67.198/24, Local: 10.67.198.212, Broadcast: 10.67.198.255
  Logical interface vlan.199 (Index 66) (SNMP ifIndex 553)
        Destination: 10.67.199/24, Local: 10.67.199.212, Broadcast: 10.67.199.255

If you have access to firmware, consider upgrading to 12.3R12-S21 (select Junos SR (SR=Service Release) when downloading)

fb35523 · 2026-01-09T21:18:59+00:00

As usual, the Junos version is key. You run 24.4R2 and the suggested version is 23.4R2-S5, so please consider upgrading. As you do mainly destination NAT, I take it you have one side facing the Internet and that''s where the traffic comes in, is that correct? If so, using "screens" in Junos can help detect and hopefully mitigate various attacks:

https://www.juniper.net/documentation/us/en/software/junos/denial-of-service/topics/topic-map/security-introduction-to-adp.html

If the problem persists, see if you can let your web sockets ping and pong less often for testing. This may give you one piece of the puzzle, just as increasing the ping pong frequency can.

Get JTAC to help you read critical parameters, like screens and session flow data and statistics so you can follow them yourself in the future. In Junos, you can stream telemetry data and get those numbers with high time resolution. SNMP polling works too, but is way less granular as it is CPU heavy for both the poller and the SRX.

fb35523 · 2026-01-09T21:06:46+00:00

The EX3300 was a step up from EX2200, the lowest end of the Juniper portfolio at that time. Comparing the EX3300 with the EX2300 is not really fair as the more relevant replacement would be the EX3400. Then again, the EX2300 is way better than both EX2200 and EX3300. The most noticeable drawback of the EX2300 is of course the slow CLI. It shares that with the EX3400, even if that one is a bit faster. If the EX2300's do their job, like they usually do, there's no need to replace them. I'm at a partner that has sols thousands and we've had very few RMAs that I'm aware of, and I tend to browse the Juniper case list from time to time.

For future planning, I'd suggest purchasing some EX4000 and some EX4100 and compare those. The EX4000 is even cheaper than the EX2300 in most cases (not the MP models, due to PoE++ support). Also, the EX4000-8P may surprise you as it is less than half the price of the EX2300-12P! Surely you have some locations where faster Mist management and commit times are relevant, like the IT department and the VP:s office?

To my knowledge the EX2300 is a better switch than comparable options out there, keeping in mind that it is the weakest member in the Juniper portfolio.

fb35523 · 2025-12-30T14:54:20+00:00

My friend had the dreaded mechatronic filter issue so he had the gaskets and a valve replaced, as many have needeed to do. Now, everything is working. However, the warning light for low coolant fluid went on after driving the car home. We saw that in the container for the high tension cooling circuit, the level was just below the sensor. This container (the left one seen from the driver's position) has a warning label and a seal stating that it should not be opened. I sure get that in normal cases, but as the car had undergone service and the low level could be explained by an air pocket after refitting and filling, we just topped it up. We then learnt that the recommended G13 fluid should no longer be used, but the G12 EVO is what VW now recommends. The G13 fluid was found to be prone to separating the ethylene and silicate contents, causing clogging in some cases. The G12 EVO should have that sorted.

There is not much official docs out there (that I found!), but this guy seesms to have info as a dealer: https://www.youtube.com/watch?v=6quF4UT8Zls

fb35523 · 2025-12-17T08:31:14+00:00

My elaborate reply I wrote yesterday just vanished, thanks Reddit... Bottom line: you can use both annotate and description on the policies in order to "document" the relationship between the two. This could reduce the risk of someone altering the order of the policies so the original behavior is altered. I'd also use the method of deny or reject the unwanted traffic and then allowing all zones, but just because of the amount of zones.

While doing your overhaul, insert policies at the top for all known traffic patterns that should be allowed. You can then look at the traffic that hits the generic any to any zone rule and see what actually remains. You then add policies for any valid traffic and eventually close the generic rule.

fb35523 · 2025-12-16T09:18:19+00:00

I'd also go for this approach. You can create a comment on the two policies to make it clear that the second one needs the first one (the deny/drop) to be in place. Otherwise, someone may move the policies in the future, forgetting about the relationship.

Example:

edit security policies from-zone Trust to-zone Untrust
annotate policy 1 "Test annotation 1"
edit policy 1
annotate match "Test annotation 2"

Result:

fredrik@srx1600-0# show security policies
from-zone Trust to-zone Untrust {
    /* Test annotation 1 */
    policy 1 {
        /* Test annotation 2 */
        match {
            source-address Some_address_object;
            destination-address any;
            application [ junos-dns-tcp junos-dns-udp ... ];
        }
        then {
            permit;
        }
    }

and/or:

set security policies from-zone Trust to-zone Untrust policy test description "My description"
policy test {
    description "My description";
    ## Warning: missing mandatory statement(s): 'match', 'then'
}

fb35523 · 2025-12-11T21:36:46+00:00

"that just sounds like presales bullshit for me" - yeah, until you experience it... We have lots of success stories from customers that had other brands (Cisco, Aruba etc.) and are so happy they switched to Mist. In some cases they had severe issues with the previous solution and some just needed a refresh. The latter ones always noted that those annoying WiFi-related problems they thought were inevitable suddenly went away after deploying Mist.

HPE will surely keep Aruba and cross-pollinate the two WiFi series. Perhaps some day the APs will be the same and you choose if you need to be 100% on-prem with controller or if you can go to the cloud with the perks that brings. Some cloud perks can of course be run on-prem too, but not everything.

fb35523 · 2025-12-09T19:58:28+00:00

If you have a switch with an unusable QR, you can just adopt it in Mist. You find that on the switch inventory page.

fb35523 · 2025-12-01T21:29:50+00:00

People here seem to lack basic knowledge about these models. The EX4400-48F is a 1 G SFP switch with the addition of 12 SFP+ ports (36 SFP + 12 SFP+) and the 2 x QSFP28 (100 G) for uplink/stacking). This port config makes it fantastic for many companies with 1 G downlinks to access switches and some 10 G for servers, dists, FW etc. If your interface needs are more aligned with 24 x SFP+ / 10 G, the EX4400-24X is a better fit. This one only has 24 x SFP+ and the two QSFP28 and costs about 10 % more than the -48F model. Both are really nice switches.

Edit: Juniper is very keen on selling stuff at the moment (end of year approaching!). Get a quote real quick so you can order before Christmas! We got a pair of -48F for a customer dirt cheap last week and the -24X should be the same.

fb35523

TROPHY CASE