Hi lpopejoy, that's interesting but I don't think my managers would allow me to use an unsupported feature in our environment. It may help others though, so thanks for posting. ... View more

I've not managed to crack this problem yet and I'm struggling to form a clear plan. Changing our IP address range is not possible, so I have to find an alternative way forward.   I have an MX60 here and my thoughts were that if I can perform the VPN termination and NAT on the MX100, then I'll split the tasks. Do you think it feasible to perform the VPN termination on the MX100 then pass the intermediate subnet over to the MX60 to be NATed to our local subnet?   If there's a guide out there on how to set this up that would be even better.   Thanks ... View more

Hi Philip, thanks, that makes things clearer. I'm not sure what the implications of using 192.168.2.0/23 would be as we are already using 192.168.5.0 through 192.168.6.254 as our DHCP range and we have other sites using 192.168.3.0/24 and 192.167.7.0/24.   This sounds like too big a change to make in a production environment so I may just suggest to my colleagues that we buy another firewall that is capable of using NAT for a VPN.   My inability to link our network to our client's is now affecting income streams, so the argument to drop some cash is there.   Thanks ... View more

Our current local VLAN is 192.168.0.0/21. The remote site also uses this subnet. However, we only actually use 192.168.2.0 and above, so I thought I could simply change our subnet to 192.168.2.0/21 and that would free up the first 512 addresses to route to the remote site.   When I make the change on the MX though, it stays at 192.168.0.0/21.   Can anyone help me understand where I'm going wrong?   Thanks ... View more

Hi Roger, an MX100 our side and we've tried a Sophos XG box and a Juniper at the client's site. Neither worked. ... View more

Hi Philip, the other end has configured NAT but this didn't work. They expressed the same opinion, that we need to configure NAT at our end as well. However, none of the Meraki engineers who have tried to help have suggested this and it appears not to be possible. The servers that need to talk to each other cannot easily be moved to a DMZ unfortunately. One is a production SQL server belonging to our client, the other an RDS server that our staff use to run a data analysis tool.   So I think that we will need to reduce the scope of our subnet. It's not that big a deal, but it would have been a lot simpler if we could have done the job with NAT. And what happens if we need to set up more VPN links to other clients and suppliers in the future? There's a high chance that there will be a clash that can't be got around this way.   So Meraki kit seems very limited in this respect. Meraki to Meraki VPN doesn't have this issue though, which is interesting. ... View more

Hey Nolan, don't feel too left out.   I've spent over three hours on support calls with four different Meraki engineers over this and none of them was seemingly aware of this fact either.   LOL ... View more

Hi Robin, that was one thing I did consider. However, after further discussion, we've decided that we can reduce our local subnet as we are using a /21 mask so have plenty of addresses spare.   Thanks ... View more

Hi Roger, thanks for your reply. That's what I thought too. The other site have done so on their Sophos XG box but as you say, I'm not sure how to assign a NAT rule to a VPN tunnel. ... View more

Security Center logging is now down to two weeks. Are sales of Stealthwatch Cloud too slow for Cisco I wonder? ... View more