Transparent Bridge Firewall :: filter rules seems to be non-functional

[shamims]

Dear List members

Recently I decided to put an additional firewall between a server and the connection. Below is an ascii art of the connections.

                             WAN                  LAN
 .--------------------.       .--------------------.       .--------------------.
 |      DSL Modem     |-------|       pfSense      |-------|       Server       |
 '--------------------'       '--------------------'       '--------------------'
                                       |                        PPPoE
                                       |Management              Dialer
                                       |Interface
                                       |10.x.x.x  

As you can see, even though there is a modem, it acts like a bridge, and the server itself does the PPPoE dialing and get the IP.

Some basic information:
Firewall: PCEngines Alix board with 3 interfaces, running pfSense i386 4GB image. WAN and LAN bridged, OPT1 used for management.

this is what I did in short
1. configured the third interface of the firewall as OPT1 (renamed), gave it a fixed IP, allowed all management access to it, ran DHCP on that interface so whatever I connect will get an IP from the box

2. configure WAN and LAN interfaces with NONE is both IPv4 and IPv6

3. bridged WAN and LAN, created the OPT2 interface with bridge on it, deleted all outbound NAT after making it manual.

4. system tunables, changed net.link.bridge.pfil_bridge to 1

5. set up aliases for the hosts and the ports my server needs to connect from/to (it does not offer any service to the world – just communicates with certain other specific hosts)

6. set up rules on WAN and LAN to allow access to the aliased hosts on the aliased ports.

7. restarted the firewall, made sure all the rules are there.

My thoughts are, this is all I need to do -- unless I am missing something very obvious.

However, despite my expectation, the firewall/bridge is not blocking anything. There are still traffic coming into the server from hosts which are not in my alias list, on ports that are not specifically allowed.

Just to make sure I am not missing something obvious, I started tcpdump on the server (NOT the firewall, the server, which is supposed to be protected), then ran nmap from a server that is NOT listed in any of the aliases. And I could see the packets flow by on the server.

Decided to take a drastic step, and added a default deny at the bottom of both LAN and WAN (deny any from any to any) -- still no joy. one more nmap, one more scrolling screen of packets being received at the server.

I have added some screenshot to make some sense. But if you require further information, or if I have forgotten to mention something, please let me know and I'll do my best to accommodate.

It is very likely that I have missed something very obvious -- but for the life of me I cannot see it. Any help/suggestion/pointer is greatly appreciated.

Thanks to all
Shah

[cmb]

Is PPPoE the only traffic going across the bridge?

Don't enable filtering on both the members and the bridge, either one or the other, depending on your preference. That has nothing to do with the issue at hand here though from the sounds of it.

[shamims]

Thanks for looking into this. To answer your questions

a. Originally there was nothing between the DSL modem and the server, and the server used to dial and establish internet connectivity. I decided to put the firewall in-between as I had (and still have) doubts about the firewall in the server. Now, the traffic that I expect to pass through the bridge is the PPPoE, SIP, RTP and IAX2 – and with the current setup (as described in the original post) they are all going through.

b. Even though I restricted the source and destination of these protocols in the pfsense box -- which is supposed to be acting as a transparent firewalling bridge sitting in-between the server and the DSL modem -- any traffic from the internet (non-allowed hosts) can still reach the server.

As you can see on the attached image, the rules are pretty specific. I have a list of hosts, a list of ports. Only from these hosts to allocated ports traffic is allowed. By default anything else is supposed to be blocked. But when I am trying to reach the server (NOT the firewall, the server's IP address) from an unlisted host, the packets are reaching the server. I can even see various attacks on the server in the logs from hosts which are not listed in my server list.

c. I have enabled rules only on the WAN and LAN, and there is no additional rule in the BRIDGE0 interface. The ones there are part of the interface configuration, and I put them thinking that might help since the other rules were unable to stop the traffic (i.e., the issue was there even when these rules in BRIDGE were not there).

If you require further information or tests done, please do let me know. I am trying to set up a similar setup on the test bench (but no identical hardware  :'(), so suggested tests should not be a problem.

Thanks again.

[shamims]

Dear all

I am still struggling with this. Further diagnosis:

if I run a packet capture from the shell, in WAN LAN or BRIDGE0, I can see the packets flowing by. However, when I do this from the web interface, there is absolutely nothing. There is also nothing in the firewall logs pertaining these interfaces.

On my search I came across this post from jimp
https://forum.pfsense.org/index.php?topic=64601.msg350315#msg350315

If I understand correctly, Jimp is suggesting that net.link.bridge.pfil_bridge = 1 should not be done, i.e., it should remain 0. This is contradictory to all the online how-to's I have come across. But upon reading more about bridge/pfil (man pages) I am a little confused, as it seems that there are two options that can be tweaked net.link.bridge.pfil_member and net.link.bridge.pfil_bridge, of which the former is already in active mode (default). But I could not find any reference/hint that activating both could cause the filter to be bypassed – which appears to be what is happening in my case.

Also, since this is supposed to be transparent/invisible, I have not put any IP on the LAN WAN BRIDGE0 interfaces -- that is how I am likely to need them to be -- does this have any impact? Should I have put an arbitrary non-relevant IP on any/all of the interfaces?

So, could this somehow be the cause behind none of the packets being passed to/through the firewall?

Your suggestions/responses for further possible diagnosis to remedy the situation is highly appreciated.

Thanks

[cmb]

You can't put a bridge inline where the only thing running across it is the PPPoE, which is what you're doing. Everything that server passes is within the PPPoE. The setting of pfil_onlyip determines what happens to that non-IP traffic. By default, it gets passed. Flipping that sysctl would result in it all getting blocked. You have no IP traffic on your bridge in that scenario and hence can't filter the way you're trying, there simply isn't any traffic there that would match any of your rules.

[shamims]

Thanks CMB for your response – it all makes sense now, and makes me feel such a stupid  :P -- I completely forgot to take the encapsulation into account! Well, back to the drawing board then.

How do you suppose I can go about it now? I guess I can try to do the PPPoE from the pfsense box while maintaining the transparent bridge, but not sure how that will handle the IPs. The server needs that specific public IP -- that is what is handed over to it every time it dials -- and my experience with PPPoE based connectivity is scratchy at best. No worries, will see what can be done. In the meanwhile, if anyone has any suggestion on how to go about it, please feel free to chime in.

Thanks again

[cmb]

You can't bridge to PPPoE. NAT is the most common answer there. If you only get a single IP via PPPoE, NAT is the only option. In some circumstances, you get a routed public IP subnet via PPPoE, in which case that could be assigned inside the firewall, but doesn't sound like that's the case in your scenario. NAT is probably your only option from the sounds of it.