• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

ARP?

as i understand a router connects different networks (one network per interface). if the asa was on a different network due to the mask being wrong and it was the inside lan interface he would not be able to ping it at all even if the DG was pointing to the router.

I could be wrong tho and learn different as a advance further into networking.


i'm pretty sure it could be possible given the right scenario.

suppose the PC is 1.2/30, the router is 1.1/24, and the ASA is 1.10/24

the router and ASA can obviously talk to each other no problem.
the PC and the router can also talk to each other no problem.
when the PC would talk to the ASA, it wouldn't know how to get there since it's not a directly connected subnet (from the PC's perspective). so, it would send the packet to the router, which would then forward it to the ASA.
to respond, the ASA thinks the PC is in it's directly connected subnet, and will simply ARP for 1.2. the PC (i'm assuming at this point) would respond, but would send its response again thru the router. Once the ASA has the MAC of the PC, it will simply send the response directly to the PC.

it's definitely asymmetric, but it could work that way.


however, he's already said the subnets are configured as /24, so this isn't the problem. (damn, thought i was on to something)
 
AMD - These are ASA 5505's and not purchased from e-bay.

Vito - The arp cache stays the same before and after i changed the DG. Also, I tried clearing out the arp cache after I changed the DG.

When I did a capture before changing the DG, I saw the ICMP echo and echo-reply, as soon as I change the DG, the ASA is not receiving the echo packets at ALL.

There has to be an explanation to this.

where are you capturing from? PC, switch, or ASA?

as someone else mentioned, what is the MAC associated to the echo packets? is it the ASA's MAC?
 
did you get this working? i'm curious what the issue turned out to be?
 
Shyt just install Cane and Abel and sniff your network. See where your packets going.
Btw when you enter 196.168.1.1
Do you get the routers log in page?
To access the firewall you got to enter https://196.168.1.1
Otherwise you won't get into it
 
Last edited:
1.) ASA should respond to ping on the inside interface, from a host addressed on the same subnet at the inside intf.

2.) If the router interface and the ASA inside intf, are in the same broadcast-domain, and have destination path to the same host, then one or the other could answer an ARP request for that host, EVEN if your PC has a DGW set of one or the other.

You also have the delicate issue of ARP timeout, whereby the router is maintaining an ARP entry for a given destination, even though you've turned on the ASA and entered it as your DGW. Thus, in this case, unless the ASA gratuitously ARPs for that host, then you'll be blackholed until a.) the ARP entry times out on the router, or b.) you issue the command "clear arp" on the router.

On the ASA, issue the command sysopt noproxyarp inside, to disable proxy arp on the ASA. This will prevent the ASA from proxy'ing ARP for hosts on other interfaces, if you have an intermediate router with a path to those destinations.

It is best practice to have only one path out of the LAN, from the inside of the ASA. This means if that router for instance, has a different physical path out, it should sit on a DMZ interface, or on a different VLAN routable from the core switch, or dist switch.


OP, if you could provide a simple diagram of what you're trying to do, I am sure it's a very simple problem, and most likely just functionality of IP that you're missing.
 
Back
Top