07-03-2007 02:17 AM
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
07-09-2007 10:10 AM
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.
07-09-2007 10:35 PM
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?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide