Networking-Blog

My WordPress Blog

MERAKI CONFIG

Context:

Corporate network is on 172.31.0.0/16

Public network is on 192.168.0.0/16 (I think /16 could be /20)

Task was to configure Meraki MR76 to advertise both the corporate network (on native vlan of 20) and the public network on vlan 45. Meraki requires full cloud connectivity to pull its config, which requires external connectivity i.e., Internet access. Below is a brief outline of things I tried:

  • Configuring the port, the Meraki connected to as a trunk, allowing all vlans and setting the native trunk as 20 (corporate vlan) This allowed the Meraki to receive a DHCP address within the 172.31/16 range HOWEVER it did not have connectivity to the cloud. It did however have full corporate connectivity, tested by pinging edge routers ingress interfaces. HTTP traffic leaving the corp. network requires the use of a proxy, as there are no NAT rules for a scope of addresses in 172.31/16 (Meraki included) only a single static NAT rule for traffic sourced from the proxy server (this is key to finding the solution).
  • Similar to above, I had also tried configuring the trunk’s native vlan to 45 (public/visitor vlan) which isn’t governed by the proxy NOR the firewall, it traverses through a “BT Managed Hub” before entering the WAN. I had full internet connectivity and access to the Meraki dashboard, which was great, until I realised the Meraki was placed in the 192.168.0.0/16 network which is not the network I need it to advertise. I would imagine there is PAT or dynamic NAT configured on this hub to translate addresses in the 192.168.0.0/16 network.
  • Configuring the port as an access-port in both vlan 20 and 45 (corp. and public). This essentially had the same outcome as configuring trunk ports.
  • Adding to an existing firewall zone-based policy to permit cloud traffic from the Meraki to the Meraki public cloud. I still believe this was required although I haven’t had the ability to check if this was required or not, as I had configured the additional class map BEFORE I had found the final solution. Within the Wiki is where you’ll find the zone-fw config.

Class-map applied to overall policy-map “INSIDE-TO-OUTSIDE-POLICY”

  • I decided to look, once again, at the running config of the Cisco 4351 (our edge router/firewall) which is where WAN traffic traverses. Because my issue was essentially Internet connectivity on vlan 20 (corporate) I homed in on the NAT config. This is what I saw:
Show ip nat translations – shows the current binding between static LAN addresses and their corresponding public address.

Now, as you can see that’s not a lot of static routes for a company that hosts 1000s of network devices and PAT or dynamic NAT was not configured. Then it hit me, THE PROXY SERVER!! two of these addresses you see above are actually statically assigned to translate the source address of our proxy servers which account for 100s of devices. The Meraki will not hit the proxy server, and therefore NOT have its source address changed, for cloud communication it requires TCP, UDP and ICMP NOT HTTP(s).

Because the Meraki requires cloud connectivity to pull its config, I was tasked with finding out the address it was handed out by DHCP – look below:

DHCP administrator tools

It is named “meraki ap” because I recently changed it. I then created a static route from the ap to a public address:

Confirmed meraki was receiving a static nat entry

Added an extra SSID on the meraki for public wifi using vlan 45 within the 192.168.0.0/16 network for unfiltered guest traffic also showcasing (on the left) the native config using vlan 20:

See the top right for “android-5” (my phone) using the public wifi.

More still to be done, TBC….

Cisco Traversing a NAT device

 

Using NAT Traversal

Network Address Translation (NAT) and Port Address Translation (PAT) are implemented in many networks where IPSec is also used, but the number of incompatibilities that prevent IPSec packets from successfully traversing a NAT device.

PIX Firewall Version 6.3 provides a feature called “Nat Traversal,” as described by Version 2 and Version 3 of the draft IETF standard, UDP Encapsulation of IPsec Packets,” which is available at the following URL:

http://www.ietf.org/html.charters/ipsec-charter.html

NAT Traversal allows ESP packets to pass through one or more NAT devices. This feature is disabled by default.

Note NAT Traversal is supported for both dynamic and static crypto maps.

To enable NAT traversal, enter the following command:

isakmp nat-traversal [natkeepalive]
isakmp nat-traversal 20

Valid values for natkeepalive are 10 to 3600 seconds; the default is 20 seconds.

 

Enabling IPsec over NAT-T

NAT-T lets IPsec peers establish a connection through a NAT device. It does this by encapsulating IPsec traffic in UDP datagrams, using port 4500, thereby providing NAT devices with port information. NAT-T auto-detects any NAT devices, and only encapsulates IPsec traffic when necessary. This feature is disabled by default.

• The security appliance can simultaneously support standard IPsec, IPsec over TCP, NAT-T, and IPsec over UDP, depending on the client with which it is exchanging data.

• When both NAT-T and IPsec over UDP are enabled, NAT-T takes precedence.
• When enabled, IPsec over TCP takes precedence over all other connection methods.
• When you enable NAT-T, the security appliance automatically opens port 4500 on all IPsec enabled interfaces.

The security appliance supports multiple IPsec peers behind a single NAT/PAT device operating in one of the following networks, but not both:

• LAN-to-LAN
• Remote access

In a mixed environment, the remote access tunnels fail the negotiation because all peers appear to be coming from the same public IP address, that of the NAT device. Also, remote access tunnels fail in a mixed environment because they often use the same name as the LAN-to-LAN tunnel group (that is, the IP address of the NAT device).
This match can cause negotiation failures among multiple peers in a mixed LAN-to-LAN and remote access network of peers behind the NAT device.

Cisco IP NaTing Source Outside

ip nat outside source static 172.16.10.20 10.11.254.212
ip nat outside source static 172.16.10.24 10.11.254.213
ip nat outside source static 172.16.10.25 10.11.254.216
ip nat outside source static 172.16.10.75 10.11.254.214
ip nat outside source static 172.16.10.76 10.11.254.215
!
!
ip route 0.0.0.0 0.0.0.0 1.1.1.1 (Wan Interface)
ip route 10.11.0.0 255.255.0.0 10.11.254.254 (Local LAN Gateway)
ip route 10.11.254.212 255.255.255.255 1.1.1.1
ip route 10.11.254.213 255.255.255.255 1.1.1.1
ip route 10.11.254.214 255.255.255.255 1.1.1.1
ip route 10.11.254.215 255.255.255.255 1.1.1.1
ip route 10.11.254.216 255.255.255.255 1.1.1.1