IMO, a DMZ is always needed when a system is accessed from the internet. Based on the customer requirements I sometimes place the Webserver into the DMZ. More often, a reverse-proxy is placed in a DMZ and that system sends the requests to the server on the local LAN. I do this if the customer wants to have the server in his internal network for whatever reasons. For the really security-aware customers (well, most of them are not) both the reverse-proxy and the server is placed in separate DMZs. For the reverse-proxy, I personally like to use a Linux-box with NGINX. But that is only a personal preference.   EDIT: I would also place the Webserver and the Database in different DMZs. ... View more

Is this a modem that you use with PPPoE? At least my MX with v15 behaves a little bit strange. The first capture on the internet port has to be done with the filter "pppoes and ip" to see any result. After that, the capture works normally.   Can you ping the MX interface (make sure it is enabled on the firewall page) and can you see that ping in the packet capture? ... View more

What kind of device do you have in front of the MX? Perhaps something is filtered there. Because TCP 80/443 for sure can be forwarded. ... View more

What do you mean with packet capture not showing any hint. Do you see the traffic entering the MX on the internet port? ... View more

Are you shure that the problem is based on the lifetime? I‘m pretty sure that I run default lifetimes (which are either 1h or 8h; although this is not on the MX) with Azure connections and they are negotiated correctly. ... View more

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   ... View more

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. ... View more

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 ... View more

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. ... View more

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 ... View more

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. ... View more

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. ... View more

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. ... View more

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 ... View more

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

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. ... View more

@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? ... View more

@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. ... View more

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. ... View more

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!" ... View more

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. ... View more

@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. ... View more

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. ... View more

@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.   ... View more