Meraki

KarstenI · ‎Sep 28 2020

I am not aware of any way to change the port and you would likely have many problems with the clients to use these changed ports. I would start with a packet-capture to see if a) the client packets leave the client b) arrive at the MX c) there is an answer-packet leaving the MX d) it comes back to the client

KarstenI · ‎Sep 28 2020

Although the lifetimes are different, there is typically no problem with this. In IKEv1 the Phase 1 and Phase 2 lifetimes are negotiated to the lower of both values.

KarstenI · ‎Sep 28 2020

That is right, both need only one license in HA.

KarstenI · ‎Sep 27 2020

For the Network 192.168.99.0/24 you need to add this network to your s2s VPN a route pointing to the s2s-tunnel on the remote network a route pointing to the local MX on the PFsense gateway

KarstenI · ‎Sep 26 2020

All what you find on the WLAN configuration is automatically applied. This includes the SSID settings. IP-settings are done per AP. If you want that the new AP has the same IP as the old one, this has to be done manually.

KarstenI · ‎Sep 26 2020

Nothing to do here as the config is assigned to the network and not the individually AP. Add the new one to the network and it will directly fetch the config. The old one can be removed. What has to be applied additionally: IP-information if needed (for example if you use WPA-Enterprise). RF-Profiles Tags for the SSID availability

KarstenI · ‎Sep 25 2020

Actually, there is nothing comparable to the MR16 anymore. Without knowing anything about your environment, I would first look at the MR36 which is Wifi6, and probably supported for a very long time.

KarstenI · ‎Sep 25 2020

I just see that your PFsense device is part of your internal network. This can give you asymmetric routing to/from your external network. Better put the PFSense box in a dedicated DMZ and configure the routing as mentioned.

KarstenI · ‎Sep 25 2020

Yes, you need static routes to the remote network pointing to the PFsense IP. And the PFsense firewall needs a route for your internal network to the MX IP.

KarstenI · ‎Sep 24 2020

All traffic specified in NAT rules is automatically allowed. For outbound traffic, generally, the MX IP is used. But for 1:1 rules the specific public IPs are used. https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Configuring_1%3A1_NAT https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Troubleshooting_Port_Forwarding_and_NAT_Rules

KarstenI · ‎Sep 24 2020

You have to set it according to the bandwidth. It's not done automatically.

KarstenI · ‎Sep 24 2020

What you configure there should be set to the ISP-bandwidth or slightly lower so that the MX knows how to apply QoS. If the value is larger than committed by the ISP, it at least will not limit your throughput but is also not optimal.

KarstenI · ‎Sep 24 2020

@Mohammad wrote: yes , I have done speed test and utilization, it only show current scenario, but didn't get what is signed and commitment from ISP. Ask the ISP if they have a speedtest-server in their network. With that you take the connections to other ISPs out of the equation. And make sure that none of your devices is limiting the bandwidth. Do you measure consistent lower throughput or is it only sometimes?

KarstenI · ‎Sep 24 2020

@Mohammad wrote: One quick question, is there any way we can see what is my uplink Bandwith ? Generally speaking, no! Your contract can tell you what you should have, speed tests and monitoring tells you what you really have.

KarstenI · ‎Sep 24 2020

Again, many "it depends" ... The AP can tell the client that other APs are candidates to roam to, this is 802.11k and has broad support at least on devices found on enterprise networks. iOS has it since version 6 or 7 (don't remember exactly). But knowing these other APs is of no value if they are not yet in range of the client with the minimum rate.

KarstenI · ‎Sep 24 2020

Typically I start with 12Mbps and then the WLAN gets evaluated (if not done before). Most of the time it ends up on 24 Mbps which often is a reasonable compromise and typically works very well. But as always: "It depends!"

KarstenI · ‎Sep 24 2020

Any Device vendor can decide on its own how to implement QoS and what it's defaults are. You should check each device individually for a correct QoS-configuration.

KarstenI · ‎Sep 24 2020

@PhilipDAth wrote: How would having a third party manage it change your liability? You are still providing the service. At least the big providers in Germany tunnel the WLAN traffic to their DCs and go to the internet with the provider's IPs. So for the outer world, all traffic originates at the provider.

KarstenI · ‎Sep 23 2020

Here is what I would do in that case: 1) Ask the ISP for a /29. Could cost some bucks but would be the best solution. 2) If not possible, think about the MG21. Yes, it is expensive, but you could connect the device to both MXes WAN2. You have more redundancy on the primary MX and the spare MX has dashboard connectivity. 3) If that is also not possible, there are probably no options than using cold standby. Better than no redundancy.

KarstenI · ‎Sep 23 2020

@DarrenOC wrote: Hi @redsector Do you have a couple of Layer 3 switch's to hand (stackable)? Place these infront of your MX's. Here the L3-switches had to do the NAT. Makes the switch-options to pick from quite limited.

KarstenI · ‎Sep 23 2020

Well, different products behave differently. Given that the feature-set especially of the MX is quite restricted, good planning is more important than ever.

KarstenI · ‎Sep 23 2020

@redsector wrote: But what I see is that both MXes are spaking with that WAN IP address. Yes, both have a connection to the dashboard. It is completely different compared to for example an ASA where you can configure it with only one usable public IP.

KarstenI · ‎Sep 23 2020

I never implemented a VPN to Zscaler and I also try to avoid Aggressive mode where possible ... You mention that you use the "User FQDN" as both the local and remote ID. That is probably not correct, as the remote ID is the string that the ZScaler has configured as a local ID.

KarstenI · ‎Sep 23 2020

This is not how MX HA works. Both units need individual connections to the internet, you can not share one IP on both appliances. Two/three solutions come to mind: 1) use a separate IP for the second MX 2) Use a different ISP on the spare MX, that could be e simple LTE-router just for dashboard connectivity, and in case of primary MX failure, you connect the primary ISP to the second MX 3) Use the second MX as a cold spare

KarstenI · ‎Sep 22 2020

As a test, can you change the printer from plain SMTP to SUBMISSION (tcp/587 with username/password)?

About KarstenI

KarstenI

Karsten Iwen

Community Record

Badges