interface connectivity issue on 887VAM

[Jobin Varghese]

I have configured an 887VAM. But the devices on the FastEthernet port (10.100.100.2) cannot be reached from the router. The following is my configuration snapshot

Building configuration...

Current configuration : 4033 bytes
!
! Last configuration change at 21:08:41 UTC Sat Jul 11 2015 by netadmin
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname %%%%
!
boot-start-marker
boot-end-marker
!
!
logging buffered 51200 warnings
!
no aaa new-model
!
crypto pki trustpoint TP-self-signed-243562899
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-243562899
 revocation-check none
 rsakeypair TP-self-signed-243562899
!
!
crypto pki certificate chain TP-self-signed-243562899
 certificate self-signed 01
  30820229 30820192 A0030201 02020101 300D0609 2A864886 F70D0101 05050030
  30312E30 2C060355 04031325 494F532D 53656C66 2D536967 6E65642D 43657274
  69666963 6174652D 32343335 36323839 39301E17 0D313330 37303830 35353932
  355A170D 32303031 30313030 30303030 5A303031 2E302C06 03550403 1325494F
  532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3234 33353632
  38393930 819F300D 06092A86 4886F70D 01010105 0003818D 00308189 02818100
  B9ADE65D 965105AC B6E02B88 971F3460 0E626788 E0F261F6 1D73ED35 64D61630
  120B0C30 CDFEC197 AF281398 0EFDCB5B 37EDBA39 2A6D4CAB 6380C12C C9C0CD58
  DFF94AE4 36F9F88E D32353BF DE481510 E2847FBC 615AEC4A 829A5E13 ED209A25
  B4A5EC06 0A50B6FA BF86D8AD 6C42B104 84ED90E7 FA47DACB 8DBD423C D1F5EBF1
  02030100 01A35330 51300F06 03551D13 0101FF04 05300301 01FF301F 0603551D
  23041830 168014D7 885E8D60 BFEAC958 2DCAE5F9 7A3D1941 6F345830 1D060355
  1D0E0416 0414D788 5E8D60BF EAC9582D CAE5F97A 3D19416F 3458300D 06092A86
  4886F70D 01010505 00038181 0088B3CE 05502861 E3C796A2 DD0D8C7E 579AA34A
  4D01B554 586376B0 DFF254DB AD4F29AC 6E4F7C69 B868D995 58FE0959 0D085D25
  64D9A275 E76CE364 FE09BE3D 53538F97 6D14D231 148F0DED 3C240FAE 3265AE32
  076F8091 974D0939 893C9CC0 1C86F513 1A924BDF D259EE04 66DCFDBA 7829E09A
  3DB592ED 9FCAE29E 9988726D 0B
        quit
ip cef
!
!
!
!
!
!
ip name-server %%%
ip name-server %%%
ip name-server %%%
ip name-server %%%
no ipv6 cef
!
!
license udi pid C887VA-W-E-K9 sn FCZ1728909C
!
!
username %%% privilege 15 secret 4 %%%
username %%% privilege 15 secret 4 %%%
!
!
!
!
!
controller VDSL 0
!
!
!
!
!
!
!
!
!
!
interface ATM0
 no ip address
 no atm ilmi-keepalive
 pvc 0/35
  pppoe-client dial-pool-number 1
 !
!
interface Ethernet0
 no ip address
!
interface FastEthernet0
 no ip address
!
interface FastEthernet1
 no ip address
!
interface FastEthernet2
 no ip address
!
interface FastEthernet3
 no ip address
!
interface Wlan-GigabitEthernet0
 description Internal switch interface connecting to the embedded AP
 no ip address
!
interface wlan-ap0
 description Service module interface to manage the embedded AP
 no ip address
!
interface Vlan1
 description LAN
 ip address 10.100.100.1 255.255.255.248
 ip nat inside
 ip virtual-reassembly in
!
interface Dialer1
 ip address negotiated
 ip nat outside
 ip virtual-reassembly in
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication pap chap callin
 ppp chap hostname %%%
 ppp chap password 0 %%%
 ppp pap sent-username %%% password 0 %%%
 no cdp enable
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
ip nat inside source list 110 interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 Dialer1
!
access-list 110 permit ip 10.100.100.0 0.0.0.7 any
no cdp run
!
!
!
line con 0
 logging synchronous
 login local
 no modem enable
line aux 0
line 2
 no activation-character
 no exec
 transport preferred none
 transport input all
 stopbits 1
line vty 0 4
 access-class 23 in
 privilege level 15
 logging synchronous
 login local
 transport input telnet ssh
line vty 5 15
 access-class 23 in
 privilege level 15
 logging synchronous
 login local
 transport input telnet ssh
!
scheduler allocate 20000 1000
!
end

[Peter Paluch]

Hi Jobin,

I understand that you cannot ping 10.100.100.2 from 10.100.100.1. How about the other way around: Is it possible to ping 10.100.100.1 from 10.100.100.2? If yes then you should check the firewall configuration on 10.100.100.2 - most operating systems nowadays like to tighten down the network communication.

If neither 10.100.100.1 nor 10.100.100.2 can ping each other (with the ping initiated from both sides) then I suggest verifying the physical layer first. Are the FastEthernet ports reported as "Status up, Protocol up" in show ip interface brief? Are the port LEDs lit? Do the computers report any connectivity on their NICs? If you enable CDP on your router and start Wireshark on your attached computers, can you see CDP packets coming in every 60 seconds?

Best regards,
Peter

[Jobin Varghese]

Hi Peter,

10.100.100.2 is an UTM device. Neither from there nor from the router a result for ping is there. All LED are lit up

*Jul 12 10:33:42.253: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to up
*Jul 12 10:33:45.265: %LINK-3-UPDOWN: Interface FastEthernet1, changed state to up

#sh ip int brie
Interface                  IP-Address      OK? Method Status                Protocol
ATM0                       unassigned      YES NVRAM  up                    up  
Dialer1                    cc.ccc.cc.ccc   YES IPCP   up                    up  
Ethernet0                  unassigned      YES NVRAM  down                  down
FastEthernet0              unassigned      YES unset  up                    up  
FastEthernet1              unassigned      YES unset  up                    up  
FastEthernet2              unassigned      YES unset  down                  down
FastEthernet3              unassigned      YES unset  up                    down
NVI0                       unassigned      YES unset  administratively down down
Virtual-Access1            unassigned      YES unset  up                    up  
Vlan1                      10.100.100.1    YES NVRAM  up                    up  
Wlan-GigabitEthernet0      unassigned      YES unset  up                    up  
wlan-ap0                   unassigned      YES NVRAM  up                    up  

[Peter Paluch]

Hi Jobin,

Okay, and how about show mac address-table (or the older show mac-address-table) command? Can you see any MAC addresses learned on the FastEthernet ports? In addition, after pinging 10.100.100.2 from the router, what does the show ip arp say about 10.100.100.2?

Finally, if you have physical access to the device, if you connected another device to a free FastEthernet port and assigned it some unused IP in 10.100.100.0/29, would that device be able to ping things?

Best regards,
Peter

[Richard Burts]

I especially like the suggestions to check the arp table and the mac address table. These will show whether there is communication with the device. If these tables have no entry for the device then we should be looking for layer 1 or layer 2 problems. If there are entries in these tables then we should be looking for layer 3 or higher problems.

HTH

Rick

[Jobin Varghese]

These are certain outputs I received. I had my laptop on Fa3,  the UTM devices are on High-Availability connected to Fa0 and Fa1.

show mac-address-table
Destination Address  Address Type  VLAN  Destination Port
-------------------  ------------  ----  --------------------
0021.9bdc.8731          Dynamic       1     FastEthernet3
0090.fb48.74b8          Dynamic       1     FastEthernet1
00e0.2011.08fd          Dynamic       1     FastEthernet0
6c41.6a5a.a3f0          Self          1     Vlan1
6c41.6a5a.a3fe          Dynamic       1     Wlan-GigabitEthernet0

sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.100.100.1            -   6c41.6a5a.a3f0  ARPA   Vlan1
Internet  10.100.100.2            0   00e0.2011.08fd  ARPA   Vlan1
Internet  10.100.100.4            0   0021.9bdc.8731  ARPA   Vlan1

console> ping 10.100.100.1
PING 10.100.100.1 (10.100.100.1): 56 data bytes
64 bytes from 10.100.100.1: seq=0 ttl=255 time=0.810 ms
64 bytes from 10.100.100.1: seq=1 ttl=255 time=1.038 ms
64 bytes from 10.100.100.1: seq=2 ttl=255 time=0.796 ms
64 bytes from 10.100.100.1: seq=3 ttl=255 time=0.893 ms
64 bytes from 10.100.100.1: seq=4 ttl=255 time=1.062 ms
64 bytes from 10.100.100.1: seq=5 ttl=255 time=0.816 ms
64 bytes from 10.100.100.1: seq=6 ttl=255 time=0.771 ms

I am getting a ping from the UTM now, but the router does not ping any device.

ping 10.100.100.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.100.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
ping 10.100.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.100.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

I did change the access-list 

ip nat inside source list 1 interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 Dialer1
!
access-list 1 permit 10.100.100.0 0.0.0.7

[Peter Paluch]

Hi Jobin,

Okay, let's see - I've got a series of comments and questions so I'll just post them all here without any particular order. Please be so kind to answer or comment each one of them.

1. What exactly does the 'UTM' acronym stand for?
2. What do you mean by saying that the UTM devices are connected for high availability to Fa0 and Fa1? What kind of high availability is that? Does it require some specific configuration on the side of the router? This may be important.
3. Notice that the MAC address table is being populated and the ARP table shows entries that are very fresh - their age is "0 minutes", meaning less than 60 seconds. That proves that the ARP works just fine and so the basic Layer2 connectivity to the devices is working.
4. The fact that the router is unable to ping the UTM devices does not necessarily indicate that there is a problem in communication but rather that the devices are not willing to respond to ping requests. Many devices, especially security devices, behave in the same way, and it is kind of expected, even though unsettling at first.
5. The fact that you were not able to ping your laptop (it was the 10.100.100.4, right?) is because all recent Windows versions (assuming you're running Windows) block incoming pings unless the network is configured as a home network or a trusted workplace network. You'd need to disable your Windows firewall temporarily to be absolutely certain that it's not causing troubles. Can you try it and do the ping again?
6. So far, we have focused on the inability to ping the UTM devices from the router. However, I suppose that the UTM devices, or the networks behind them, want to communicate with internet. Is this communication successful, i.e., can the UTMs or networks behind them (if there are any) access internet successfully? If yes then there is nothing wrong with your config at all.
7. Replacing the extended ACL with a standard ACL did not, in my opinion, have any impact - but it did not hurt, either.

Looking forward to hearing from you.

Best regards,
Peter

[Richard Burts]

I agree with Peter that the outputs are encouraging. They show that layers 1 and 2 are working just fine. The router knows the MAC addresses and the ARP relationship of the UTM device. So we need to be looking at upper layers of the protocol stack for explanation of this issue.

You showed attempts to ping from the router to 10.100.100.4 which failed. And I believe that there is merit in Peter's explanation for this. What I would like to know is whether 10.100.100.4 can ping the router address?

I also wonder if some communication from your laptop other than ping to the UTM might be successful. Would the UTM respond to an attempt to connect using HTTP or HTTPS or SSH?

HTH

Rick 

[Jobin Varghese]

As of now HTTP, HTTPS all work fine from laptop and UTM. The curious thing is that I cant ping from router to the device.

[Jobin Varghese]

1. UTM (Unified Threat Management) - A firewall. We are using a device called Cyberoam.

2. There are 2 UTM of the same spec, connected to each other by a cross over cable. Once a device fails the other becomes Master or Primary. Both are connected to the Similar ports on each UTM. A Cisco 887-K9 on ver 15.0 running another DSL communicates fine. This is a  Cisco C887VA-W-E-K9 running ver 15.2.

6. Yes, the devices can access Internet.

7. I donno about this, cos prior I had no ping. Now there is a one way ping.

[Richard Burts]

If HTTP and/or HTTPS are working with the UTM device then I believe that things are working and there is not any real problem. Knowing that this is a firewall device makes me comfortable that the issue with ping is a security setting or policy on the firewall. Firewalls are well known for being very restrictive about the kind of traffic to which they will respond.

HTH

Rick