ASA Intra Interface Traffic only allowing ICMP

Unanswered Question
Oct 16th, 2008

I have seen some previous posts regarding this matter but the solution is not quite clear. Here is my issue:


I have a ASA 5505 that has 2 conifugred VLAN's; inside and outside. Outside takes Ethernet 0/0 and inside takkes Ethernet 0/1 - 0/7. I use outside for VPN connections and inside for internal LAN use. The inside is on the 172.30.0.0/24 subnet.


I want to connect another network subnet, 172.30.2.0/24, to the inside 172.30.0.0/24 network. I have a router at 172.30.0.80 that is set to route between 172.30.0.0/24 and 172.30.2.0/24 and I have set a static route in my ASA to allow traffic headed to 172.30.2.0/24 to use 172.30.0.80 as it's default gateway.


I can ping devices on the 172.30.2.0/24 subnet but I cannot establish a TCP connection. It looks like previous people have mentioned this is because ICMP is using UDP stateless connections while TCP is stateful.


Has anyone found a workaround for this problem? I am running ASA 7.2(4).


Thanks much in advance!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
acomiskey Thu, 10/16/2008 - 10:22

You can do either....


global (inside) 1 interface

nat (inside) 172.30.0.0 255.255.255.0


or


access-list nat0 extended permit ip 172.32.0.0 255.255.255.0 172.32.2.0 255.255.255.0

nat (inside) 0 access-list nat0

nsalemme1 Thu, 10/16/2008 - 11:01

Thanks for the quick reply! So the first set of commands you provided actually returns on error:


saxton-co-asa(config)# nat (inside) 172.30.0.0 255.255.255.0

^

ERROR: % Invalid input detected at '^' marker.



The second set of commands seems to overwrite existing NAT exempt rules I have set in place. I believe I have everything on the inside interface to be NAT exempt. I've pasted parts of my running config below:


interface Vlan1

nameif inside

security-level 100

ip address 172.30.0.1 255.255.255.0



same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

access-list outside_1_cryptomap extended permit ip 172.30.0.0 255.255.255.0 172.30.1.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip any any

access-list vpns remark

access-list vpns standard permit 172.30.0.0 255.255.255.0

access-list vpns remark

access-list vpns standard permit 172.30.1.0 255.255.255.0

access-list vpns remark

access-list vpns standard permit 10.252.0.0 255.255.255.0

access-list vpns remark

access-list vpns standard permit 255.255.255.0

access-list outside_2_cryptomap extended permit ip 172.30.0.0 255.255.255.0 10.252.0.0 255.255.255.0

access-list outside_3_cryptomap extended permit ip 172.30.0.0 255.255.255.0 255.255.255.0

access-list inside_nat0_outbound_1 extended permit ip any any

access-list inside_access_in extended permit ip any any

access-list outside_nat0_outbound extended permit ip any any

pager lines 24

logging enable

logging asdm informational

mtu inside 1500

mtu outside 1500

mtu dmz 1500

ip local pool vpnpool 172.30.0.132-172.30.0.163 mask 255.255.255.0

icmp unreachable rate-limit 1 burst-size 1

icmp permit any inside

icmp deny any outside

asdm image disk0:/asdm-524.bin

no asdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 0 access-list inside_nat0_outbound_1 outside

nat (inside) 1 0.0.0.0 0.0.0.0

nat (outside) 0 access-list outside_nat0_outbound

access-group inside_access_in in interface inside

route inside 172.30.2.0 255.255.255.0 172.30.0.80 1

route inside 172.30.3.0 255.255.255.0 172.30.0.80 1




Sorry about all the access lists. Those are there for several VPN connections coming into the ASA. So how exactly should I be changing my inside interface NAT rules? Do I want to be NATing from 172.30.0.0 to 172.30.2.0 or do I want to be excluding it? Right now I have everything setup to exclude.



Here is the error I get in the logs...


Built inbound TCP connection 24559 for inside:172.30.0.2/58202 (172.30.0.2/58202) to inside:172.30.2.2/22 (172.30.2.2/22)


Teardown TCP connection 24559 for inside:172.30.0.2/58202 to inside:172.30.2.2/22 duration 0:00:00 bytes 0 TCP Reset-O


Deny TCP (no connection) from 172.30.0.2/58202 to 172.30.2.2/22 flags RST on interface inside

acomiskey Thu, 10/16/2008 - 11:09

Sorry, I missed a "1".


nat (inside) 1 172.30.0.0 255.255.255.0


I would do this...


access-list inside_nat0_outbound extended deny ip any 172.30.2.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip any any

global (inside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0

nat (inside) 0 access-list inside_nat0_outbound


nsalemme1 Thu, 10/16/2008 - 11:33

Unfortunately still no luck. I am getting the Deny TCP connection in the ASA logs still. Very aggravating...

nsalemme1 Thu, 10/16/2008 - 11:46

Here is it. I've ommitted all IP sensitive information.




ASA Version 7.2(4)

!


!

interface Vlan1

nameif inside

security-level 100

ip address 172.30.0.1 255.255.255.0

!

interface Vlan2

nameif outside

security-level 0

ip address

!

interface Vlan3

shutdown

no forward interface Vlan1

nameif dmz

security-level 50

no ip address

!

interface Ethernet0/0

switchport access vlan 2

!

interface Ethernet0/1

!

interface Ethernet0/2

!

interface Ethernet0/3

!

interface Ethernet0/4

!

interface Ethernet0/5

!

interface Ethernet0/6

!

interface Ethernet0/7

!

ftp mode passive

dns server-group DefaultDNS

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

access-list outside_1_cryptomap extended permit ip 172.30.0.0 255.255.255.0 172.30.1.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip any any

access-list inside_nat0_outbound extended deny ip any 172.30.2.0 255.255.255.0

access-list vpns remark

access-list vpns standard permit 172.30.0.0 255.255.255.0

access-list vpns remark townshend-bts

access-list vpns standard permit 172.30.1.0 255.255.255.0

access-list vpns remark

access-list vpns standard permit 10.252.0.0 255.255.255.0

access-list vpns remark

access-list vpns standard permit 255.255.255.0

access-list outside_2_cryptomap extended permit ip 172.30.0.0 255.255.255.0 10.252.0.0 255.255.255.0

access-list outside_3_cryptomap extended permit ip 172.30.0.0 255.255.255.0 255.255.255.0

access-list inside_nat0_outbound_1 extended permit ip any any

access-list inside_access_in extended permit ip any any

access-list outside_nat0_outbound extended permit ip any any

pager lines 24

logging enable

logging asdm informational

mtu inside 1500

mtu outside 1500

mtu dmz 1500

ip local pool vpnpool 172.30.0.132-172.30.0.163 mask 255.255.255.0

icmp unreachable rate-limit 1 burst-size 1

icmp permit any inside

icmp deny any outside

asdm image disk0:/asdm-524.bin

no asdm history enable

arp timeout 14400

global (inside) 1 interface

global (outside) 1 interface

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 0 access-list inside_nat0_outbound_1 outside

nat (inside) 1 172.30.0.0 255.255.255.0

nat (inside) 1 0.0.0.0 0.0.0.0

nat (outside) 0 access-list outside_nat0_outbound

access-group inside_access_in in interface inside

route inside 172.30.2.0 255.255.255.0 172.30.0.80 1

route inside 172.30.3.0 255.255.255.0 172.30.0.80 1

route outside 0.0.0.0 0.0.0.0 216.66.108.41 1

!

router ospf 5

network 172.30.0.0 255.255.255.0 area 3

area 3

log-adj-changes

!

router rip

network 172.30.0.0

passive-interface inside

passive-interface outside

!

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute


!

class-map inspection_default

match default-inspection-traffic

!

!

policy-map type inspect dns preset_dns_map

parameters

message-length maximum 512

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect rsh

inspect rtsp

inspect esmtp

inspect sqlnet

inspect skinny

inspect sunrpc

inspect xdmcp

inspect sip

inspect netbios

inspect tftp

!

service-policy global_policy global

prompt hostname context

Cryptochecksum:xxx

: end


acomiskey Thu, 10/16/2008 - 11:51

1. The "deny" line in your acl needs to be before the permit.


access-list inside_nat0_outbound extended deny ip any 172.30.2.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip any any


2. You should not need this.


no nat (inside) 0 access-list inside_nat0_outbound_1 outside

nsalemme1 Thu, 10/16/2008 - 12:47

Great, that did it! I am now able to go from the 172.30.0.0 network to the 172.30.2.0 network. Thanks!


However when I try and go in the reverse direction, 172.30.2.0 --> 172.30.0.0 it seems to have trouble. Here is the error:


3 Oct 16 2008 13:34:21 305006 172.30.2.2 regular translation creation failed for icmp src inside:172.30.0.3 dst inside:172.30.2.2 (type 0, code 0)


Almost there! I've pasted the latest running-config below. Perhaps I need to add a new NAT rule for inbound?



same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

access-list outside_1_cryptomap extended permit ip 172.30.0.0 255.255.255.0 172.30.1.0 255.255.255.0

access-list inside_nat0_outbound extended deny ip any 172.30.2.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip any any

access-list vpns remark saxton-river-co

access-list vpns standard permit 172.30.0.0 255.255.255.0

access-list vpns remark townshend-bts

access-list vpns standard permit 172.30.1.0 255.255.255.0

access-list vpns remark vanu monitoring

access-list vpns standard permit 10.252.0.0 255.255.255.0

access-list vpns remark midtex bypass net

access-list vpns standard permit midtex-msc 255.255.255.0

access-list outside_2_cryptomap extended permit ip 172.30.0.0 255.255.255.0 10.252.0.0 255.255.255.0

access-list outside_3_cryptomap extended permit ip 172.30.0.0 255.255.255.0 midtex-msc 255.255.255.0

access-list inside_access_in extended permit ip any any

access-list outside_nat0_outbound extended permit ip any any

pager lines 24

logging enable

logging asdm informational

mtu inside 1500

mtu outside 1500

mtu dmz 1500

ip local pool vpnpool 172.30.0.132-172.30.0.163 mask 255.255.255.0

icmp unreachable rate-limit 1 burst-size 1

icmp permit any inside

icmp deny any outside

asdm image disk0:/asdm-524.bin

no asdm history enable

arp timeout 14400

global (inside) 1 interface

global (outside) 1 interface

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 0.0.0.0 0.0.0.0

nat (outside) 0 access-list outside_nat0_outbound

access-group inside_access_in in interface inside

route inside 172.30.2.0 255.255.255.0 172.30.0.80 1

route inside 172.30.3.0 255.255.255.0 172.30.0.80 1




Thanks so much acomiskey.

acomiskey Thu, 10/16/2008 - 13:42

access-list inside_nat0_outbound extended deny ip any 172.30.2.0 255.255.255.0

access-list inside_nat0_outbound extended deny ip 172.32.2.0 255.255.255.0 172.32.0.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip any any


acomiskey Thu, 10/16/2008 - 17:21

Actually, the traffic initiated from 172.32.2.x to 172.32.0.x shouldn't even be hitting the firewall.

nsalemme1 Fri, 10/17/2008 - 07:17

I tried adding the lines you mentioned above, no luck. The traffic initiated from 172.30.2.x must be hitting the firewall if I am receiving messages from the ASA logs.


I am going to look into what the "Regular translation creation failed" error means. That is the error I get in the ASA logs when I try and ping. There is a pretty extensive writeup about what this error means in the log details:


(apoligies for length)





A protocol (UDP, TCP, or ICMP) failed to create a translation through the security appliance. This message appears as a fix to caveat CSCdr0063 that requested that security appliance not allow packets that are destined for network or broadcast addresses. The security appliance provides this checking for addresses that are explicitly identified with static command statements. With the change, for inbound traffic, the security appliance denies translations for a destined IP address identified as a network or broadcast address.


The security appliance does not apply PAT to all ICMP message types; it only applies PAT ICMP echo and echo-reply packets (types 8 and 0). Specifically, only ICMP echo or echo-reply packets create a PAT xlate. So, when the other ICMP messages types are dropped, system log message 305006 (on the security appliance) is generated.


The security appliance utilizes the global IP and mask from configured static command statements to differ regular IP addresses from network or broadcast IP addresses. If the global IP address is a valid network address with a matching network mask, then the security appliance does not create a translation for network or broadcast IP addresses with inbound packets.


For example:


static (inside,outside) 10.2.2.128 10.1.1.128 netmask 255.255.255.128


Global address 10.2.2.128 is responded to as a network address and 10.2.2.255 is responded to as the broadcast address. Without an existing translation, security appliance denies inbound packets destined for 10.2.2.128 or 10.2.2.255, and logs this system log message.


When the suspected IP is a host IP, configure a separated static command statement with a host mask in front of the subnet static (first match rule for static command statements). The following static causes the security appliance to respond to 10.2.2.128 as a host address:


static (inside,outside) 10.2.2.128 10.2.2.128 netmask 255.255.255.255 static (inside,outside) 10.2.2.128 10.2.2.128 netmask 255.255.255.128


The translation may be created by traffic started with the inside host with the questioned IP address. Because the security appliance views a network or broadcast IP address as a host IP address with overlapped subnet static configuration, the network address translation for both static command statements must be the same.

vilaxmi Sat, 01/09/2010 - 12:28

Hello,


I have seen some previous posts regarding this matter but the solution is not quite clear.  Here is my issue:

I have a ASA 5505 that has 2 conifugred VLAN's; inside and outside.  Outside takes Ethernet 0/0 and inside takkes Ethernet 0/1 - 0/7.  I use outside for VPN connections and inside for internal LAN use.  The inside is on the 172.30.0.0/24 subnet.

I want to connect another network subnet, 172.30.2.0/24, to the inside 172.30.0.0/24 network.  I have a router at 172.30.0.80 that is set to route between 172.30.0.0/24 and 172.30.2.0/24 and I have set a static route in my ASA to allow traffic headed to 172.30.2.0/24 to use 172.30.0.80 as it's default gateway.

I can ping devices the 172.30.2.0/24 subnet but I cannot establish a TCP connection.  It looks like previous people have mentioned this is because ICMP is using UDP stateless connections while TCP is stateful.

Has anyone found a workaround for this problem?  I am running ASA 7.2(4).

Thanks much in advance!


So, you are running into assymetric routing issues in your network, where you can ONLY establish successful UDP/Stateless communication from one inside subnet to another  and NOT TCP/Stateful communications.


There are three workarounds in such scenarios :


1. Easiest is to use the new tcp-state-bypass mechnaism in the 8.1(x) code. But you need to upgrade you can also use our firewall to use it as you are at 7.2 now.

Here is  a link to help you :


http://cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpstatebypass.html


Scene 1 : when all the users in both subnets behind your firewall HAVE THEIR DEFAULT GATEWAY SET AS INSIDE IP OF FIREWALL.


2. You can  use nat (inside) 1 0 0 and global (inside) 1 interface and then use


static (inside,inside) x.x.x.0 y.y.y.0 netmask 255.255.255.0


static (inside,inside) y.y.y.0 x.x.x.0 netmask 255.255.255.0


Where x.x.x.0 is one of the inside subnets and y.y.y.0 is another inside subnet.


In this wrorkaround, you may be able to open connections only one way, i.e. from x.x.x.0 to y.y.y.0. and not vice versa.


Scene 1 : when all the users in both subnets behind your firewall HAVE THEIR DEFAULT GATEWAY SET AS ROUTER's IP address.


3. Here you can let the inter subnet routing being taken care of by the router and then set a default route on router which points to ASA's inside ifc.

This will make sure that all internet traffic of all inside subnets go THROUGH the firewall, and as long as TWO WAY inter subnet communication is concerned, router will take care of it just fine.


HTH


Vijaya



Actions

This Discussion