Two Cisco ASA working on one Public Subnet Issue

[aandewegr]

Dear all,

First off all I ‘am not a Firewall specialist.

I have a configuration that is not working and I am out of options hot to fix my following strange issue.

In use:

1. One Public Subnet
2. 2 Cisco ASA's with firmware 9.x
3. Multiple private ranges on both asa's on different interfaces (OUTSIDE, INSIDE, DMZ)
4. Laptop (working on homeinternet connection

Issue

Both ASA's work normally but i will try to explain what issue I ‘am facing (Attached drawing). 

- When i connect with SSH (22) from my laptop at home to 1.1.1.141 that works

- When i connect with ASDM or SSH (22) from my laptop at home to 1.1.1.140 (ASA) that works

- When i connect with ASDM or SSH (22) from Client 172.16.18.62 to 1.1.1.140 (ASA) that does NOT work

- When i connect with SSH (22) from Client 172.16.18.62 to 1.1.1.141 (SFTP Server, NAT) that does NOT work

TEST ASA is only connected to public vlan (2500) for internet connection and the other private ranges are only know by the TEST ASA physical interfaces.

I hope somebody can help me with this issue I’ am facing

If you got questions because my explanation is not clear then do not hesitate to ask.

Thanks in advance

Regards,

Remco

[Marius Gunnerud]

Have you configured ssh and http(s) access for the inside network?

ssh 172.16.18.0 255.255.255.0 inside

http 172.16.18.0 255.255.255.0 inside

[aandewegr]

Yes i also have that but i go out from 172.16.18.62 (Public 1.1.1.130) so i enabled below on the TEST ASA and that does not make a difference

ssh 1.1.1.130 255.255.255.0 OUTSIDE

http 1.1.1.130 255.255.255.0 OUTSIDE

[ngkin2010]

Hi,

Can you try packet tracer command on production (ASA) to see whether the packet pass through the firewall or not?

packet-tracer input INSIDE tcp 172.16.18.62 12345 1.1.1.140 22

packet-tracer input INSIDE tcp 172.16.18.62 12345 1.1.1.140 443

[aandewegr]

I have tested what you asked and that works (22 and 443 both same result)

----------------------------------------

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

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 1.1.1.129 using egress ifc OUTSIDE

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside-acl in interface INSIDE
access-list inside-acl extended permit ip object-group NL-RO-NW-ReAa any
object-group network NL-RO-NW-ReAa
network-object object NL-RO-NW-CLT99
Additional Information:

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (INSIDE,OUTSIDE) source dynamic any interface
Additional Information:
Dynamic translate 172.16.18.62/12345 to 1.1.1.130/12345

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

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

Phase: 7
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (INSIDE,OUTSIDE) source dynamic any interface
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 351579777, packet dispatched to next module

Phase: 12
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 1.1.1.129 using egress ifc OUTSIDE

Phase: 13
Type: ADJACENCY-LOOKUP
Subtype: next-hop and adjacency
Result: ALLOW
Config:
Additional Information:
adjacency Active
next-hop mac address 5006.ab65.0f44 hits 14 reference 226

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: allow

[ngkin2010]

Hi,
"found next-hop 1.1.1.129 using egress ifc OUTSIDE"

Could you verify the subnet mask set on ASA (Production)? I see the nexthop for your connection was used .129 instead of .140 directly.

Would you please post your "show route" result of both ASA?

[aandewegr]

ASA-TEST# sh route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is 1.1.1.129 to network 0.0.0.0

S* 0.0.0.0 0.0.0.0 [1/0] via 1.1.1.129, OUTSIDE
C 1.1.1.128 255.255.255.192 is directly connected, OUTSIDE
L 1.1.1.140 255.255.255.255 is directly connected, OUTSIDE
C 172.16.10.0 255.255.255.0 is directly connected, INSIDE
L 172.16.10.1 255.255.255.255 is directly connected, INSIDE
C 172.16.11.0 255.255.255.0 is directly connected, DMZ
L 172.16.11.1 255.255.255.255 is directly connected, DMZ

ASA-PRODUCTION# sh route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 1.1.1.129 to network 0.0.0.0

S* 0.0.0.0 0.0.0.0 [1/0] via 1.1.1.129, OUTSIDE
C 1.1.1.128 255.255.255.192 is directly connected, OUTSIDE
L 1.1.1.130 255.255.255.255 is directly connected, OUTSIDE
C 172.16.18.0 255.255.255.192 is directly connected, INSIDE
L 172.16.18.1 255.255.255.255 is directly connected, INSIDE
C 172.16.18.64 255.255.255.192 is directly connected, DMZ
L 172.16.18.65 255.255.255.255 is directly connected, DMZ
C 172.16.19.0 255.255.255.192 is directly connected, MNGT
L 172.16.19.1 255.255.255.255 is directly connected, MNGT

[ngkin2010 · Accepted solution]

Hi,

I am not sure why it look like sending to wrong adjacency on production ASA. I have setup a lab on GNS3, and it's work well.

So, let's check it step by step to look deeper.

1. On Production ASA, try to "show arp", and verify you could see the ARP entry of 1.1.1.140, and check whether the MAC address is 5006.ab65.0f44 (which you from the result of packet tracer).

2. On Test ASA, try to issue "packet-tracer input OUTSIDE tcp 1.1.1.130 12345 1.1.1.140 22" to verify if anything wrong on Test ASA. You should see the 1.1.1.130's MAC address at the result. (E.g.:

Type: ADJACENCY-LOOKUP
...
Result: ALLOW
...
next-hop mac address XXXX.YYYY.ZZZZ hits xxxxxxxx


3. Setup a capture on Test ASA, to see whether you see the packet coming from Production ASA on outside interface.

# capture temp input buffer 2048 match tcp host 1.1.1.130 host 1.1.1.140 eq 22
# (telnet 1.1.1.140 22 on your 172.16.18.62)
# show capture temp
(clear the capture at the end)
## no capture temp

4. Verify the control plane ACL on TEST ASA to see whether it has blocked the ssh access on outside interface.

# show run access-group
# (see whether something like: access-group Outside-Control-PlaneACL in interface outside control-plane)
# If yes, check the access-list by "show run access-list Outside-Control-PlaneACL"

[aandewegr · Accepted solution]

Thank you veryyyyyy much for you're help my two problems are fixed

1. ASDM is working now, fixed it by going to conf t and type "ssl encryption aes128-sha1 aes256-sha1"

2. SSH connection to 1.1.1.141 i resolved by you're advice "packet-tracer input OUTSIDE tcp 1.1.1.130 12345 1.1.1.141 22" that lead me to an ACL DROP.

What a great forum this is and alle the People that helped me putting me in the right direction!!

[Marius Gunnerud]

Are you by chance running HTTPS and SSH services on 1.1.1.141 server and have NAT statements on the Test-ASA for SSH and HTTPS using the outside interface IP pointing to 1.1.1.141?  If yes then this is your problem.  For ASDM the fix is to use a different port (ex. 4433) for SSH you would need to connect to the ASA via AnyConnect or similar.

http server enable 4433

Could you post your full running configuration of the Test-ASA (remember to remove public IPs, usernames and passwords.)