Quote:
Originally Posted by jggimi
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.
|
Okay, it appears not that traffic passes, but I can't seem to filter it as I need.
I have some web servers that need extra protection that's why 80/443 are open.
My pf.conf is as follows:
Code:
int_if = "em1"
ext_if = "em2"
localnet = "192.168.100.0/24"
set loginterface em2
# we only want to filter one interface, so pass everything on the inside interface
pass in quick on $int_if all
pass out quick on $int_if all
# block everything by default on the external interface
block in log on $ext_if all
block out log on $ext_if all
# allow UDP DNS traffic
pass out log quick on $ext_if proto udp from $localnet to any port 53 keep state
# allow FTP, SSH, DNS and HTTP traffic to trusted networks
pass out log quick on $ext_if proto tcp from $localnet to any port { 20, 21, 22, 53, 80, 443, } modulate state
# allow incomming FTP, SSH, and HTTP traffic
#pass in log quick on $ext_if proto tcp from any to $localnet port {20, 21, 22, 80, 81, 443 } modulate state
# allow pings
pass in log on $ext_if proto icmp from any to $localnet icmp-type 8 code 0 keep state
pass out log on $ext_if proto icmp from $localnet to any icmp-type 8 code 0 keep state
When I run TCP dump it looks like I'm passing netbios traffic - which is one of the reasons I implemented this thing..to stop broadcasts.