cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1763
Views
0
Helpful
11
Replies

FWSM route decision with subnet overlapping

Plinio Brandao
Level 1
Level 1

Hi Community,

We are having some problems at a customer and I'd like to change some ideias with you.

I have the following scenario:

fwsm-problem.png

The FWSM has 3 interfaces, INSIDE, OUTSIDE-A and OUTSIDE-B. A host from 10.14.7.0/24 is trying to reach on a host at 10.2.7.0/24. According to the topology, some comments are needed:

R1 has a specific route to 10.2.7.0/24 through FWSM

R1 knows the route 10.2.0.0/16 by BGP

FWSM knows the network 10.2.7.0/24 because its directly connected

FWSM has a specific route to 10.2.0.0/16 through R1

According the concepts, a connected route is more specific than a static route, ok?

So, when a host at 10.14.7.0/24 sends a packet to a host on 10.2.7.0/24 the FWSM receive the packet on OUTSIDE-B interface and forwards to the OUTSIDE-B again as we can see at the image:

fwsm-interface.png

If a packet form a host at 10.14.7.0/24 goes to a host at 10.1.20.0/24 through INSIDE everything works good.

I know that this overlap isn't good and isn't a best practice, but why FWSM has this behavior?

11 Replies 11

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Seems strange.

Connected routes should be of value/metric/distance = 0 and static routes default = 1

Could any NAT configurations have anything to do with the problem?

Is one of the 10.2.x.x networks are new network just connected to the FWSM or how did this problem start?

Is there a possibility of perhaps using NAT for the 10.2.0.0/16 network before the FWSM?

Is it possible to change the network 10.2.7.0/24 to something different?

Ofcourse the best scenario would be to find whats causing this.

I wonder if any debug could give hints as to whats happening with the traffic. Wonder if theres a possibility of some sort of bug?

Hi Jouni,

Thank you for your feedback. I'll answer your questions:

Could any NAT configurations have anything to do with the problem?

  No, there isn't NAT. I tried to do a NAT at OUTSIDE-B but withou success.

Is one of the 10.2.x.x networks are new network just connected to the FWSM or how did this problem start?

  No, the 10.2.7.0/24 and the 10.2.0.0/16 were configured at a N7 solution, when we moved to a Cisco solution wtih 6513 and FWSM, we got this problem. No firewall existed before.

Is there a possibility of perhaps using NAT for the 10.2.0.0/16 network before the FWSM?

  I tried to to a NAT at OUTSIDE-B but withou success. The device before the FWSM is the SP router and we dont't have access.

Is it possible to change the network 10.2.7.0/24 to something different?

  We are planning a procedure to do this, but we'd like to understand why that it happened

I'm searching for a bug or something else. My last option will be open a case with TAC.

Thank you anyway.

Hi Plinio,

Can you please check if there is any stale xlate being created on the FWSM, which is pushing the packet through the wrong interface, check it with "show xlate".

Moreover, if you are not natting the traffic at all, then enable "xlate-bypass" and then do clear xlate and chcek again.

I've experienced it a few times myself, a wrong xlate created on the FWSM routing packets this way.

Thanks,

Varun

Thanks,
Varun Rao

Hi Varun,

Thank you for your return.

The output of "show xlate" is:

Global 10.2.165.3 Local 10.2.165.3

Global 10.2.172.143 Local 10.2.172.143

Global 10.2.141.22 Local 10.2.141.22

Global 10.2.164.208 Local 10.2.164.208

My NAT rules are:

static (OUTSIDE-B,INSIDE) 10.2.0.0 10.2.0.0 netmask 255.255.0.0

static (OUTSIDE-A,INSIDE) 10.2.7.0 10.2.7.0 netmask 255.255.255.0

Regards.

Plínio Monteiro

Thanks Plinio

In FWSM, established xlates have actually higher preference than routes in determining the next-hop, so NAT has it's significant contribution in the routing function, especially in some situations with overlapping statements.

If you have no nat-control enabled on the FWSM. I would suggest to remove the static from the FWSM, enable xlate-bypass, clear the xlates and try again, then the decisions should be purely routing table based.

Varun

Thanks,
Varun Rao

Hi Varun,

Thank you for your fast feedback.

I don't have de no nat-control. Is it even necessary remove the static, enable xlate-bypass and clear xlates?

Thank you in advance.

Only if you have "no nat-control" enabled. Can you share your "show tech", I would also check for any known issue.

Thanks,

Varun

Thanks,
Varun Rao

Hi Varun,

Yes, how can I send to you?

Plínio

you can PM me.

Thanks,
Varun Rao

Hi Varun,

I already sent to you.

Thank you in advance.

Hi Plinio,

its seems that you FWSM is creating worng xlate for the u-turning.

Can you check if you have the below commands enabled.

same-security-traffic inter interface

same-security-traffic intra interface

you can check them by typing the command "show run same"

In case they are enabled please remove them as below.

no same-security-traffic inter interface

no same-security-traffic intra interface

then do a clear xlate and clear conn.

after that try again.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: