«

[WabukiSensei]

Hi, newbie to the forums.


I'm currently working on a project where I have to use a CISCO ASA 5510 as a router-on-a-stick for my network due to the resources that I am limited to. Initially my whole network was working fine with subinterfaces configured on the device where each is put into a separate vlan. After a few days of leaving the entire system off, I turned the system back on only to discover that the device is currently disconnected from the rest of the network and I can no longer to inter-vlan routing because of this. Pinging to the ASA results to nothing, but pinging from the ASA to other devices reveal question marks:


ciscoasa# ping 192.168.2.2
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
ciscoasa#


Wondering if the device itself could not connect to any other devices, I set up a connectivity test, basically by assigning an ip address to one interface and another ip address within the same subnet to the neighbor's interface and they are able to ping each other.

It seems when I set it up for vlan communication, the ASA router cannot detect anything. Below is the running-config unedited:


ciscoasa# show run
: Saved
:
ASA Version 7.0(5)
!
hostname ciscoasa
enable password 8Ry2YjIyt7RRXU24 encrypted
names
dns-guard
!
interface Ethernet0/0
nameif inside
security-level 100
ip address 192.168.0.254 255.255.255.0
!
interface Ethernet0/0.1
vlan 1
nameif VL_1
security-level 100
no ip address
!
interface Ethernet0/0.2
vlan 2
nameif VL_2
security-level 100
ip address 192.168.2.254 255.255.255.0
!
interface Ethernet0/0.3
vlan 3
nameif VL_3
security-level 100
ip address 192.168.3.254 255.255.255.0
!
interface Ethernet0/1
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
shutdown
no nameif
no security-level
no ip address
management-only
!
passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
same-security-traffic permit inter-interface
pager lines 24
mtu inside 1500
mtu VL_1 1500
mtu VL_2 1500
mtu VL_3 1500
icmp permit any inside
icmp permit any echo inside
icmp permit any echo-reply inside
no asdm history enable
arp timeout 14400
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
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
telnet 192.168.0.0 255.255.255.0 inside
telnet timeout 5
ssh timeout 5
console timeout 0
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map global_policy
class inspection_default
inspect dns maximum-length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
!
service-policy global_policy global
Cryptochecksum:80b5d280306638f7a2c92c15e3c18008
: end
ciscoasa#


I'd like to point out that this section of the config:

interface Ethernet0/0
nameif inside
security-level 100
ip address 192.168.0.254 255.255.255.0
!
interface Ethernet0/0.1
vlan 1
nameif VL_1
security-level 100
no ip address

the original working setup was to have the ip address 192.168.0.254 255.255.255.0 command assigned to int e0/0.1 (it was working before this problem came up) but doing that and trying to ping the subinterface would result in the 'question mark pings' as I previously mentioned. Letting int e0/0 have the ip address allows for ping connectivity, but only to that ip address. All the other subinterfaces configured are unreachable from other devices.

This running-config was working, give or take a few commands (that might potentially take care of the problem) which I can't remember. Did I miss a few crucial commands to enable connectivity?

Appreciate all the help!

[globalchicken]

From first glance, yes thats what i noticed. The ip address is assigned to main interface. Now i am not sure that working on ASA is any different than working on 26xx 37xx, ect, but the ip address has to be on the subinterfaces, the main interface can not have an ip. The interface has to be up and the switchport on your switch that connects has to be a TRUNKing port. HAve you checked that yet?
Also not having any experience with the ASA, Is there a way to define your encapsulation type as i dont see that. Either ISL (if supported) but preferably dot1q.
http://www.cisco.com/en/US/products/...html#wp1044006

I found a link that describes that dot1q, is the encapsulation type, this link also describes configuring your ASA subinterfaces.

Like I said above maybe check your switch and ensure the link is trunked.

Check out this note that I found on the above link:

If you use subinterfaces, you typically do not also want the physical interface to pass traffic, because the physical interface passes untagged packets. Because the physical interface must be enabled for the subinterface to pass traffic, ensure that the physical interface does not pass traffic by leaving out the nameif command. If you want to let the physical interface pass untagged packets, you can configure the nameif command as usual.

I would reconfigure the interface as such according to the documentation:

interface Ethernet0/0
security-level 100

!
interface Ethernet0/0.1
vlan 1
nameif VL_1
security-level 100
ip address 192.168.0.254 255.255.255.0


In your opinion, what is the difference between the PIX and the ASA?
Also, what is the purpose of the security-level command?

M

[WabukiSensei]

Originally Posted by globalchicken

From first glance, yes thats what i noticed. The ip address is assigned to main interface. Now i am not sure that working on ASA is any different than working on 26xx 37xx, ect, but the ip address has to be on the subinterfaces, the main interface can not have an ip. The interface has to be up and the switchport on your switch that connects has to be a TRUNKing port. HAve you checked that yet?
Also not having any experience with the ASA, Is there a way to define your encapsulation type as i dont see that. Either ISL (if supported) but preferably dot1q.
http://www.cisco.com/en/US/products/...html#wp1044006

I found a link that describes that dot1q, is the encapsulation type, this link also describes configuring your ASA subinterfaces.

Like I said above maybe check your switch and ensure the link is trunked.

Check out this note that I found on the above link:

If you use subinterfaces, you typically do not also want the physical interface to pass traffic, because the physical interface passes untagged packets. Because the physical interface must be enabled for the subinterface to pass traffic, ensure that the physical interface does not pass traffic by leaving out the nameif command. If you want to let the physical interface pass untagged packets, you can configure the nameif command as usual.

I would reconfigure the interface as such according to the documentation:

interface Ethernet0/0
security-level 100

!
interface Ethernet0/0.1
vlan 1
nameif VL_1
security-level 100
ip address 192.168.0.254 255.255.255.0


In your opinion, what is the difference between the PIX and the ASA?
Also, what is the purpose of the security-level command?

M

Thanks for the reply. The original configuration (when it was working) isn't supposed to have an IP for the physical address, I just put it there because assigning the IP to int e0/0.1 wasn't working (none of the subinterfaces were working). I was only able to obtain connectivity only via the physical interface, so I did that just for testing purposes.

Yes, the ASA does automatically make it dot1q capable. In terms of trunking, the firewall is connected to a non-Cisco device and as I mentioned earlier, was working fine before this (for some reason the switch doesn't have any trunking capabilities).

Since all the devices are internal, or on the 'inside' I needed to set them all to the same security level and then enable the 'same-security-traffic permit inter-interface' so that they could communicate with each other.

Regarding the differences between the ASA and PIX, I'm not too sure about any differences since I've had limited exposure to them. So far they seem to be pretty much the same in terms of OS and commands.

I guess the main issue that I'm facing is that my configuration was working for a certain time, then when I powered the firewall back on after turning it off for a few days, the firewall just wouldn't cooperate anymore (with the exact same configs). But I do appreciate your suggestion and will continue to figure out what's wrong.

Thanks

[globalchicken]

Thanks for that good info. The only thing that i do not understand is that you said your non cisco switch does not support trunking. how then do you allow multiple vlans to traverse over that one link and your ASA recogize them as being in different vlans with different subnets? Trunking would allow all vlans or at least the ones you specify to travel over that link and communicate with the appropriate subinterface. I would still consider looking into the switch. Like I said, that does not make sense that your switch is not trunking.

[WabukiSensei]

Originally Posted by globalchicken

Thanks for that good info. The only thing that i do not understand is that you said your non cisco switch does not support trunking. how then do you allow multiple vlans to traverse over that one link and your ASA recogize them as being in different vlans with different subnets? Trunking would allow all vlans or at least the ones you specify to travel over that link and communicate with the appropriate subinterface. I would still consider looking into the switch. Like I said, that does not make sense that your switch is not trunking.

Glad to help out! Regarding the non Cisco switch, I believe it is because the way they make different VLANs communicate with each other is a bit different. It gets the job done, but I wouldn't call it trunking. Honestly, I'm not too sure how it works either, it just happened to work after we were messing around with the settings for those switches

On another note, we've decided to try another alternative for the system we're doing and we won't be using the firewall for layer 3 purposes anymore (couldn't figure out the problem.) This is actually a better solution than using the firewall actually, and I am more comfortable with this design, hehe.