I would love to get another backup ISP but this one took a year, even with multiple hiccups with our current ISP. I think I will try moving the Primary uplink to WAN2 initially and then after testing possibly physically move this to WAN1 when our current circuit is disconnected. Thanks! ... View more

Because of all of the stability issues, I was going to use this backup as our primary and then have our current primary as the backup but with the current primary being disconnected in a couple of months, this new backup will be our only internet connection and will most likely stay our primary. We are using a MX250 so we do have the dedicated WAN2 port. At this point, I'm thinking of making WAN2 the primary uplink and changing the few external DNS pointers for testing over the next month and if all goes well, when the current primary is disconnected I may move this backup to WAN1. I just wanted to make sure there were not any major things to watch for. Thanks! ... View more

@JessIT1 wrote: I also received those IP's.  However I recently replaced 3 of my firewalls that could no longer could receive firmware updates, and now the Zyxel unauthenticated IKEv2 command injection attempt and Zyxel unauthenticated IKEv2 overflow attempts that have been plaguing our MX's since February now show blocked instead of allowed..so I guess getting these MX's up to the latest MX 18.211.2 version allowed the  Intrusion detection and prevention to block..strange.   FWIW, we are using MX250s, updated to 18.211.2, and it's still showing as allowed on ours. We are not over-utilized either. ... View more

We've been experiencing the same thing. I opened a ticket with Support and this was their initial response. "The traffic in question is targeting the MX public IP and a non used port. This traffic is indeed didn't advance.  Since there is no advancement, to a two way traffic the internal blocker doesn't detect anything to block so the default value for the traffic will be marked as "allowed".  "Allow" statement doesn't mean the traffic was allowed in. It is just the default value when no two-way bad traffic flow was detected.  I added a Layer 7 Deny rule for the IP that was hitting us and a day or two later, we saw the same Allow status from the same IP. I questioned support about this and below is their response to that. "There is no NAT/Port forwarding Rule that will allow any income traffic to pass over to he LAN side.  The traffic in questions is hitting the MX WAN side and never advanced either by a reply from the MX or by passing it over to any LAN client.  Default value for such criteria is "Allowed".  When adding a Layer 7 rule, it will not affect the behavior of the IDS/IPS since it is on a different category of blocking. Filter event logs using "layer 7 firewall rules". It shows  no traffic detected for that newly added L7 rule to block.  Which means no advancement to any LAN host. "   ... View more

I know this is not going to help but we ended up getting our bandwidth upgrade soon after my first post and that solved all of our problems. ... View more

I did add the All VoIP definition but not the defaults. It has not seemed to help so I'm wondering if there is something on the switches that need to be set too. ... View more

Thanks, cmr. Next time I'm in the office on the weekend I'll plug everything in and we'll see how it goes. Thanks for the quick responses. ... View more

Thanks, cmr. Going by the Cisco docs, once the RPS is powered up with the cables connected to it all you need to do is plug an RPS cable into each switch. I just wanted to make sure there were not any gotcha's to watch out for. Do you guys run yours in Active or Standby mode? Didn't know if there was a best practice for that. ... View more