General Questions

Is there any problem with filtered bridging on 1.33?

I have a Soekris net 5501 running 1.32 generic pc and everything is working fine.

I started experimenting with multiple filtered bridges, and set up the 1.33 vmware appliance from the M0n0wall download page for testing. I cannot get the filtered bridge to work on that image. I set up the bridge just like on my soekris (I even tested it by importing the configuration, same problem.) I allowed icmp both in and out, and pings would fail, no route to host. I changed to a routing configuration, left the same rules, and pings went through fine.

I saw that there is a note on the Interfaces->Opt1 page that says you need to go to System-> Advanced and enable filtered bridging. If you go to that link it says you no longer have to enable filtered bridging, if you have a bridge it filters. If so the note on Interfaces -> Opt1 should be changed.

Has anyone set up filtered bridging in 1.33? Has anyone setup filtered bridging in the vmware appliance? Does anyone know what I am doing wrong?

I searched the message board and there seem to be a few posts that could be this same issue, but have not been responded to. Google did not find anything useful.

I have what I need running on 1.32 on the Soekris, so this is not urgent. However, I need to successfully test this before I update. Also, I would eventually like to switch the firewall onto a virtual machine, as it is really convenient, flexible and slightly more stable.

Finally, why is there no entry for 1.33 in the change log?

Thanks for all of your help!

http://m0n0.ch/wall/downloads.php

Changes in this release:

    a new image type "generic-pc-serial" has been added; the only difference to generic-pc is that it always uses the serial console (on COM1 at whatever speed the BIOS set it to)
    added Realtek customized network chip driver to support additional chipsets
    updated ipfilter to 4.1.33
    inbound NAT rules can now be added on the LAN interface with the WAN address as a target; this helps with accessing servers on an optional interface from the LAN interface by using m0n0wall's WAN IP address
    IPv6 improvements by Andrew White:
        support for LAN IPv6 prefix assignment using DHCP-PD
        added MTU option for RA
        added AICCU to interface status page
        added IPv6 support for syslog destination
        added IPv6 support for Diagnostics: Firewall States
        added error handling to interface status page for AICCU being down
        fixed DHCPv6 server setup when target interface is configured in 6to4 mode (reported by Brian Lloyd)
    modified "disable port mapping" option so that it will actually avoid port mapping whenever possible, but fall back to port mapping if another mapping for the same port already exists (inspired by a patch submitted by Adam Swift)
    added support for user-customizable captive portal logout and status page, as well as a password change option for local CP users (contributed by Stephane Billiart)
    added 'Bind to LAN' option for syslog, so you can syslog over a VPN tunnel
    fixed dnswatch to deal with changed resolv.conf (for IPsec tunnels to dynamic endpoints)
    fixed various XSS vulnerabilities in webGUI
    added option on advanced setup page to defend against DNS rebinding attacks
    fixed extra slash in captive portal redirect
    added support for (manually updated) CRLs for IPsec VPN (contributed by Sebastian Lemke)
    prevent /ext directory from being listed through webGUI (reported by Bernd Strehhuber)
    fixed typo in system_do_extensions() that broke extensions support (reported by Bernd Strehhuber)
    added check for DHCP reservation entries for the same MAC address
    changed EDNS to 4096 from default of 1280 for dnsmasq, should help with DNSSEC
    don't let missing DNS server information keep DHCPD from starting

Roy...

some virtualisations, like vmware, require that you enable additional options for the NIC to do promiscuous mode, which is probably required for bridging.  Can you check this is enabled ?

for example  http://communities.vmware.com/message/371562