NAT configuration problem, stopping OSX VPN communication.

[rgaasbeek]

Hi,

This  is my first time posting in this forum. I am  having trouble getting  Mac computers (my test is OSX 10.8.2) to properly  connect to our  company's VPN. We have a Cisco ASA5510 which handles the  VPN requests.  Here are some details:

--Windows  computers, running Cisco VPN Client (not  Anyconnect) are able to  connect to the VPN and access internal  computers/fileserver etc, just  as we'd like them to.

--Mac's can establish a VPN connection, but  cannot communicate  with internal machines or servers. I cannot connect  to or ping the  fileserver using its IP address. I also cannot ping my  personal work  computer.

--BUT, from my work computer I CAN ping  the Mac's ip  address which it received after connecting via VPN. So,  internal Windows  PC can ping external VPN'd Mac, but Mac cannot ping  internal Windows  pc.

Using  ASDM I was able to start up Packet Tracer. I  had it trace a ping from  the Windows machine address 192.168.0.52 /23 to  the Mac's VPN address  192.168.5.33 /24. This was successful.

Using Packet Tracer to  trace a ping from the Mac's VPN address of  192.168.5.33 /24 to the  Windows address of 192.168.0.52 /23 is not  successful. The packet goes  through the following phases: "Capture",  "Access-list", "Route-Lookup",  "Access-List", "IP Options", "Inspect",  "Inspect", "Debug-ICMP",  "NAT-Exempt", until it reaches "NAT" where I  get this message:

Type - NAT    Action - Drop

Config

nat (inside1) 1 0.0.0.0 0.0.0.0

match ip inside1 any inside1 any

dynamic translation to pool 1 (192.168.1.1 [Interface PAT])

translate_hits = 913403, untranslate_hits = 27

Result is the packet is dropped.

Info: (acl-drop) Flow is denied by configured rule

I'm   not super familiar with ACL's or NAT configuration, so I am not sure what change I need to   make to get this to work properly. I also find it strange that the   Windows pc's using the Cisco client have no problem communicating   internally after connecting, but Mac's using the Mac integrated Cisco   IPSEC VPN are unsuccessful.

Any help would be greatly appreciated.

-Ramai

P.s. I included a screenshot of the Packet Tracer screen.

[rgaasbeek]

Hey Jennifer,

I changed the subnet on my home network to be 192.168.8.1 instead of 192.168.1.1 and am now able to ping and access the fileserver at 192.168.1.50! What a silly problem. It's unfortunate that most private networks are 192.168.1.1 networks by default, and I guess that most of my mac end users have these networks and were thus experiencing this problem.

Thanks for your help in diagnosing this problem, I appreciate it. Now I just have to figure out why I can't access my ASA5510 anymore I have created a new discussion here:

https://supportforums.cisco.com/thread/2178511

[Jennifer Halim]

Since you are using DHCP to assign IP to your internal subnet, maybe it is a good idea to configure a different subnet for your internal ASA network, so it doesn't overlap with home network as home network is very often by default in 192.168.0.0/24 subnet.

[rgaasbeek]

I agree with you, but due to the nature of our set up I'm leaning toward having the remote Mac users (only a handful of people) change their home set up. The reason being is our 192.168.0.0/23 network gives out DHCP for the 192.168.0.X portion of addresses, but we have a lot of devices with static IPs on the 192.168.1.X portion. Thank you for your suggestion though. If we ever get a large surge in remote Mac users we'll have to figure things out haha.

[rgaasbeek]

To answer your other questions:

The Mac I am using for testing is connected on a remote network via wireless.

Here is the output of the show cry command as you directed:

ciscoasa# show cry ipsec sa peer 72.***.***.56

peer address: 72.***.***.56

    Crypto map tag: dynmap, seq num: 1, local addr: 98.***.***.57

      local ident (addr/mask/prot/port): (192.168.0.0/255.255.254.0/0/0)

      remote ident (addr/mask/prot/port): (192.168.5.35/255.255.255.255/0/0)

      current_peer: 72.***.***.56, username: R*********k

      dynamic allocated peer ip: 192.168.5.35

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

      #pkts compressed: 0, #pkts decompressed: 0

      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0

      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

      #send errors: 0, #recv errors: 0

      local crypto endpt.: 98.***.***.57/4500, remote crypto endpt.: 72.***.***.56/4500

      path mtu 1500, ipsec overhead 66, media mtu 1500

      current outbound spi: 062A311E

      current inbound spi : 02C48356

    inbound esp sas:

      spi: 0x02C48356 (46433110)

         transform: esp-3des esp-md5-hmac no compression

         in use settings ={RA, Tunnel,  NAT-T-Encaps, }

         slot: 0, conn_id: 2334720, crypto-map: dynmap

         sa timing: remaining key lifetime (sec): 3514

         IV size: 8 bytes

         replay detection support: Y

         Anti replay bitmap:

          0x00000000 0x00000001

    outbound esp sas:

      spi: 0x062A311E (103428382)

         transform: esp-3des esp-md5-hmac no compression

         in use settings ={RA, Tunnel,  NAT-T-Encaps, }

         slot: 0, conn_id: 2334720, crypto-map: dynmap

         sa timing: remaining key lifetime (sec): 3513

         IV size: 8 bytes

         replay detection support: Y

         Anti replay bitmap:

          0x00000000 0x00000001

[Brian McPhillips]

Has anyone played about with inserting static routes when the mac is connected to the vpn to resolve this issue or tested with another mac vpn client

We have a customer with servers in the 192.168.1.0 range and this will conflict every time their end users are in a public internet zone. They would be reluctact to change their server IPs. I can't see many other options for them.