IPv6

I must be missing something very, very basic here.

I am running 1.8.1 with two NICs (re0 LAN, re1 WAN).  The WAN link receives its IPv4 address via PPPoE, NATs IPv4 traffic from LAN to WAN without issue, port forwards from WAN interface to random servers on the LAN, etc.  It's your basic textbook working configuration, and has been operational for awhile across multiple m0n0wall versions.

Enter IPv6.  I've been trying to spin up a HE tunnelbroker tunnel, to no avail.

The tunnelbroker side of things works fine.  The link goes up, the WAN IPv6 address (denoted here as "A:B:C:D::2") is pingable from the outside.

So is the /64 routed to me via tunnelbroker ... almost.  I have followed multiple mostly congruent HOWTOs for tunnelbroker/m0n0 configuration, so I have configured the LAN IPv6 interface as A:B:C:D+1::1 (i.e., the first address on the /64 routed to me).  IPv6 ACLs are in place on both the WAN and LAN interface to permit any/any/any, and I'll lock that down when I can verify end-to-end connectivity.

I can ping6 the m0n0wall LAN IPv6 interface ("A:B:C:D+1::1") from the outside world with no issues.  I can ping6 between machines on the LAN subnet ( ::5 and ::59, for example) with no issues.

I cannot ping6 the m0n0wall LAN IPv6 interface ( ::1 ) from either ::5 or ::59, nor can it ping6 them.  I placed a gratuitous "deny/deny/deny log" at the end of the LAN IPv6 ACL list, but see no hits there.  I don't think it's a switch issue, as the machines that can ping each other are connected to the same physical switch as the m0n0wall's LAN interface.

My suspicion is that there's a hidden default ACL in there somewhere that is pre-emptively dropping IPv6 packets from LAN before it gets to my "permit any/any/any" ACL ... but status.php doesn't seem to have anything substantial added or missing from the IPv6 list over the IPv4 list.

Am I missing something really, really basic here, do I have a weird hardware issue that affects IPv6 but not IPv4, or is 1.8.1 subtly broken for IPv6?

I'm happy with m0n0wall, and I don't really want to evaluate other solutions right now.  That having been said, I don't have much hair left, and I'd like to keep what I've got ... so if this is simply not doable, I'll have to start looking at pfsense.

Thanks in advance for any guidance,

-- Chris

Can you reach IPv6 sites out on the internet from your LAN hosts?

If not, verify that your LAN hosts have an IPv6 gateway set. It should be the m0n0wall IPv6 LAN interface IP address.

No, they cannot hit anything in the outside world -- since the m0n0wall LAN IPv6 address does not respond to ping from adjacent LAN IPv6 addresses, an end-to-end test certainly isn't going to work.  m0n0wall needs to be reachable before it can route packets 

Thanks for the suggestion, though.

Do your LAN hosts have their IPv6 gateway specified or not?

They do, same IPv6 IP as assigned to m0n0wall LAN interface:

[18:59:01] dev:~$ /sbin/ip -6 route show dev eth0
A:B:C:D+1::/64  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
default via A:B:C:D+1::1  metric 1  mtu 1500 advmss 1440 hoplimit 4294967295

Your addressing looks suspect to me. You have:

m0n0wall WAN: A:B:C:D::2
m0n0wall LAN:  A:B:C:D+1::1

When I had an HE tunnel they were:


m0n0wall WAN: 2001:470:4:930::2
m0n0wall LAN:  2001:470:5:930::1

You show the +1 in the 4th digit, on mine it's in the third digit.

It's always clearer if you don't obfuscate addresses and just post them. You can delete the tunnel and get a new one if you are worried about posting addresses here.

Sorry about that.  Yes, I was obfuscating addresses for security reasons, and I did swap the third and fourth numbers while obfuscating.

The address assigned to the WAN side is:

2001:470:23:438::2

... which works from the outside world.

The address assigned to the LAN side is:

2001:470:24:438::1

... which also works from the outside world.

The LAN address, however, cannot access nor be accessed by anything on the LAN interface.  Test machines (2001:470:24:438::5, ::9, and so forth) can hit each other.  They cannot hit ::1.  ::1 cannot hit anything else.  It can't even ping itself.

Thanks, again, for your help.

1) From what I can see HE is doing its job and your tunnel is good if packets can reach both the m0n0wall LAN and WAN interfaces.

2) Your LAN machines being able to reach each other doesn't involve m0n0wall at all, that would still work with m0n0wall shut off.

3) Not being able to ping your m0n0wall LAN address from the m0n0wall console itself seems to be be counter to 1) above, at least from having an allow any rule in place perspective.

I can't say it works here, because I got away from IPv6 some time ago due to log flooding. The last saved working HE Tunnel config file I have here is dated 10/29/2012 but that was well before m0n0wall 1.8.1 was final and generic-pc-serial-1.8.0b517 is the one with a date closest to the last working config file.

I'll try to bring up my old HE tunnel here later when I have a bit more time.

I agree with your conclusions.  It's acting like a layer-one / layer-two problem, except a) IPv4 is working and b) it can't ping itself.

That's why I was thinking that there was a magic hidden misconfigured ACL in there somewhere that was blocking traffic hitting LAN from LAN.  In my experience, when it's not a physical issue, it's going to be an ACL ...

... this is where I really miss having direct CLI access to the firewall (I'm a UNIX/Cisco guy by profession).  It *has* to be something mindbogglingly obvious, but clearly I'm overlooking it.

Thanks for taking the time to add another pair of eyes to the problem, much appreciated.

I haven't been able to get to restoring my HE tunnel just yet, but I did remember something that bit me badly here back then and I do not know if it was ever fixed - enabling the Traffic Shaper breaks IPv6 connectivity. Again, I don't know it if got fixed or not. Any chance you have it enabled there?

Nope, traffic shaping isn't enabled.  Neither is PPTP, any DHCP or DNS service / forwarding, IPSEC, etc.  Just your bog-standard two-NIC NATting PPPoE firewall 

(I did turn off the "block internal networks" ACL for troubleshooting, but this configuration should otherwise be stock)

I just restored my old m0n0wall image and config file for my HE tunnel. But it will not acquire a WAN IPv6 address. Must be something my ISP did when they went to Native IPv6 because changing only that gets me good to go with IPv6. Afraid I can't help you by trying to debug HE here.

Fair enough.  Thanks for trying, much appreciated.

Fixed.  The switch was in a weird state; rebooting it fixed the issue.

[20:19:03] dev:~$ ping6 ipv6.google.com
PING ipv6.google.com(nrt19s12-in-x09.1e100.net) 56 data bytes
64 bytes from nrt19s12-in-x09.1e100.net: icmp_seq=1 ttl=58 time=135 ms
64 bytes from nrt19s12-in-x09.1e100.net: icmp_seq=2 ttl=58 time=108 ms
64 bytes from nrt19s12-in-x09.1e100.net: icmp_seq=3 ttl=58 time=126 ms

Thanks for your help, Fred -- having confirmation that HE worked on a 1.8.0 beta made me look at layer one and two much closer.

Ouch!

I was also able to get my HE tunnel up and running. What was fooling me was that I didn't bother configuring a LAN machine until I was convinced m0n0wall was all set to go. What fooled me, and this is new behavior, was that the m0n0wall WAN address was a local link address, not the one HE provided. I assumed that was wrong and gave up. Something told me to try pinging something out on the net from m0n0wall and it worked! I set up one LAN machine and that was good to go too.