View Single Post
  #3   (View Single Post)  
Old 21st January 2012
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

We don't have quite enough information to diagnose a root cause. Based on what little we know, bridge traffic on the LAN is passing correctly. If so, this means that ARP traffic is not blocked, and IP forwarding is enabled. But Internet destined packets don't get responses. Which tends to indicate a routing problem. And now I'm at a loss, because the ASA should be able to reach any device on the subnet, since ARP and IP packets should flow, and stateful processing is used in your PF configuration. All the devices, protected and unprotected, should appear to the ASA like one big happy Ethernet LAN and all devices are on the same IP subnet.

I do notice one two things in your pf.conf. 1) This comment doesn't agree with the rule. And 2) why are you permitting a public facing webserver to operate from your protected zone? When you do this, there is little value to having a DMZ at all, as webservers should sit in the DMZ ... that's what it's for.
Code:
# allow incomming FTP, SSH, and HTTP traffic
pass in log quick on $ext_if proto tcp from any to $localnet \
     port { 80, 443 } modulate state
These are in no particular order, except I will start with routing...
  • Is the ASA your gateway route for devices in your protected zone?
  • Does Internet DNS resolve for your protected IPs? If so, does your ASA device act as your DNS server, or do you point to external DNS servers at your ISP or elsewhere?
  • What does a tcpdump trace of your external interface show -- are there responses received at the interface for Internet-bound traffic?
  • I don't speak Cisco, so I do not know if you can get ARP tables to display on its console. If so, look to see if any of your protected devices are in the table. If not, you know you have an ARP problem as far as the Cisco device is concerned.
  • If you do have an ARP problem, trace those packets and see what component is dropping them.
  • Adding log to your block rules will allow you to use tcpdump with the pflog interface to trace blocked packets .. since you have a default deny ruleset, you can see what rules you may need to add.
  • Test the bridge with a simple pass all ruleset. If suddenly things start working, you'll know the source is your PF configuration and you will need to to log your block rules and trace blocked packets.

Last edited by jggimi; 21st January 2012 at 02:04 AM.
Reply With Quote