Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2445
Views
0
Helpful
6
Replies

Remote Access VPN and NAT inside interface

mahesh18
Level 6
Level 6

‎03-04-2014 09:22 PM - edited ‎03-11-2019 08:53 PM

Hi everyone,

I have configured Remote VPN access.

Inside interface and vpn pool is 10.0.0.0 subnet.

ASA inside interface has NAT exempt as per config below

nat (inside,outside) source static NETWORK_OBJ_10.0.0.0_24 NETWORK_OBJ_10.0.0.0_24 destination static NETWORK_OBJ_10.0.0.0_25 NETWORK_OBJ_10.0.0.0_25 no-proxy-arp route-lookup

object network NETWORK_OBJ_10.0.0.0_24

subnet 10.0.0.0 255.255.255.0

object network NETWORK_OBJ_10.0.0.0_25

subnet 10.0.0.0 255.255.255.128

Also i have ASA inside interface connected to R1 as below

R1 ---10.0.0.2------------inside int  IP 10.0.0.1--------ASA

R1 has loopback int 192.168.50.1 and ASA has static route to it.

When i connect to remote access vpn i can ping the IP 192.168.50.1 from My pc which is connected to outside interface of ASA.

This ping works fine.

Mar 04 2014 21:58:27: %ASA-6-302020: Built inbound ICMP connection for faddr 10.0.0.52/1(LOCAL\ipsec-user) gaddr 192.168.50.1/0 laddr 192.168.50.1/0 (ipsec-user                                                                                        )

Mar 04 2014 21:58:28: %ASA-6-302021: Teardown ICMP connection for faddr 10.0.0.52/1(LOCAL\ipsec-user) gaddr 192.168.50.1/0 laddr 192.168.50.1/0 (ipsec-user) Mar 04 2014 21:58:27:

Need to understand how this ping works without exempting 192.168.50.0 from natiing

or

how does nat work for above ping from 10.0.0.52 VPN user PC IP to loopback interface of R1 in regards to NATing?

Regards

Mahesh

Labels:
0 Helpful
6 Replies 6

Jouni Forss
VIP Alumni
VIP Alumni

‎03-06-2014 12:04 AM

Hi Mahesh,

Could you do the following

  • Log in with the VPN and check the IP address that is assigned to your client PC
  • Use the "packet-tracer" command to simulate the ICMP above using the aboe mentioned VPN Client IP as the source

packet-tracer input outside icmp 8 0 192.168.50.1

Lets see if this producess some output that tells us what is happening. I would however presume that the situation might be one of the following for example

  • You have another NAT configuration that matches this traffic
  • You DONT have any Dynamic NAT/PAT configurations for the Loopback interface IP address which therefore lets you connect directly to it from the VPN Client as the Loopback interface IP address

And I think I need to clarfiy the second point above. What I mean by it is that you necesarily have not configured any Dynamic NAT/PAT rule for the Loopback interface IP address on the ASA and therefore ASA does not match any NAT configuration for the traffic TO and FROM the Loopback interface. This means that from the ASAs perspective this traffic is passed essentially like it had NAT0.

Now, the reason why you need the NAT0 configuration for the LAN network is that they have a Dynamic NAT/PAT configurations towards the "outside" interface. If you did not add any NAT0 configuration and the VPN Client attempted the connection then the ASA would drop the traffic as the ASA would check if any NAT configuration matches for the traffic going from the VPN Client to the LAN and from the LAN to the VPN Client (the reverse check). The reverse check would match the Dynamic NAT/PAT rule (if you had no NAT0) and therefore the ASA would drop the traffic.

If you want to use the "packet-tracer" to confirm if the Loopback interface has any NAT configuration on the ASA at all you can use this command for example

packet-tracer input inside icmp 192.168.50.1 8 0 8.8.8.8

Provided ofcourse that traffic is allowed through the ASA

So as I said I presume that you either have a NAT0 configuration for the Loopback interface IP address (or some wider rule that applies to it) OR you have absolutely no NAT configurations on the ASA matching the Loopback interface IP address and therefore the ASA does NO NAT for the traffic to and from the Loopback interface.

Hope this made any sense

Let me know what the above test show.

- Jouni

0 Helpful

mahesh18
Level 6
Level 6
In response to Jouni Forss

‎03-06-2014 06:02 PM

Hi Jouni,

IP address to PC is 10.0.0.52 ---------Assigned to Client PC.

Leting you  know that i have removed the NAT below config from inside to outside interface 

ASA inside interface has NAT exempt as per config below

nat (inside,outside) source static NETWORK_OBJ_10.0.0.0_24 NETWORK_OBJ_10.0.0.0_24 destination static NETWORK_OBJ_10.0.0.0_25 NETWORK_OBJ_10.0.0.0_25 no-proxy-arp route-lookup

object network NETWORK_OBJ_10.0.0.0_24

subnet 10.0.0.0 255.255.255.0

object network NETWORK_OBJ_10.0.0.0_25

subnet 10.0.0.0 255.255.255.128

Still ping works fine from VPN client PC to IP 192.168.50.1

Packet tracer output

ASA1# packet-tracer input outside  icmp 10.0.0.52 8 0 192.168.50.1

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   192.168.50.1    255.255.255.255 inside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit ip any host 192.168.50.1 log
access-list outside_access_in remark Allow Ping to Loopback IP of R1 Which is inside Network of ASA1
Additional Information:

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: CP-PUNT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

I can ping from PC command prompt to IP 192.168.50.1 fine.

Here is second packet tracer

ASA1# packet-tracer input inside icmp 192.168.50.1 8 0 8.8.8.8

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit ip any any
Additional Information:

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: DEBUG-ICMP
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: DEBUG-ICMP
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 18033, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

So question is how ping from outside is working without nat exempt from inside to outside?

So does second packet tracer proves that i have no NAT config from loopback to outside and ping works because i have NO NAT configured?

Regards

Mahesh

Message was edited by: mahesh parmar

0 Helpful

Jouni Forss
VIP Alumni
VIP Alumni
In response to mahesh18

‎03-07-2014 01:07 AM

Hi Mahesh,

Yes, as you can see from the second "packet-tracer" output there is no Phase for NAT so there is no translation for the source address 192.168.50.1. And this probably is no surprise as the Loopback interface probably in this situation does not need any connectivity to the external network.

An easy thing to test the above would be to temporarily configure Dynamic PAT for the Loopback interface IP address 192.168.50.1 and see if you could then PING the IP address from the VPN Client. You should not be able to do this without further adding a NAT0 / NAT Exempt for it OR removing the Dynamic PAT.

So as you can see from the above, you typically need NAT0 configuration only because if you did not configure NAT0 the traffic would match the Dynamic PAT and fail. And removing the Dynamic PAT naturally is not possible on a typical firewall as the users need that for Internet access. NAT0 is essentially used to bypass another NAT configurations in these cases. Since there is no NAT configurations for your Loopback interface it does not need NAT0 to bypass any Dynamic NAT/PAT rule.

If you had an ASA which only services VPN connections and NO users Internet connections you could simply leave the NAT configurations completely empty and the ASA would not perform any NAT on traffic.

Hope this helps

- Jouni

0 Helpful

mahesh18
Level 6
Level 6
In response to Jouni Forss

‎03-07-2014 05:22 AM

Hi Jouni,

For first packet tracer output need to confirm that it also does not hit the NAT rule  and there is no NAT translation  like second packet tracer output right?

Second thing need to confirm with you is on ASA there is no dynamic PAT configured.

I did test below

ASA1#                 ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/50 ms

logs show

Mar 07 2014 06:17:03: %ASA-6-302020: Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 192.168.1.171/61674 laddr 192.168.1.171/61674

Mar 07 2014 06:17:03: %ASA-6-302021: Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 192.168.1.171/61674 laddr 192.168.1.171/61674

Debug

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:

ICMP echo request from 192.168.1.171 to 8.8.8.8 ID=41725 seq=65382 len=72

!ICMP echo reply from 8.8.8.8 to 192.168.1.171 ID=41725 seq=65382 len=64

ICMP echo request from 192.168.1.171 to 8.8.8.8 ID=41725 seq=65382 len=72

!ICMP echo reply from 8.8.8.8 to 192.168.1.171 ID=41725 seq=65382 len=64

ICMP echo request from 192.168.1.171 to 8.8.8.8 ID=41725 seq=65382 len=72

!ICMP echo reply from 8.8.8.8 to 192.168.1.171 ID=41725 seq=65382 len=64

ICMP echo request from 192.168.1.171 to 8.8.8.8 ID=41725 seq=65382 len=72

!ICMP echo reply from 8.8.8.8 to 192.168.1.171 ID=41725 seq=65382 len=64

ICMP echo request from 192.168.1.171 to 8.8.8.8 ID=41725 seq=65382 len=72

!

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/50 ms

Above ping works because ASA is using the source IP of outside interface right?


ASA1# ping ins
ASA1# ping inside ?

  Hostname or A.B.C.D     Ping destination IPv4 address or hostname
  Hostname or X:X:X:X::X  Ping destination IPv6 address or hostname
 
ASA1# ping inside 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)

log shows

Mar 07 2014 06:19:52: %ASA-6-302020: Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 10.0.0.1/12162 laddr 10.0.0.1/12162

Mar 07 2014 06:19:52: %ASA-6-302021: Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 10.0.0.1/12162 laddr 10.0.0.1/12162

debug shows

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:

ICMP echo request from 10.0.0.1 to 8.8.8.8 ID=12162 seq=16887 len=72

ICMP echo reply from 8.8.8.8 to 10.0.0.1 ID=12162 seq=16887 len=64

?ICMP echo request from 10.0.0.1 to 8.8.8.8 ID=12162 seq=16887 len=72

ICMP echo reply from 8.8.8.8 to 10.0.0.1 ID=12162 seq=16887 len=64

?ICMP echo request from 10.0.0.1 to 8.8.8.8 ID=12162 seq=16887 len=72

ICMP echo reply from 8.8.8.8 to 10.0.0.1 ID=12162 seq=16887 len=64

?ICMP echo request from 10.0.0.1 to 8.8.8.8 ID=12162 seq=16887 len=72

ICMP echo reply from 8.8.8.8 to 10.0.0.1 ID=12162 seq=16887 len=64

?ICMP echo request from 10.0.0.1 to 8.8.8.8 ID=12162 seq=16887 len=72

ICMP echo reply from 8.8.8.8 to 10.0.0.1 ID=12162 seq=16887 len=64

?

Above ping fails because we have no Natting from inside to outside right?

Regards

Mahesh

Message was edited by: mahesh parmar

0 Helpful

Jouni Forss
VIP Alumni
VIP Alumni
In response to mahesh18

‎03-07-2014 05:47 AM

Hi,

Both of the earlier "packet-tracer" outputs show that there is NO NAT performed for the Loopback interface. The first "packet-tracer" fails though but that can be expected I guess since we are trying to simulate a connection that is supposed to arrive from a VPN connection.

Your "ping" tests don't really give clear picture of the NAT situation on your firewall. Notice that when you simply ping a destination IP address without specifying the ASA interface then the ASA will just use the IP address closest to the destination as the source IP address. There is no NAT involved as this traffic is generated by the ASA. You can't NAT traffic sourced from the ASA itself.

Notice also that when you define the "inside" interface in the "ping" command that no NAT configurations will be applied to this traffic because of the thing I mentioned above. ASA will not NAT its own interface IP address to another IP address when it generates some traffic (like the ICMP here)

So you can have a Dynamic PAT configuration but the "ping inside" command won't have its traffic NATed. It goes through the ASA simply with its original IP address.

Easiest thing to confirm these is naturally to look at the NAT configurations and confirm which interfaces and networks have NAT configured.

As I don't see your configurations I would suggest rather using "packet-tracer" to check what NAT gets applied to traffic.

For example if you have an internal IP address of 10.0.0.100 for example then you could check what NAT is applied to it when it connects to the Internet with the command

packet-tracer input inside tcp 10.0.0.100 12345 8.8.8.8 80

You should see a NAT Phase and it should tell you the NAT IP address used. If you dont have any NAT configurations for this internal network then you wont see any NAT Phase.

But with regards to your Router Loopback interface and its IP address I think that you simply dont have any NAT configuration that would apply to that IP address and thats why you are not needing a NAT0 configuration to be able to connect to it at the moment through your VPN.

- Jouni

0 Helpful

mahesh18
Level 6
Level 6
In response to Jouni Forss

‎03-07-2014 06:34 PM

Hi Jouni,

Here is the output from the ASA of packet tracer

ASA1# packet-tracer input inside tcp 10.0.0.2                      12345 8.8.88 80

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 2
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 20106, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Where 10.0.0.2 was IP of Router connected to ASA1.

As per your anwser seems NO nat is used above.

From Router R1 IP 10.0.0.2 i can ping 8.8.8.8.

You have explained very well one last thing to confirm is as per above info there is also No NAT from inside to outside

used.

Only NAT config on this ASA is for site to site VPN as per below

ASA1#               sh run nat

nat (inside,outside) source static NETWORK_OBJ_10.0.0.0_24 NETWORK_OBJ_10.0.0.0_24 destination static NETWORK_OBJ_10.2.0.0_24 NETWORK_OBJ_10.2.0.0_24 no-proxy-arp route-lookup description Site_To_Site_VPN NAT

Second thing to ask is when  i do ping inside 8.8.8.8  it does not work as traffic goes un Natted.

So is this default behaviour of the ASA?

What can i do to make this work?

Regards

MAhesh

Message was edited by: mahesh parmar

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking for a $25 gift card