Re: ASA firewall question

cisco24x7 · ‎10-29-2008

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

of 172.16.1.1.

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.

cisco24x7 · ‎10-30-2008

Any gurus here know the solution to this?

Alan Huseyin Kayahan · ‎10-30-2008

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 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.

Regards

Alan Huseyin Kayahan · ‎10-30-2008

David,

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

IOS=7.2(2),PIX515E

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 (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.

Regards

cisco24x7 · ‎10-30-2008

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?

Alan Huseyin Kayahan · ‎10-30-2008

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

Alan Huseyin Kayahan · ‎10-30-2008

Deny TCP (no connection) from 192.168.0.10/3389 to 172.16.1.10/1045 flags SYN ACK on interface inside

:/ ,we have some issues with state table

cisco24x7 · ‎10-30-2008

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.

David

Alan Huseyin Kayahan · ‎10-30-2008

You are welcome :)

Farrukh Haroon · ‎11-10-2008

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.

Regards

Farrukh

cisco24x7 · ‎11-10-2008

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.

ajagadee · ‎11-10-2008

Hi,

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

nailed

(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.

http://www.cisco.com/en/US/docs/security/asa/asa72/command/reference/s8_72.html#wp1202525

Regards,

Arul

*Pls rate if it helps*

cisco24x7 · ‎11-10-2008

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.