News: This forum is now permanently frozen.
Pages: [1]
Topic: Totally baffled by IPv6 firewall issue (FIXED)  (Read 3906 times)
« on: May 23, 2013, 17:14:30 »
holviala *
Posts: 2

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

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.
« Last Edit: May 29, 2013, 18:37:31 by holviala »
« Reply #1 on: May 23, 2013, 17:21:32 »
holviala *
Posts: 2

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....
« Reply #2 on: May 28, 2013, 18:38:30 »
Lee Sharp *****
Posts: 517

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
« Reply #3 on: May 31, 2013, 01:22:37 »
brushedmoss ****
Posts: 446

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 ?
Pages: [1]
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines