cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1886
Views
5
Helpful
9
Replies

Routing across ASA / NAT

prusieck
Level 1
Level 1

Hi,

I have searched high and low over the last few days and couldn't find exact answer that would actually work in my case. I have the following setup:

Capture.PNG

Essentially the network connectivity to my home is presented via 'business line' router that offers a modem mode that negotiates a GRE tunnel presenting a /29 network with a gateway marked on the leftmost router.

Onwards connectivity is provided via Layer 2 unmanaged switch that has a regular run of the mill router dishing out addresses in 192.168.1.0/24 and doing what I assume is basic NAT, as the DHCP dishes out gateway of x.x.223.121. It by itself as a public IP address of .122. Also, there's ASA connected to that switch that takes an address .123 (running version 9.1 hence the new NAT style)

Behind the ASA sits my home lab (I'm currently training for CCNA, so ASA seemed a bit deep jump to go for, but I could get one very cheaply) defined on a DMZ interface. the ASA has two other interfaces - outside with the public address and inside with a 192.168.1.181/24 address. Lastly, there's a console server build on old 2511 that sits on 192.168.1.180/24. What I am aiming to achieve is to telnet/ssh through the ASA to the ingress router to my lab (SSH) or to the Console (telnet, I know.... doesn't support SSH).

I have broadly followed a documented guide with some degree of success - can PM a link as my first post go auto-flagged for SPAM so I'd rather avoid that again...

The relevant bits of config on ASA:

Configuration on interfaces:

interface Ethernet0/0
speed 1000
nameif outside
security-level 0
ip address x.x.223.123 255.255.255.248
!
interface Ethernet0/1
nameif dmz
security-level 50
ip address 10.99.99.1 255.255.255.252
!
interface Ethernet0/2
nameif inside
security-level 100
ip address 192.168.1.181 255.255.255.0
!

There are network objects configured, with static NAT:

object network console
host 192.168.1.180
nat (inside,outside) static x.x.223.124

object network R1
host 10.99.99.2
nat (inside,outside) static x.x.223.125

And there is also the access list that's applied as a single group to the outside interface

access-list inbound extended permit tcp any host 192.168.1.180
access-list inbound extended permit tcp any host 10.99.99.2
access-group inbound in interface outside

When I run packet tracer it all looks reasonably where to simulate access from the outside to the object in question, same result on both - the other omitted for brevity:

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network console
nat (inside,outside) static x.x.223.124
Additional Information:
NAT divert to egress interface inside
Untranslate x.x.223.124/22 to 192.168.1.180/22

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inbound in interface outside
access-list inbound extended permit tcp any host 192.168.1.180
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: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network console
nat (inside,outside) static x.x.223.124
Additional Information:

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

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

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

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

However, when I perform external ping (ping allowed on all interfaces of ASA) or try to check the port 22 - I get failures, despite the ASA external interface being happy:

--- PING x.x.223.123 (x.x.223.123) 56(84) bytes of data. ---
64 bytes from x.x.223.123: icmp_seq=1 ttl=244 time=37.8 ms
64 bytes from x.x.223.123: icmp_seq=2 ttl=244 time=38.1 ms
64 bytes from x.x.223.123: icmp_seq=3 ttl=244 time=36.8 ms
64 bytes from x.x.223.123: icmp_seq=4 ttl=244 time=38.1 ms


--- x.x.223.123 ping statistics ---


packets transmitted 4
received 4
packet loss 0 %
time 3005 ms



--- Round Trip Time (rtt) ---


min 36.880 ms
avg 37.753 ms
max 38.171 ms
mdev 0.518 ms

But neither of the NAT'ed devices:

 

--- PING x.x.223.124 (x.x.223.124) 56(84) bytes of data. ---


--- x.x.223.124 ping statistics ---


packets transmitted 9
received 0
packet loss 100 %
time 8316 ms

Interestingly when I check the NAT statistics I can see successful hits, but nothing comes back:

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static R1 x.x.223.125
translate_hits = 0, untranslate_hits = 122
2 (inside) to (outside) source static console x.x.223.124
translate_hits = 0, untranslate_hits = 236

On the flipside, when pinging out from R1 - no translate hist, but this isn't the case for the console (although in various attempts I had seen a hit of two on R1 as well):

 

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static R1 x.x.223.125
translate_hits = 0, untranslate_hits = 127
2 (inside) to (outside) source static console x.x.223.124
translate_hits = 5, untranslate_hits = 246

What this makes me think is that somehow the route back is not working from the external devices to ASA, via respectively the default gateway on the console (no routing enabled) or via the default route on R1

 

R1 - static route configured to point back to 10.99.99.1 (and rest either directly connected or learned via egirp)

 

Gateway of last resort is 10.99.99.1 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 10.99.99.1
10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks
C 10.0.10.0/30 is directly connected, Serial0/1/0
L 10.0.10.1/32 is directly connected, Serial0/1/0
D 10.0.20.0/30 [90/2681856] via 10.0.30.2, 00:51:39, Multilink1
[90/2681856] via 10.0.10.2, 00:51:39, Serial0/1/0
C 10.0.30.0/30 is directly connected, Multilink1
L 10.0.30.1/32 is directly connected, Multilink1
C 10.0.30.2/32 is directly connected, Multilink1
C 10.5.1.0/24 is directly connected, Loopback1
L 10.5.1.1/32 is directly connected, Loopback1
D 10.5.2.0/24 [90/2297856] via 10.0.10.2, 00:51:39, Serial0/1/0
D 10.5.3.0/24 [90/1468928] via 10.0.30.2, 00:51:39, Multilink1
C 10.99.99.0/30 is directly connected, FastEthernet0/1
L 10.99.99.2/32 is directly connected, FastEthernet0/1
D 192.168.1.0/24 [90/30720] via 10.99.99.1, 00:51:39, FastEthernet0/1

The console has default gateway back to the ASA interface as well:

Default gateway is 192.168.1.181

Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty

Lastly, I can ping to the respective endpoint from the ASA - outside, internal and DMZ. I have a feeling that I am missing something very obvious but after a considerable amount of googling and researching I can't come up with a sensible answer. I tried to point the routes/gateways to the external addresses on the devices but this didn't yield any positive results and didn't feel 'right' as ASA should be separating these networks.

 While it's not the core of my study, with CCNA being the main focus I was hoping to have remote access to the lab as I can control it's power remotely and could well log in and practice while remote. Any help appreciated - I can also provide further detail or troubleshooting as needed while continuing my search for the answer to this particular problem.

I also checked the hits of the interfaces but due to other traffic on them, I cannot fully discern if this is actually reaching the devices. I assume it is based on the ASA output

1 Accepted Solution

Accepted Solutions

Can you do a packet-tracer from either the DMZ or inside interface mimic traffic from R1 to 8.8.8.8? We can see why outbound pings are failing.

 

Under the VTY sessions of R1 do you have any ACL applied to limit who can SSH?

 

line vty 0 4
 access-class xxx in

 

Can you SSH to R1 from the other kit/various network on your diagram? Just want to ensure SSH is setup correctly on R1 i.e. RSA keys etc

 

Joel

View solution in original post

9 Replies 9

Two things come to mind initially.  Do you have inspect icmp configured under the policy-map? and is the windows firewall turnd off or at least allows ICMP?

--
Please remember to select a correct answer and rate helpful posts

Hi,

I do, and I specifically tested for the port 22 from the outside aside from pings and ICMP inspect is allowed under configuration map:

policy-map global_policy
 class inspection_default
  inspect icmp

There are no Windows devices in the network path as far as I can think of; the only Windows device that's in the picture is my workstation that lives on a single 'internal' IP while performing no other function than a client. I have been heavy handed an allowed ICMP throughout, global config:

icmp permit any outside
icmp permit any dmz
icmp permit any inside

I got communication up between a DMZ interface and the internal one by setting same security levels; I guess I'm missing a chapter on NAT on ASA and routing between interfaces on different security levels - earmarked in a book for tomorrow morning; I do have a feeling it's somewhere along these lines.

As stated; I'm fairly new to networking and working up to CCNA; appreciate the reply :)

Could you clarify where exactly you are trying to connect to 192.168.1.180 from (the PC on inside interface or a PC on the outside interface).  If the PC is on the outside interface what IP subnet is assigned to the PC?

 

Could you also clarify what the issue is.  Are you having issues accessing the console switch through the ASA or accessing R1 from the console switch through the ASA?

--
Please remember to select a correct answer and rate helpful posts

Hi Marius,

I'm trying to connect externally to this and the other private address. Both R1 and the console have their private addresses; R1 in DMZ and console on internal.

 

ASA has a public IP on the outside interface on a /29 subnet and few other public IPs that are not in use. I'm trying to do a static NAT to both console and R1 to unused public IPs

 

I have added the initial data flow on below picture. It is the same problem that affects two devices

 

Capture2.PNG

Joel has observed and incorrect NAT rule on ASA for R1 - it was mapping on inside interface rather than DMZ:

object network R1
 nat (inside,outside) static x.x.223.125

This has been corrected to:

object network R1
 nat (dmz,outside) static x.x.223.125

Packet-tracer for the translated address reports:

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network R1
 nat (dmz,outside) static x.x.223.125
Additional Information:
NAT divert to egress interface dmz
Untranslate x.x.223.125/22 to 10.99.99.2/22

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inbound in interface outside
access-list inbound extended permit tcp any host 10.99.99.2
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: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network R1
 nat (dmz,outside) static x.x.223.125
Additional Information:

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

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

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

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

Tests:

ping from an external site - FAIL:

--- PING x.x.223.125 (x.x.223.125) 56(84) bytes of data. ---


--- x.x.223.125 ping statistics ---

					
packets transmitted 	9
received 	0
packet loss 	100 %
time 	8143 ms

So tests for port 22 - closed

x.x.223.125:22 port is closed

There are hits on the NAT:

Auto NAT Policies (Section 2)
1 (dmz) to (outside) source static R1 x.x.223.125
    translate_hits = 0, untranslate_hits = 58
2 (inside) to (outside) source static console x.x.223.124
    translate_hits = 0, untranslate_hits = 41

And I can now generate hits of R1 - although they fail to come out

R1#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 0 percent (0/5)
Auto NAT Policies (Section 2)
1 (dmz) to (outside) source static R1 x.x.223.125
    translate_hits = 1, untranslate_hits = 72
2 (inside) to (outside) source static console x.x.223.124
    translate_hits = 0, untranslate_hits = 46

 It's not much closer to a solution yet, but one mistake less and consistent behaviour for both devices affected.

Can you do a packet-tracer from either the DMZ or inside interface mimic traffic from R1 to 8.8.8.8? We can see why outbound pings are failing.

 

Under the VTY sessions of R1 do you have any ACL applied to limit who can SSH?

 

line vty 0 4
 access-class xxx in

 

Can you SSH to R1 from the other kit/various network on your diagram? Just want to ensure SSH is setup correctly on R1 i.e. RSA keys etc

 

Joel

Hi Joel,

here it goes, same for both:

R1 on DMZ interface - looks successful

ciscoasa# packet-tracer input dmz icmp 10.99.99.2 8 0 8.8.8.8

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

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

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
object network R1
 nat (dmz,outside) static x.x.223.125
Additional Information:
Static translate 10.99.99.2/0 to x.x.223.125/0

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: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

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

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

2511 on the inside interface

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

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

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
object network console
 nat (inside,outside) static x.x.223.124
Additional Information:
Static translate 192.168.1.180/0 to x.x.223.124/0

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: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 7481, 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

There's no ACLs on R1 or console for that matter:

line vty 0 4
 password *
 logging synchronous
 login local
 transport input all

Also, I'm permitting ICMP on the ASA:

icmp permit any outside
icmp permit any dmz
icmp permit any inside
policy-map global_policy
 class inspection_default
  inspect icmp

And yes, I can SSH to the console on the inside network (shared with my home PC) and between devices in the 'DMZ' network (can't test from a PC, as ASA sits in between)

R3#ssh -l en 10.0.30.1
Password:

R1>

Joel,

 

got it! You nudged me in the right direction:

- console - it's telnet! So I was testing the wrong port - 22 instead of 23. Now that comes through. It's old 2511 that is not capable of SSH

- R1 - after changing transport input to SSH and re-generating the key it started working as well over the correct port.

 

I was looking in the wrong direction (routing) altogether, yet it has proven to be such a silly thing! 

 

Thank you a lot. Two days of my life lost but it's a good lesson to check the basics first.

Glad it's working.

 

Joel

Review Cisco Networking for a $25 gift card