1.3 Development

I have a new 3-NIC ALIX machine running m0n0wall to act as a traffic-shaper between my LAN and my ADSL router (which provides the firewall functions itself).

I have configures WAN/vr0 as 10.1.100.252/16 and LAN/vr1 (which I planned to use for management only) as 10.1.100.253/16.  OPT1/vr2 is bridged to the WAN interface and the WAN interface is connected directly to the ADSL router on 10.1.100.254/16.

I set all of this up without LAN/vr1 plugged in - and I had full internet access and could see the router's web interface, but I couldn't access the m0n0wall webUI on 10.1.100.252.

Here's where it gets strange:

I plugged a cable from the LAN top-level switch into the LAN/vr1 socket.  This gives me LAN/vr1 plugged into a gigabit unmanaged switch (no reason, there was a spare socket) which connects directly to a 10/100Mb unmanaged switch which connects to OPT1/vr2.

Now I can see the web UI of the m0n0wall on 10.1.100.252, but can't even ping 10.1.100.253 from my LAN!

Stranger, all my LAN hosts are detected as living on the LAN/vr1 port, but using the m0n0wall diagnostic tools I'm unable to ping any of them through this port.  If I try to ping any LAN hosts via the WAN/vr0 port, however, this succeeds.

This means that none of my internal services are currently available externally, because incoming packets are de-NAT'd by the ADSL router and sent to the m0n0wall, which presumably then transmits them via the LAN interface where they get lost.

During this entire testing period I was pinging 10.1.100.254, 10.1.100.253, and 10.1.100.252 - whilst .254 and .252 always worked, I noticed as I finished that .253 did respond to about 20 pings in sequence during the 30-minute or so test.  I've no idea why this didn't work all the time, or what might have caused it to suddenly respond for a short period.

My questions are:

• Is bridging intended to be used in this fashion?
• Why is the UI only accessible when LAN/vr1 is plugged in, but then only via OPT1/vr2?
• Why can't the m0n0wall see any hosts via LAN/vr1, when this is directly plugged into the same top-level switch as all other (gigabit) LAN hosts, which have no networking issues?
• Can I workaround this problem by setting a static route for 10.1/16 via WAN/vr0 (which is bridged with OPT1/vr2) without breaking anything?

These tests were performed with the Traffic Shaper enabled with the default P2P shaping configuration produced by the Wizard, and the only Firewall rules were a rule on each interface passing all traffic.

Any help greatly appreciated...

Stuart

I've also just tested pinging both 10.1.100.252 and 10.1.100.253 - and despite being ports on the same network segment I see no packet loss to 10.1.100.252, but a steady 10% packet loss to 10.1.100.253.

Additionally, as soon as I remove the cable from LAN/vr1/10.1.100.253, both IP addresses become unavailable to pings.

However, the bridge must still be working because I do not lose the ability to contact the ADSL router which is only plugged into the WAN/vr0 port.

I still can't access internal services, though, to m0n0wall is still not routing traffic correctly.

(I do have the option to block local subnet traffic disabled, so I'm running afoul of this...)

looks to me like your LAN and WAN are on the same network.

CS...

Indeed - ideally, I'd like to bridge LAN and WAN, and have OPT1 unused.  Since this isn't possible (only OPT1 shows bridging options) then I'm happy to bridge WAN and OPT1.

The router on .254 is still be default gateway for the internal network, but this traffic should be shaped to m0n0wall acting as a transparent bridge - and this does work with the limitations that either LAN/vr1 has to be plugged in or I cannot access the m0n0wall admin UI and, even worse, m0n0wall seems to attempt to route any inbound traffic via LAN/vr1, where it disappears.  I'm only using m0n0wall's traffic-shaping abilities, not its firewall.

I think that this configuration is valid and perfectly correct, albeit one possibly not anticipated by the developers.  However, the behaviour of m0n0wall in this configuration does appear to be quite broken regardless.  If anyone can explain how else I might configure things, I'm happy for suggestions!

Currently, I'm trying:

Code:

ADSL router (.254) -> (.252/WAN) m0n0wall (transparent bridge/OPT1) -> Internal network

This works, but I can't access the m0n0wall admin UI on .252.  If I configure as follows:

Code:

ADSL router (.254) -> (.252/WAN) m0n0wall (transparent bridge/OPT1) -> Internal network
                                 m0n0wall (.253/LAN)                -> Internal network

... which allows me to access the admin interface on .252, but doesn't allow access via .253 - and 10% of pings to this IP address are lost.

I've just this second now also tried unplugging OPT1, leaving only the WAN connection on .252 and the LAN on .253.  I'd expect to be able to access the m0n0wall admin UI on LAN/.253 but not access the router on .254 (since the LAN interface isn't bridged).  In fact what happens is that the admin UI is still inaccessible and the packet loss is at least as bad.

This seems pretty broken - if the WAN interface is (mis)configured to be on the same subnet as LAN, then the LAN interface drops packets and the admin UI cannot be reached... or at least on an ALIX 2c3 system.

Can anyone confirm whether this is also the case on other hardware?

... although I am seeing log entries such as:

Code:

kernel: Limiting icmp ping response from 278 to 200 packets/sec

so the packet-drops could be a red herring...

Right - I've set the LAN address to a totally different subnet, and now inbound traffic is being correctly bridged across to OPT1/vr2 rather than routed to LAN/vr1.

This still means that I need a network cable plugged into LAN/vr1 in order (presumably) to mark the interface as RUNNING for the admin UI to be accessible - and I still think that this is a fairly significant bug!

m0n0wall is a Router that had Bridging added on after the fact.  It's was not intended to be a Smart Bridge.

The Bug might be in your thinking   

CS...

Ah - I've fixed it!

(albeit probably temporarily...)

I've edited /etc/hosts on the m0n0wall from:

Code:

127.0.0.1 localhost localhost.seventytwo.miltonroad.net
192.168.0.253 m0n0wall.seventytwo.miltonroad.net m0n0wall

... to:

Code:

127.0.0.1 localhost localhost.seventytwo.miltonroad.net
10.1.100.252 m0n0wall.seventytwo.miltonroad.net m0n0wall

(e.g. replaced the unused LAN address with the WAN/OPT1 bridged address) - and everything works!  I can access the internet, external hosts can connect to internal services, and I no longer have to have the LAN port connected but on an unavailable IP address for incoming traffic or the webadmin interface to work.

Do developers read this forum?  I guess that this could be fixed internally or at least, in a worst-case scenario, be fixed with a "Primary IP address" (or similar) option in the web UI.