IPv6

(this has to be a bug since I never make mistakes   )

Here's my overly complicated but oh so fun setup:

[ws1] <-> [intertubes] <-> [m0n0#1] <-> [linux] <-> [m0n0#2] <-> [ws2]

[ws1] = just another IPv6-connected workstation
[tubes] = native v6 internet
[m0n0#1] = routes & firewalls IPv6 traffic between intertubes and my linux servers
[linux] = normal linux server (actually, dozens of servers in a farm)
[mono#2] = second m0n0wall in another location
[ws2] = normal workstation behind [m0n0#2]

OK, so [ws1]<->[tubes]<->[m0n0#1]<->[linux] works nicely and is in production doing IPv6 for a Finnish TOP-10 site.

Since I had a full /48 to play with I decided to build my own tunnel broker - that [linux] machine in the above diagram. So, I routed a couple of /64's from [m0n0#1] to [linux] and opened up the firewall. After that I set up an IPv6 tunnel in [m0n0#2] pointing to [linux] and once again opened up the firewall.

For testing, I ping6'ed [ws1] -> [m0n0#2] and it worked. Pinged [ws1] -> [ws2] and that worked nicely too. Woo! Only then I noticed that nothing that originates from [ws2] or [m0n0#2] works. Like, pinging [ws2] -> [ws1] just didn't do anything. Since pinging from outside to inside worked, routing had to be right - so it had to be a firewall problem.

Well, I checked and double-checked and triple-checked everything, and my firewall configs were all ok. But I finally noticed that [m0n0#1] is blocking every packet coming from the OPT1 input (where [linux] is) that is not from the OPT1 subnet. So, for testing I opened up all <-> all for all interfaces on [m0n0#1] and it STILL blocks my pings originating from either [mono#2] or [ws2]. That was fun as [m0n0#1] is actually in very heavy production :-D.

So, the bug: the network in which OPT1 operates can be firewalled, or opened, but routed networks behind OPT1 are always blocked no matter what I put into OPT1 IPv6 firewall (even all <-> all open blocks). I'm pretty sure I had a similar setup working in my previous job, but I can't access those configs anymore....

Any ideas? I actually have two sets of [m0n0#2] and [ws2] and both act the same way - it's always [m0n0#1] blocking the outgoing traffic (incoming works).

EDIT: I fixed it by replacing [m0n0#1] with a linux router/firewall. Firewalling IPv6 majorly sucks on Linux, but at least it works. I think my original problem was 1.33 m0n0 firmware on [m0n0#2] since everything finally started working with 1.34 - so it all might have worked with the extra m0n0 there as well. Oh well, it works now.

On an (un)related note, does the new m0n0 18 beta work? I mean well enough to put into production? It supposedly has working IPv6 for IPsec so I could route my /64's through that instead of the extra tunnel broker linux machine....

I have been running a 1.8 beta in production for a few months now.  I needed the nic support...  However, I am not using IPv6

m0n0wall blocks packets received on an internal interface (LAN) that are not sourced from the subnet defined for that interface.  these are part of the built in rule sets , and take action before any rules you configure.

When you add a route to a subnet remote to m0n0wall, it adds a permit rule for that subnet to be a source of traffic.

can you check /status.php , where you can see the full rule set, and check it has the permits for the remote subnet before the denies ?