Have two clients on separate networks one gets traffic but the other doesn't

[jwnetworker]

I have the following setup:

[client 10.1.20.0]---inside--[asa fw]-outside------[server 192.168.0.0]

[client 10.1.30.0]-----inside--^

Essentially two separate networks connected to the asa firewall on the inside and one on the outside.

The 10.1.30 subnet connects to our outside server 192...just fine...etc..

The 10.1.20 subnet client can't connect.

What type of commands can I run on the firewall to diagnose the possible reason?

Attached are some of the settings currently on the ASA that I believe may give insight...

route inside 0.0.0.0 0.0.0.0 10.1.10.1 1
route inside 10.1.30.0 255.255.254.0 10.1.10.1 1

route inside 10.1.20.0 255.255.255.0 10.1.10.1 1

!

nat (inside,outside) source static NET1 NET1 destination static NET3 NET3 no-proxy-arp route-lookup

(Not sure what this does..exactly...)

(Net1 is all the local networks and Net3 are the outside)

(I can ping successfully from the 10.1.20 subnet  to the 192 subnet server.)

Thanks!

[Seb Rupik]

Hi there,

The NAT statement given is known as a no-NAT/ NAT exemption rule, ie the address (both source and destination) do not get translated.

This makes it highly likely that the server in the outside subnet does not have a route for 10.1.30.0 subnet. It should have something like:

!
ip route 10.1.30.0 255.255.255.0 <asa_outside_ip>
!

Telling it that he 10.1.30.0 is reached via the ASA outside interface.

Since the client is initiating the connection, the ASA state table will permit the return traffic.

cheers,

Seb.

[jwnetworker]

Thanks for the help...however....notice im trying to connect from the 10.20 network. I can ping the outside server fine but it doesnt connect. The 10.30 connects fine all the way.

[Seb Rupik · Accepted solution]

Can you share the output of:

packet-tracer input inside tcp 10.1.20.1 55000 192.168.0.2 80 detail

...please change the source and destination IPs as required.

cheers,

Seb.

[jwnetworker]

Hmm...I ran it but it comes back as allow.

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

[Seb Rupik]

OK, well that is promising. 

Have you run a packet capture on the destination server, to see if the packets are reaching it?

What sort of server is it, what service is it you are trying to access? Does it have a firewall service running?