topic Remote Access VPN and NAT inside interface in Network Security

Remote Access VPN and NAT inside interface

mahesh18 — Tue, 12 Mar 2019 03:53:50 GMT

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

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

Remote Access VPN and NAT inside interface

Jouni Forss — Thu, 06 Mar 2014 08:04:32 GMT

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

Re: Remote Access VPN and NAT inside interface

mahesh18 — Fri, 07 Mar 2014 02:02:29 GMT

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

Remote Access VPN and NAT inside interface

Jouni Forss — Fri, 07 Mar 2014 09:07:08 GMT

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

Re: Remote Access VPN and NAT inside interface

mahesh18 — Fri, 07 Mar 2014 13:22:41 GMT

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