News: This forum is now permanently frozen.
Pages: [1]
Topic: Transparent Bridge issue only present in 1.3 betas  (Read 3576 times)
« on: April 29, 2009, 14:09:18 »
roosterdude *
Posts: 14

Hi All,

We run quite a large number of m0n0walls (>100) in transparent bridge mode with the following config...

LAN - 10.10.100.x/16 - Used to admin the m0n0walls only
WAN - Usually no IP
OPT1 - Bridged with WAN

Enable filtering bridge = Checked.

On 1.2.x This setup works perfectly.  But on 1.3.x betas (we've tried all betas on both WRAP and ALIX hardware), we get strange issues when trying to traceroute out such as:

Tracing route to []
over a maximum of 30 hops:

  1     1 ms     *        * []
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *       34 ms     *
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10    62 ms    58 ms    58 ms []

It's almost always the same... hop one will almost always be..
  1     1 ms     *        *
unless you cancel the trace and try again immediately in which case it is:
  1     *     *        *

And there is almost always one hop that gets a partial response in the middle and the last hop always shows up as normal.  Am i right in (my uneducated about how the packet filter in m0n0wall really works) thinking that potentially the packet filter isn't associating the packets coming back as associated with those that are going out.   Note.. this issue still occurs even if there is a Allow all on both the WAN and OPT1 interfaces.  Only turning off filtering bridge makes the FW work ok.

We've only tried tracing out from Windows machines and not been in a position to trace from any other OS's yet so can be sure this is ICMP traffic. 

Ping however to any of the hops works just fine. 

I can't try a trace from the m0n0wall itself as these mostly don't have IP's given that they are transparent filtering bridges, although i'll try it from one that does have an IP (for VPNs) and post the results.

I've set this up in the lab and can confirm that as soon as "Enable Filtering Bridge" is unchecked there are instantly no issues with traceroutes out.

Traceroutes in (eg through Internet --> WAN --> pf -- > OPT1 --> Server) are no problem at all, it's just the other direction out to the internet that the issues occur.

Next step will be to put a packet sniffer in at various locations but I'm wondering if anyone has come across this before?  like I say it is the same result with all the betas that I've tried so far.

Happy to post configs up and will do that as soon as I've obsfuscated the pwds etc.

Many Thanks in advance :-)
« Last Edit: April 29, 2009, 14:13:18 by roosterdude »
« Reply #1 on: September 03, 2009, 12:23:33 »
roosterdude *
Posts: 14

Just to let everyone know.... this issue was fixed brilliantly by Chris Buechler (and Manuel) and is available in the latest betas :-)

Awesome work guys - thankyou.

I can wholeheartedly recommend Chris's company for paid m0n0wall and pfSense support :-)
Pages: [1]
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines