ICMP msg sent in wrong routing instance

Unanswered Question
Jul 3rd, 2007

Scenario: We have a simple VRF setup running on a Cat4500 Sup IV. The global routing instance maintains multiple subnets and a default route to a PIX firewall. This is considered the secure inside. No dynamic routing is used.

Next to that there is a VRF instance that maintains five guest networks which use a different internet exit towards an ADSL router. This is considered the public, insecure network. No dynamic routing deployed here either. We have added inbound ACLs on each public network to prevent them to communicate with private addresses and only allow them to go out the ADSL exit.

Problem: Some systems on those public networks try to contact private destination addresses, which is prevented through the mentioned ACLs on the VLAN interfaces. Upon denial, IOS sends an ICMP type 3 code 13 message back to the originating host. Unfortunately, this packet doesn't get sent within the VRF instance back to the originating host, yet it will be originated from the L3 interface that points to the PIX in the global routing instance.

This is the message that the PIX logs:

4 Jul 03 2007 11:18:11 313005 No matching connection for ICMP error message: icmp src inside:172.26.2.2 dst outside:192.168.4.136 (type 3, code 13) on inside interface. Original IP payload: udp src 192.168.4.136/49156 dst 192.168.136.55/161.

So the PIX complains about an ICMP message which it doesn't have a connection installed for. That's reasonable, but doesn't explain why IOS originates the message from the global RT.

Question: Does anybody have an explanation for this behaviour? Can I control the source for the ICMP message individually?

Config on the Cat4500:

ip vrf public-internet

rd 1:100

route-target export 1:100

route-target import 1:100

!

interface Vlan596

description Guest WLAN

ip vrf forwarding public-internet

ip address 192.168.4.2 255.255.255.0

ip access-group Guest-WLAN in

ip helper-address 192.168.1.1

standby 60 ip 192.168.4.1

standby 60 priority 110

standby 60 preempt

!

interface Vlan597

description Guest VLAN Entwicklung

ip vrf forwarding public-internet

ip address 192.168.3.2 255.255.255.0

ip access-group Guest-Entwicklung in

ip helper-address 192.168.1.1

standby 60 ip 192.168.3.1

standby 60 priority 110

standby 60 preempt

!

interface Vlan598

description Guest VLAN Produktion

ip vrf forwarding public-internet

ip address 192.168.2.2 255.255.255.0

ip access-group Guest-Produktion in

ip helper-address 192.168.1.1

standby 60 ip 192.168.2.1

standby 60 priority 110

standby 60 preempt

!

interface Vlan599

description Guest VLAN

ip vrf forwarding public-internet

ip address 192.168.1.252 255.255.255.0

standby 60 ip 192.168.1.254

standby 60 priority 110

standby 60 preempt

!

ip route 0.0.0.0 0.0.0.0 172.26.2.11

ip route vrf public-internet 0.0.0.0 0.0.0.0 Vlan599 192.168.1.1

!

ip access-list extended Guest-Entwicklung

permit udp any any eq bootpc

permit udp any any eq bootps

permit ip 192.168.3.0 0.0.0.255 host 172.26.13.12

deny ip any 192.168.0.0 0.0.255.255

deny ip any 172.16.0.0 0.15.255.255

deny ip any 10.0.0.0 0.255.255.255

permit ip any any

ip access-list extended Guest-Produktion

permit udp any any eq bootpc

permit udp any any eq bootps

permit ip 192.168.2.0 0.0.0.255 host 172.26.13.125

deny ip any 192.168.0.0 0.0.255.255

deny ip any 172.16.0.0 0.15.255.255

deny ip any 10.0.0.0 0.255.255.255

permit ip any any

ip access-list extended Guest-WLAN

permit udp any any eq bootpc

permit udp any any eq bootps

deny ip any 192.168.0.0 0.0.255.255

deny ip any 172.16.0.0 0.15.255.255

deny ip any 10.0.0.0 0.255.255.255

permit ip any any

ip access-list extended Schulung

permit udp any any eq bootpc

permit udp any any eq bootps

deny ip any 192.168.0.0 0.0.255.255

deny ip any 172.16.0.0 0.15.255.255

deny ip any 10.0.0.0 0.255.255.255

permit ip any any

!

Thanks for any hint!

Toni

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

This is a connection-related message. This message occurs when an attempt to connect to an inside address is denied by your security policy. Possible tcp_flags values correspond to the flags in the TCP header

that were present when the connection was denied. For example, a TCP packet arrived for which no connection state

exists in the PIX Firewall, and it was dropped. The tcp_flags in this packet are FIN and ACK.

tgrundbacher Mon, 07/09/2007 - 22:35

Thanks for your reply. I'm aware what the PIX is trying to tell me. Yet this is not the issue here, I want to find out why IOS sends the ICMP message from the global routing table and not within the VRF.

Anybody got an idea?

Actions

This Discussion