10-14-2018 05:25 AM - edited 02-21-2020 08:21 AM
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:
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
Solved! Go to Solution.
10-15-2018 05:37 AM
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
10-14-2018 12:24 PM
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?
10-14-2018 12:38 PM - edited 10-14-2018 12:38 PM
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 :)
10-14-2018 01:15 PM
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?
10-14-2018 01:29 PM - edited 10-15-2018 03:18 AM
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
10-15-2018 05:23 AM - edited 10-15-2018 05:50 AM
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.
10-15-2018 05:37 AM
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
10-15-2018 05:49 AM - edited 10-15-2018 06:01 AM
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>
10-15-2018 06:06 AM - edited 10-15-2018 06:12 AM
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.
10-15-2018 06:59 AM
Glad it's working.
Joel
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide