08-19-2019 09:37 PM - edited 08-20-2019 06:06 AM
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!
Solved! Go to Solution.
08-20-2019 07:46 AM
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.
08-20-2019 12:06 AM
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.
08-20-2019 05:00 AM
08-20-2019 07:46 AM
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.
08-20-2019 10:50 AM
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
08-21-2019 04:01 AM
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?
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