Does anyone have a solution to this problem?
Host "CA" has dual NIC. Eth0 has an IP address of 192.168.0.10/24.
Eth1 has an ip address of 192.168.1.10/24. The default gateway
on host CA is 192.168.1.254
The firewall has three interfaces. E0 has has IP address of 10.0.0.254/24
E1 has IP address of 192.168.1.254/24 and E2 has IP address of 192.168.0.254/24
The default gateway on the firewall is 10.0.0.1.
Host "NY" has an IP address of 172.16.1.10/24. 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 192.168.0.10 and 192.168.1.10 ip address. Furthermore,
NY can access CA via either 192.168.0.10 or 192.168.1.10 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 192.168.0.10 and 192.168.1.10.
Is this possible with ASA? I don't have an ASA to test at the moment so I have to ask.
Thanks in advance.
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 192.168.1.10 thats OK, but when NY pings CA on 192.168.0.10, since source is in a different subnet, it has to forward the response to default gateway, which is 192.168.1.254. 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 (192.168.0.254) so there wont be any assymetrical routing issue.
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
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 (10.0.0.254)
NY can ping CA's both IP addresses, but as I proposed, the traffic from NY to CA 192.168.0.10 flows through an assymetrical route. Return traffic is passed to default gateway of CA, which is 192.168.1.254, 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 192.168.0.10 can be established.
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.
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.
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.
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.
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*
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.