cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1332
Views
0
Helpful
5
Replies

Hairpinning remote access vpn-Ipsec inside host not accessible.

searskarthik
Level 1
Level 1

               Team,

I am having issue in Hairpinning vpn confiuration.

ASA Version 8.2(3)5

the only issue is ,from remote access vpn clinet IP unable to access inside hosts.However able to reach branch office IP's and it's using corprate Internet.

In ASA from outside interface I am  able to ping  remote clint IP's but not  from inside inteface. please help and let me know if additional info is required.

thanks

Karthik

1 Accepted Solution

Accepted Solutions

Hi,

For the NAT0 configuration, you should only need the NAT0 statement for the "inside" interface

That command/ACL alone should make it possible for "inside" <--> "vpn-pool" communcation.

NAT0 configurations on the "outside" interface should only be needed if you are doing NAT0 between 2 VPN connections. I guess you might be doing this since you are talking about hairpinning traffic?

I would suggest using different "object-group" to define the NAT0 destination networks for the "inside" users and different "object-group" for the "outside" to "outside" NAT0.

I would also suggest avoinding using too wide network ranges in the NAT0 statements. According to some documents they might cause problems

For example this network "network-object 172.16.0.0 255.240.0.0" contains the whole 172.x.x.x.x private IP address range. And in this case it contains some of your "inside" networks too?

How is this a hairpinning problem by the way? You say the problem is between the VPN clients on the "outside" interface and the LAN hosts behind the "inside"? Hairpinning would mean you have connection problem between "outside" <-> "outside" perhaps.

I don't know if I made any sense. Might be a bit messy. But can't give really specific answers as I dont know the whole configuration.

Also check that you have the "inspect icmp" configured under the global policy-map so that ICMP echo reply messages are automatically allowed through the ASA.

- Jouni

View solution in original post

5 Replies 5

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

This would be easier to troubleshoot if you provide the following information

  • The ASA configurations (remove any sensitive information)
  • Source IP and destination IP address of the attempted connection
  • The service used to test connections (ICMP, TCP/UDP port)

You might be missing some NAT configurations perhaps if the traffic is otherwise allowed.

- Jouni

Thanks Jouni for your quicke response, my apologizes at this moment not sharing the full config. I should get approval.

object-group network vpn_internal

network-object 10.0.0.0 255.0.0.0

network-object 148.162.0.0 255.255.0.0

network-object 151.149.0.0 255.255.0.0

network-object 172.16.0.0 255.240.0.0

network-object 192.168.0.0 255.255.0.0

network-object 172.29.64.0 255.255.240.0

access-list no_nat extended permit ip object-group vpn_internal vpn_pool_172.29.65.0_24 255.255.255.0

access-list outside_nat0_outbound extended permit ip vpn_pool_172.29.65.0_24 255.255.255.0 object-group vpn_internal

global (outside) 1 XXX.XXX.XXX.67 netmask 255.255.255.224

nat (outside) 0 access-list outside_nat0_outbound

nat (outside) 1 vpn_pool_172.29.65.0_24 255.255.255.0

nat (inside) 0 access-list no_nat

nat (inside) 1 0.0.0.0 0.0.0.0

Our inside subnet is 172.29.64.0/20 (in vpn_internal is included)  reomote vpn pool 172.29.6o 5.0/24 , however this is part of our internal subnet. whether is this an issue?

from VPN pool  (172.29.65.0 /24) trying to reach  172.29.66.0/24.

Sh route output:

S   172.29.65.160 255.255.255.255

           [1/0] via XXX.XXX.XXX.XXX.65, outside

S   172.29.65.161 255.255.255.255

           [1/0] via XXX.XXX.XXX.XXX.65, outside

S   172.29.65.162 255.255.255.255

           [1/0] via XXX.XXX.XXX.XXX.65, outside

Show NAT:-outside

match ip outside vpn_pool_172.29.65.0_24 255.255.255.0 outside 172.16.0.0 255.240.0.0

   NAT exempt

   translate_hits = 678, untranslate_hits = 24

match ip outside vpn_pool_172.29.65.0_24 255.255.255.0 outside 192.168.0.0 255.255.0.0

   NAT exempt

   translate_hits = 0, untranslate_hits = 0

match ip outside vpn_pool_172.29.65.0_24 255.255.255.0 outside 172.29.64.0 255.255.240.0

   NAT exempt

   translate_hits = 0, untranslate_hits = 0

match ip outside vpn_pool_172.29.65.0_24 255.255.255.0 outside any

   dynamic translation to pool 1 (XXX.XXX.XXX.67)

   translate_hits = 46931, untranslate_hits = 9388

Nat Inside:

match ip inside 172.16.0.0 255.240.0.0 inside vpn_pool_172.29.65.0_24 255.255.255.0

   NAT exempt

   translate_hits = 14, untranslate_hits = 0

match ip inside 192.168.0.0 255.255.0.0 inside vpn_pool_172.29.65.0_24 255.255.255.0

   NAT exempt

   translate_hits = 0, untranslate_hits = 0

match ip inside 172.29.64.0 255.255.240.0 inside vpn_pool_172.29.65.0_24 255.255.255.0

   NAT exempt.

thanks

Karthik

Hi,

For the NAT0 configuration, you should only need the NAT0 statement for the "inside" interface

That command/ACL alone should make it possible for "inside" <--> "vpn-pool" communcation.

NAT0 configurations on the "outside" interface should only be needed if you are doing NAT0 between 2 VPN connections. I guess you might be doing this since you are talking about hairpinning traffic?

I would suggest using different "object-group" to define the NAT0 destination networks for the "inside" users and different "object-group" for the "outside" to "outside" NAT0.

I would also suggest avoinding using too wide network ranges in the NAT0 statements. According to some documents they might cause problems

For example this network "network-object 172.16.0.0 255.240.0.0" contains the whole 172.x.x.x.x private IP address range. And in this case it contains some of your "inside" networks too?

How is this a hairpinning problem by the way? You say the problem is between the VPN clients on the "outside" interface and the LAN hosts behind the "inside"? Hairpinning would mean you have connection problem between "outside" <-> "outside" perhaps.

I don't know if I made any sense. Might be a bit messy. But can't give really specific answers as I dont know the whole configuration.

Also check that you have the "inspect icmp" configured under the global policy-map so that ICMP echo reply messages are automatically allowed through the ASA.

- Jouni

object-group network vpn_internal

network-object 10.0.0.0 255.0.0.0

network-object 148.162.0.0 255.255.0.0

network-object 151.149.0.0 255.255.0.0

network-object 172.16.0.0 255.240.0.0

network-object 192.168.0.0 255.255.0.0

network-object 172.29.64.0 255.255.240.0

Yes I am  doing NAT 0 between  two vpn connections (BOLD) all IP belongs to our corprate VPN.

only 172.29.64.0 /20 belongs to my interenal network. However 172.29.65.0/24 (remote VPN pool) also falls under this subnet.This could be one the issue.

As you suggested  nat (inside) 0  I need sepcific network (like 172.29.66.0/24 and 172.29.69.0/24 )

!

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum client auto

  message-length maximum 512

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect netbios

  inspect rsh

  inspect skinny 

  inspect esmtp

  inspect sqlnet

  inspect sunrpc

  inspect tftp

  inspect xdmcp

  inspect icmp

  inspect ip-options

  inspect rtsp

  inspect sip 

class tcp-traffic

  set connection advanced-options allow-probes

class global-class

  flow-export event-type all destination XXXX.XXXXX.XXXXX.XXXX

class global-class1

  csc fail-open

!

Really your inputs much helped to me to work further. I will update once i made tesing on this week end.

But I have configured SSL  webvpn also , using any coonect vpnclient able to reach inside hosts.

thank you for great timely response.

-Karthik

Jouni,

Its resolved now .

after removing   from HO no_nat (network-object 172.16.0.0 255.240.0.0). Not  from vpn_internal similar way my HO no_nat having this subnet.

Phase: 7

Type: NAT-EXEMPT

Subtype:

Result: ALLOW

Config:

  match ip inside 172.29.64.0 255.255.240.0 inside vpn_pool_172.29.65.0_24 255.255.255.0

    NAT exempt

    translate_hits = 1, untranslate_hits = 0

Additional Information:

before removal of network-object 172.16.0.0 255.240.0.0

Phase: 7

Type: NAT-EXEMPT

Subtype:

Result: ALLOW

Config:

  match ip inside 172.29.64.0 255.255.240.0 outside 172.16.0.0 255.240.0.0

    NAT exempt

    translate_hits = 219900, untranslate_hits = 150420

Additional Information:

Now I am able to access inside hosts.

thanks

Karthik