strange HAPPENINGS

I have a router with two subinterfaces set up on it

int f0/0.900 and f0/0.922 each with a seperate network attached.

now devices in both netwroks can ping there respective interface on the router, but the router can only ping devices in the network connected to the 900 network?

The router also acts as a fire wall (1841 series router)

how ever I have turned on all logging on the firewall and I dont see packets gettign dropped. I have also tried to follow the ACL' and put loggign on them all but still no joy.

Now running a packet debug on the router and on the connected switch, I can see when you ping the nonresponding IP addesses,

From the router yo usee them getting set out int f0/0.922

and the reciving switch shows them as both comming from and going back to the router.

But Like I say I never see them arive at the router interface???

Is there any debug command I can use that will show packets ariving at the router interface f0/0.922 before any ACL's or Firewall policies are applied?

I want to know if the packets ever reach the router or not?

Cheers

Find more posts tagged with

Comments

DevilWAH

ahh never mind I sundly though if I updated the in comming acess list to include a permit statment for ICMP with a LOG command.

Now I get a log of the incomming packets and I can see they are recived by the router? now all i need to do is work out where they are going, and why it dose not see them on the control plane?

fire wall has the default of allow self to any, and I know this use to work?

wonder if there is another access list some where in the fire wall blocking it

ConstantlyLearning

DevilWAH wrote: »

ahh never mind I sundly though if I updated the in comming acess list to include a permit statment for ICMP with a LOG command.

Now I get a log of the incomming packets and I can see they are recived by the router? now all i need to do is work out where they are going, and why it dose not see them on the control plane?

fire wall has the default of allow self to any, and I know this use to work?

wonder if there is another access list some where in the fire wall blocking it

So you can see ICMP reply packets in the logs but when running the ping you don't get any ICMP replies?

DevilWAH

I can see ICMP packets incrementing the access list I applied to the incomming interface.

and now I see this line from a debug ip apcket <access list> (this access lists permits all traffic from and two 172.16.x.x)

000874: Sep 13 12:40:43.451 UTC: pak 64A7D804 consumed in enqueue feature , packet consumed, CCE Firewall(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE.

but I am not sure what that means

below is the full output for a single ICMP packet

Any ideas ?

Cheers

Planet-Router#ping 172.16.12.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.6, timeout is 2 seconds:
000784: Sep 13 12:40:35.448 UTC: IP: s=172.16.12.254 (local), d=172.16.12.6 (FastEthernet0/0.922), len 100, sending
000785: Sep 13 12:40:35.448 UTC: IP: s=172.16.12.254 (local), d=172.16.12.6 (FastEthernet0/0.922), len 100, output feature, NAT Inside(7), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000786: Sep 13 12:40:35.448 UTC: IP: s=172.16.12.254 (local), d=172.16.12.6 (FastEthernet0/0.922), len 100, output feature, Stateful Inspection(20), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000787: Sep 13 12:40:35.448 UTC: IP: s=172.16.12.254 (local), d=172.16.12.6 (FastEthernet0/0.922), len 100, output feature, CCE Post NAT Classification(30), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000788: Sep 13 12:40:35.448 UTC: IP: s=172.16.12.254 (local), d=172.16.12.6 (FastEthernet0/0.922), len 100, output feature, Firewall (firewall component)(31), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000789: Sep 13 12:40:35.448 UTC: IP: s=172.16.12.254 (local), d=172.16.12.6 (FastEthernet0/0.922), len 100, sending full packet
000790: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254, len 100, input feature, Stateful Inspection(4), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000791: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254, len 100, input feature, Virtual Fragment Reassembly(21), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000792: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254, len 100, input feature, Access List(26), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000793: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254, len 100, input feature, Virtual Fragment Reassembly After IPSec Decryption(32), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000794: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254, len 100, input feature, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000795: Sep 13 12:40:35.452 UTC: IP: tableid=0, s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254 (FastEthernet0/0.922), routed via RIB
000796: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254 (FastEthernet0/0.922), len 100, output feature, NAT Inside(7), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000797: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254 (FastEthernet0/0.922), len 100, output feature, Stateful Inspection(20), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000798: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254 (FastEthernet0/0.922), len 100, rcvd 3
000799: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254, len 100, stop process pak for forus packet
000800: Sep 13 12:40:35.452 UTC: IP: s=172.16.12.6 (FastEthernet0/0.922), d=172.16.12.254, len 100, enqueue feature, CCE post NAT(1), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
000801: Sep 13 12:40:35.452 UTC: pak 64A7D05C consumed in enqueue feature , packet consumed, CCE Firewall(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE.
 
Success rate is 0 percent (0/5)

　
Go on tell me its something really simple

DevilWAH

Ahh things beging to make sence..

the passage

Although the router offers a default-allow policy between all zones and the self zone, if a policy is configured from any zone to the self zone, and no policy is configured from self to the router’s user-configurable interface-connected zones, all router-originated traffic encounters the connected-zone to self-zone policy on its return the router and is blocked. Thus, router-originated traffic must be inspected to allow its return to the self zone.

from https://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00808bc994.shtml

gave me the answer.

I had a policy in place that used an ACL to restrict access from the inside networks to the router (this was applied to the interface). That only allowed ICMP to the DFGW address (to check the DFGW was up), blocked all other traffic to that IP and allow all traffic to other IP address.

The idea preventing people in the inside network from managing the router.

however when I set up easy VPN I used the SDM (I know stupid me), and one of the things it did was to create a firewall policy that added a ACL policy from the inside network to self that went at the start of the list saying.

Permit any any protocol easy-vpn

It seems the default self to any did not like this and started blocking the packets.

So nice of cisco's Easy VPN wizzard to break it

and not only break it but becasue there is not policy self to inside created it does not even log or alert you where the packets are getting dropped!

But at least getting some where now

It seems I need to add two policies one from inside to self permitting ICMP and dropping the rest.

and once from self to inside allowing and inspecting all.

I just need to check what I need to set up for "IP-Helper address" I supose I will need to add a policy from inside to self to allow DHCP traffic.

DevilWAH