Bridging firewall with OPenBSD 5.0

[scrummie02]

I have a switch with multiple VLANS with a DMZ. I nave some servers that need protecting within the DMZ so I've decided to implement an OpenBSD bridging/transparent firewall.

So far I'm connected and I can ping stuff from the internal network (i.e. I can ping my gateway and servers on the "other" side of the firewall), but I can't get to the internet from the servers or nodes behind the firewall.

For some clarification here is what I have:

ext-->ASA-->DMZ--->OBSD PF ---->Protected I.P.'s

They're all the same network (192.168.10.0/24). So I can easily connect to nodes on the other side of the OpenBSD firewall just not the internet.

Here is my pf.conf

int_if = "em1"
ext_if = "em2"

localnet = "192.168.0.0/24"



# 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, 81, 443 } modulate state

# 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

# 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

Also, I'm questioning whether a bridging firewall would be good as opposed to just a filtering firewall. Since all of the machines are already IP'ed I don't want to change any IP's and double NAT is messy.

Any help is appreciated.

[J65nko]

The classic setup for a DMZ firewall with pf is one with a box with three NIC's:

1. external interface : connecting to the dangerous Internet
2. DMZ interface - connection to the servers in the DMZ
3. internal interface - connecting the internal LAN

Is this an option for your?

[jggimi]

Originally Posted by J65nko

The classic setup for a DMZ firewall with pf is one with a box with three NIC's...

Heh. The best practice for a single DMZ is two firewalls, inner and outer, with a DMZ network in between. My current customer has many tiers, each with its own set of firewalls and each with unique rulesets.

[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.

# 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.

[scrummie02]

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.

# 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:

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.