intra-interface routing on ASA

Answered Question
Jul 29th, 2008

Hi,

Well, I'm a bit confused with the command "same-securty-level permit intra-interface"

I configured an asa, with this command, and and just try to use the inside interface as a "gateway".

I mean : my packet is sent from my station 192.168.1.2 to the ASA inside interface 192.168.1.100 and then the ASA should send it to the router 192.168.1.1, (so back to the same interface), and then the router send the packet to Internet.

It works fine for ICMP... but nothing else ^^

Where am I wrong ??

I have this problem too.
0 votes
Correct Answer by husycisco about 8 years 4 months ago

Hello,

This is neither a wierdness of same-security-traffic issue nor an xlate lookup or ACL. Adam is right, but the command syntax in his suggestion is the victim of a design which ASA is not developed for. Let me explain.

Connectionless protocols like ICMP and UDP will work right now. But TCP wont. Here is why.

1)192.168.1.2 tries connecting to 198.133.219.25 (cisco.com) via port 80. Host first checks if it has a directly connected route (checks if destination is in the same segment with itself or not). No. Host creates TCP SYN packet sourced 192.168.1.2 from its own L2 MAC address destined to cisco.com IP address, but to ASA's (its default gateway) Layer 2 MAC address, then starts waiting ACK packet that cisco.com will send, from ASA.

2)ASA gets the packet, its destined for 198.133.219.25, places its own L2 MAC to source field, but source IP still remains 192.168.1.2 since it is not performing NAT, and places the L2 MAC of its gateway 192.168.1.1

3)Gateway receives the packet. Source IP of the packet is 192.168.1.2. Gateway has to perform NAT for internet connectivity, so records that into its translation table. Places its Public Ip and mac as source of the packet. The "mac swap" continues throughout its way untill it reaches the destination, while registers into translation tables to not to lose its way back. SYN reaches the destination. ACK is on its way back

4)Finally, our gateway gets the ACK destined for itself, checks its translation table and finds the match. Removes its public IP from destination and places 192.168.1.2.

All was fine untill here, but here is how it ends up

ASA did send the packet with source ip 192.168.1.2, so that means ASA know where that IP is. Under normal circumstances, gateway was going to check its routing table to learn how to get to 192.168.1.2, was going to see ASA as the advertising or statically entered gateway, send that packet, then ASA was going to send it to 192.168.1.2 and finally 192.168.1.2 was going to get the ACK from the L2 address that it destined its SYN to. SYN_ACK was going to be sent and session was going to be established. But here is what happened

Gateway checks its routing table to see how to get to 192.168.1.2, and dang... it has a Connected route to that host, it is within the same segment with that host! Checks its arp table, no MAC entry, broadcasts... 192.168.1.2 responds... Now the packet has the L2 address of the host itself, sends the packet.

Host receives the packet, its the SYN_ACK that it was waiting for, but wait a sec... source L2 MAC address of the SYN_ACK does not match with the L2 MAC address that it destined its SYN for... sorry, TCP is broken... -RST

If ASA have changed the source IP of the packet with its egress int IP (NAT), all was going to work.

Here is the commands with correct syntax that will resolve your isue

access-list NAT permit ip 192.168.1.0 255.255.255.0 any

nat (inside) 1 access-list NAT

global (inside) 1 interface

clear xlate

I hope I didnt bore you with the long story

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
acomiskey Tue, 07/29/2008 - 05:34

See if this fixes it....

global (inside) 1 interface

nat (inside) 1 0 0

olivier.jessel Wed, 07/30/2008 - 01:14

Hi,

Well I tested it. It didn't help... So I entered the command

nat (inside) 1 192.168.1.2 255.255.255.255

It worked fine for 3 minutes ^^ then I only modified the password and make a wr mem, and nothing works ... Well I suspect some other problems, not on the ASA... I'm investigating...

By the way, does someone knows if it's possible to transport vlans through L2L Ipsec vpn ?

olivier.jessel Wed, 07/30/2008 - 02:34

woh... ok ! not very simple as I can see ^^

Thanks for the link ;)

For my problem with the intra-interface command, I'm lost now. I checked everything... Does anyone has a correct configuration example to show me. I can post my config too...

olivier.jessel Wed, 07/30/2008 - 05:49

Well, OK this would be the best design, However the router connected on Internet is a kind of "ALL in the box" provided by my ISP. You can't do a lots of things on it, but NAT or port forwarding is possible.

Anyway, the goal of this is to configure an ASA as a "HTTP proxy on a stick". I don't know if it's possible, that's why I first tried to configure it like a gateway to check if routing is OK or not... But maybe it's not the good way to do it, or simply it's not possible ?

if anbody has got an idea... well... I'm really interested by ^^

Thanks again for your help, I really appreciated !

As fas as I know the ASA cannot be used in that way I maybe wrong, and someone has dont it - that is why even the basic models come with an inside and outside interface, fi you want to filer traffic/protocols/urls - then you have the internal network on the inside, and the ISP router on the outside - and the ASA "filters" traffic as is passes THRU it.

HTH>

olivier.jessel Wed, 07/30/2008 - 06:07

sorry the word "proxy" is not really the best. I just want the ASA authenticates the traffic, not really filter it... well if I read myself, it seems to be the same... so you're maybe right, it's not possible with this device... :(

But why it can't work corectly with this intra-interface command, this is still a mistery..

olivier.jessel Wed, 07/30/2008 - 06:16

Yes i've seen this link, that's why I though it could be possible to do a "ASA on stick" configuration.. but it doesn't seems to work as described...

olivier.jessel Wed, 07/30/2008 - 06:37

I have no ACL on the inside interface. But yes, I tried to add an "any to any" ACL. It didn't change anything.

I will try again this evening, I'll let you know.

samak9c Wed, 07/30/2008 - 07:23

Only for ....intra-interface command, this is still a mistery..

if)

ISP-Router-L2--F/W

......................|-Server

i think it may be switching issue if the configure hasn't NAT & connected L2.(between R & F/W)

first packet was sent to f/w ~ L2 and then

to the Router But(From Router)Return packet was directly sent to server

because L2 table is preper than L3 table

lookup , if you try capture on f/w inside ,

can't be found any return connections.

(Just my suppose -_-)

samak9c Wed, 07/30/2008 - 08:47

if the design isn't abvoe case, it may be xlate lookup fail

because static (inside,inside) command] is not allowed , dynamic nat is require for make xlate. and increase timeout xlate

anyway the design isn't good..... -_-;

Correct Answer
husycisco Thu, 07/31/2008 - 01:11

Hello,

This is neither a wierdness of same-security-traffic issue nor an xlate lookup or ACL. Adam is right, but the command syntax in his suggestion is the victim of a design which ASA is not developed for. Let me explain.

Connectionless protocols like ICMP and UDP will work right now. But TCP wont. Here is why.

1)192.168.1.2 tries connecting to 198.133.219.25 (cisco.com) via port 80. Host first checks if it has a directly connected route (checks if destination is in the same segment with itself or not). No. Host creates TCP SYN packet sourced 192.168.1.2 from its own L2 MAC address destined to cisco.com IP address, but to ASA's (its default gateway) Layer 2 MAC address, then starts waiting ACK packet that cisco.com will send, from ASA.

2)ASA gets the packet, its destined for 198.133.219.25, places its own L2 MAC to source field, but source IP still remains 192.168.1.2 since it is not performing NAT, and places the L2 MAC of its gateway 192.168.1.1

3)Gateway receives the packet. Source IP of the packet is 192.168.1.2. Gateway has to perform NAT for internet connectivity, so records that into its translation table. Places its Public Ip and mac as source of the packet. The "mac swap" continues throughout its way untill it reaches the destination, while registers into translation tables to not to lose its way back. SYN reaches the destination. ACK is on its way back

4)Finally, our gateway gets the ACK destined for itself, checks its translation table and finds the match. Removes its public IP from destination and places 192.168.1.2.

All was fine untill here, but here is how it ends up

ASA did send the packet with source ip 192.168.1.2, so that means ASA know where that IP is. Under normal circumstances, gateway was going to check its routing table to learn how to get to 192.168.1.2, was going to see ASA as the advertising or statically entered gateway, send that packet, then ASA was going to send it to 192.168.1.2 and finally 192.168.1.2 was going to get the ACK from the L2 address that it destined its SYN to. SYN_ACK was going to be sent and session was going to be established. But here is what happened

Gateway checks its routing table to see how to get to 192.168.1.2, and dang... it has a Connected route to that host, it is within the same segment with that host! Checks its arp table, no MAC entry, broadcasts... 192.168.1.2 responds... Now the packet has the L2 address of the host itself, sends the packet.

Host receives the packet, its the SYN_ACK that it was waiting for, but wait a sec... source L2 MAC address of the SYN_ACK does not match with the L2 MAC address that it destined its SYN for... sorry, TCP is broken... -RST

If ASA have changed the source IP of the packet with its egress int IP (NAT), all was going to work.

Here is the commands with correct syntax that will resolve your isue

access-list NAT permit ip 192.168.1.0 255.255.255.0 any

nat (inside) 1 access-list NAT

global (inside) 1 interface

clear xlate

I hope I didnt bore you with the long story

Regards

olivier.jessel Thu, 07/31/2008 - 01:34

Well that's right. After acomiskey told there was a NAT issue, I tried this, but it didn't work. Yesterday I tried again and I found the problem. The ASA configuration works fine with the NAT config you explained. My problem was not on the asa but on the "all in the box" f.cking router my provider gave to me : all connections made by wifi (same subnet 192.168.1.x/24) are not correctly forwarded to my ASA. I only use cable and it works fine.

So... conclusion : I need a Cisco 877W to replace this f...ing box !

Thanks again, it really helps me !!

Actions

This Discussion