ASA 5505 Cannot communicate accross vlans

[rcsjohnathan1]

Let me start by saying it has been some time since I have configured any cisco device. I have an ASA 5505 that I cannot ping through. as of right now for testing I have the network setup as follows. I have a server on the inside interface at IP 192.168.3.16/24. I have a client trying to access the server (via UDP ports 50000-50002) on the outside interface at IP 10.23.15.9/24. I also have my laptop that I am attempting to ping with. If my laptop is connected to the Inside Vlan I can ping the server but not the client. If my laptop is connected to the Outside Vlan I can ping the client but not the server. The client and server are not talking at all. For my testing purposes all that is in the network is the ASA, my laptop, the Client, and the Server. I don't work on cisco products a whole lot so any help would be appreciated.

The Client is connected to ETH0/0 and the server to ETH0/2

: Saved
:
ASA Version 8.2(5)
!
hostname routeswitch
enable password muxOvcHkd/3QWG7v encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
switchport access vlan 2
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.3.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 10.23.15.8 255.255.255.0
!
ftp mode passive
object-group network inside-subnet
object-group network inside-net
object-group network ANY
access-list 101 extended permit icmp any any echo-reply
access-list 101 extended permit icmp any any source-quench
access-list 101 extended permit icmp any any unreachable
access-list 101 extended permit icmp any any time-exceeded
access-list 101 extended permit udp any any range 50000 50002
pager lines 24
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
access-group 101 out interface inside
access-group 101 in interface outside
route inside 0.0.0.0 0.0.0.0 10.23.15.1 1
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 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 192.168.1.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
sla monitor 123
type echo protocol ipIcmpEcho 192.168.1.181 interface outside
num-packets 3
frequency 10
sla monitor schedule 123 life forever start-time now
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
!
track 1 rtr 123 reachability
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside
!

threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
!
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous
Cryptochecksum:f642943f052ddc72753f8cd5d052007a

[Richard Burts]

I do not believe that you need to apply the access list on the inside interface and suggest that you remove

access-group 101 out interface inside

Also the access list permits echo-reply but not echo. So the attempt to ping from the client will be denied.

Another issue is your default route

route inside 0.0.0.0 0.0.0.0 10.23.15.1 1

But this route should use interface outside and not inside.

Make these changes and let us know if the behavior changes.

HTH

Rick

[rcsjohnathan1]

Thank you for the response Rick,

I made the changes that you suggested and I am still unable to ping and there is no communication via UDP from between client and server.

So just to clarify, I am attempting to allow UDP traffic in either direction as well as pings. I have worked with ACLs one time before (years ago) and it was very basic so it would be safe to assume I know almost nothing on the subject.

[Richard Burts]

Could you add an inspect for ICMP? This would go under class inspection_default.

Could you also post the output of the command show arp

Could you enable logging buffered and then when you are attempting to send from client to server look in the logs and see what might be there about the connection attempt?

HTH

Rick

[rcsjohnathan1]

Hey Rick,

Sorry I am so green to this. Here is the show ARP command

routeswitch(config-pmap)# sho arp
inside 192.168.3.16 6469.bc04.dfbf 41
inside 192.168.3.10 a0b3.cc23.da1e 261
outside 10.23.15.9 6469.bc04.e8cb 10

I am unsure what commands to run to add an inspect for ICMP I will see if I can google that one up real quick. I also turned on logging so once I find the log I will let you know what I find on the connection attempt.

[rcsjohnathan1]

Okay I have turned on Inspect ICMP and have checked the log, there are no messages in the buffered log.

[Richard Burts]

I had hoped that there would be helpful information in the logs, but if there is not then we will take a different approach to this issue. I suggest that for now we focus on traffic initiated from the server on the inside interface to the client on the outside interface. The traffic from inside to outside should be permitted and any response to that traffic should be permitted. So what happens if you attempt a ping from the server to the client?

HTH

Rick

[rcsjohnathan1]

I am able to ping the client from the inside interface.

[rcsjohnathan1]

Is there any way to set this up as passing any and all traffic through? When these devices go live on the network the ASA is pretty much going to be just an SLA monitor point.

[Richard Burts · Accepted solution]

If you want to pass all traffic then it should be possible to simply configure an extended access list with a permit ip any any and assign that ACL in on the outside interface. That is not a typical approach on an ASA, but the ASA is usually functioning as a firewall. If you basically want just an SLA monitor it seems this should work.

HTH

Rick

[rcsjohnathan1]

Well I was playing around with the settings here and I have found that if I set the outside security level higher than the inside the UDP traffic flows no problem. The server and client can talk both ways. Thank you for all of your help rick. I will be putting this in place on Wednesday and will post just to let you know how the cutover goes

[Richard Burts]

I am glad that you figured out a way to get it to work. On an ASA traffic initiated from a higher level interface is always allowed to a lower level interface and response traffic is always allowed. So when you make the outside interface level higher than the inside interface then the UDP traffic would flow to the server and response traffic would flow back. While it is an unusual config on an ASA to have the outside interface a higher level than the inside interface it works in your situation.

It would also have worked to get UDP traffic from the client to the server to configure an access list that permitted the traffic from outside to inside. But if you have a config that works it may not be worth the effort to get a different way to get it to work.

Please do post back and let us know how it does as you put it into production.

HTH

Rick