Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.


ASA firewall question

Does anyone have a solution to this problem?

Host "CA" has dual NIC. Eth0 has an IP address of

Eth1 has an ip address of The default gateway

on host CA is

The firewall has three interfaces. E0 has has IP address of

E1 has IP address of and E2 has IP address of

The default gateway on the firewall is

Host "NY" has an IP address of It has the default gateway


The current firewall is a Checkpoint firewall. There is NO NAT on the firewall.

Policy on the firewall is allow everything.

Currently, NY can ping both and ip address. Furthermore,

NY can access CA via either or and everything is working fine.

Here is the issue:

Customer would like to get rid of the Checkpoint firewall and replace it an ASA

firewall. One of the many requirements is that after swapping the Checkpoint

firewall with an ASA firewall, host NY can still access host CA on both IP addresses

of and

Is this possible with ASA? I don't have an ASA to test at the moment so I have to ask.

Thanks in advance.


Re: ASA firewall question

Any gurus here know the solution to this?

Re: ASA firewall question

Hello David,

I know nothing about Checkpoint, and if there are no tricks configured on Checkpoint, here is my opinion.

There is no NAT configured so source appears as itself. NY pings CA on thats OK, but when NY pings CA on, since source is in a different subnet, it has to forward the response to default gateway, which is That causes an assymetrical routing, but doesnt mean that connections wont establish. Connections would fail if there is 1) A device with Reverse Path Check configured on the way, 2) A statefull device configured "properly" on the way.

If this way it works is OK, then ASA can do the same job with permit statements for assymetrical return traffics and RPF check disabled. But my suggestion is NATing the traffic destined for 192.168.0 network to interface IP of ASA ( so there wont be any assymetrical routing issue.


Re: ASA firewall question


I think you are about to do a sugegstion or consultation to someone and need certain answers. I have been there so I loaded your scenario to my lab. Here are the results


issued commands

no nat-control

no ip verify reverse-path interface inside

There are no NAT rules in place and traffic from any source to any destination is permitted inboun in E0 interface (

NY can ping CA's both IP addresses, but as I proposed, the traffic from NY to CA flows through an assymetrical route. Return traffic is passed to default gateway of CA, which is, the inside interface of PIX. When I enable "ip verify reverse-path interface inside" firewall blocks this assymetrical flow and no connection between NY and CA can be established.



Re: ASA firewall question

The issue is that this asymetric routing

is working on Checkpoint. Customer does NOT

want to make any modifications.

On the ASA, RPF and anti-spoofing will be

disabled. Due to the ASA "stateful", will it

work like Checkpoint?

I know for a fact that it will NOT work on ACE

because ACE will inspect "per" flow. Will

ASA behave the same as ACE?

I can NOT modify the existing network in

any shapes or forms.

Anymore ideas?

Re: ASA firewall question

It worked in the lab I mentioned above, no modification needed in existing network. Let me try it with a TCP connection instead ICMP

Re: ASA firewall question

Deny TCP (no connection) from to flags SYN ACK on interface inside

:/ ,we have some issues with state table


Re: ASA firewall question

Then the ASA behaves just like Cisco ACE engine

then. In other words, what works in Checkpoint

does not work in ASA. Bummer....

Thanks again for testing this out for me. I

really appreciate that.


Re: ASA firewall question

You are welcome :)

Re: ASA firewall question

Howcome this works on the checkpoint? How does a stateful firewall allow a 'new' connection/packet with the SYN+ACK flags set in it without the session already being in its state table? Or you have some special command to exclude this particular flow?

I'm sorry ...not that good with CheckP.




Re: ASA firewall question

Checkpoint is a stateful firewall, just like

ASA. If you look at the diagram I posted,

both interfaces of the Server is connected

to the firewall.

Assuming you turn OFF anti-spoofing, the

connection come from the "source" getting

to the target, the firewall has that connection, so the firewall know.

Furthermore, since this is Checkpoint

Secureplatform (aka CP+Linux), the linux

kernel has a parameter net.ipv4.conf.all.rp_filter = 1 and that this

parameter inside the Linux kernel that

controls the aysmetric route. If this option

is set to 1, asymetric will NOT be possible,

does not matter what Checkpoint does. If

this parameter is set to 0, asymetric route

is possible with antispoofping disable.

Hope that makes sense.

Cisco Employee

Re: ASA firewall question


How about using the "Nailed" option under the static configuration.


(Optional) Allows TCP sessions for asymmetrically routed traffic. This option allows inbound traffic to traverse the security appliance without a corresponding outbound connection to establish the state. This command is used in conjunction with the failover timeout command. The failover timeout command specifies the amount of time after a system boots or becomes active that the nailed sessions are accepted. If not configured, the connections cannot be reestablished.

Note Adding the nailed option to the static command causes TCP state tracking and sequence checking to be skipped for the connection. Using the asr-group command to configure asymmetric routing support is more secure than using the static command with the nailed option and is the recommended method for configuring asymmetric routing support.



*Pls rate if it helps*


Re: ASA firewall question

We are not using any static so "nailed" does not

apply in this situation. We use

"no nat-control" in this situation, just routed

mode through the ASA.