US Cable Support > Comcast HSI > [IPv6] Seeing two different LAN side ranges

reply to JoelC707

Re: [IPv6] Seeing two different LAN side ranges

reply to whfsdude
It scrolls past at a pretty good rate so I'm not sure if I could catch anything in a screen shot. I think what I'll do then is reboot pfSense as soon as I can and see if that solves it now that we have everything else squared away.

reply to whfsdude
Interesting info. I never knew Netflix used Amazon's services for their infrastructure. Makes sense the actual streaming would still come from Netflix since Amazon has a competing product but there's nothing stopping Netflix or another provider from leveraging Amazon's massive server infrastructure.

reply to whfsdude
Rebooted pfSense. No change

Here's something. What snapshot are you or anyone else running? I'm on the latest (Dec 19th) snap, but you or someone mentioned in another thread I read that a regression is always possible. Maybe I need to downgrade. It'll mean recreating a bunch of firewall rules but I could just blow away and recreate it from scratch (might have to do that anyway if I downgrade as I don't know what importing config settings would do).

I'm really at a loss here. I don't know if it's pfSense or my network. I've used IPv6 before via a HE tunnel so nothing funky in the switches or anything should be messing with it. They are web managed switches (one D-Link, one Dell) but I haven't seen anything IPv6 related in them.

reply to JoelC707
2.1-BETA1 (amd64)
built on Wed Dec 19 15:46:29 EST 2012
FreeBSD 8.3-RELEASE-p5

But I'm not running PD anymore as I've got all static ranges

The only other suggestion I can think of is when you allowed any traffic on the "Comcast" firewall rule, was it also set to IPv4+IPv6?

reply to JoelC707
There are more recent snapshots here:

»snapshots.pfsense.org/FreeBSD_RE···?C=M;O=D

reply to whfsdude
I started with that image you're using, another got released a few hours later (mine has 19:19:47 as the time stamp) and I upgraded to it. For that matter, would an upgrade have broken this?

The Comcast "any any" rule was IPv6 only. I have re-enabled it and it made no difference.

reply to graysonf
Aha it was set to check against the release server not the snapshots server. I just assumed they took a break from updates for Christmas or something. Before I contemplate blowing this away and starting fresh, I'm gonna try an update and see what I can make it do with a newer snapshot (at least with an update I don't have to recreate a bunch of rules and such lol).

You can save your current configuration file at any time and restore it later into your next install. No need to recreate anything from scratch.

Yeah but I'm worried there might be something hidden that is messing this up and restoring the config would restore the fault too. I guess I don't really see what that might be since everything else says it should be working but I'm stumped at this point.

Maybe you should consider a simpler product just to see if it will configure IPv6 correctly for you. If it won't, then the problem lies on Comcast's side and you are spinning your wheels.

I run m0n0wall here, the product that was forked to form pfsense.

It might take you ten minutes to try it. I can paste screenshots of the configuration for you if you want them.

Tell me more about what type of pfsense install you are running and I'll point you to the right m0n0wall image.

Good point. This could all be some bug in pfSense that has come up. The IPv6 forum at pfSense.com is filled with Comcast IPv6 questions I haven't even connected it direct to my desktop to test it direct (though considering I can ping from the firewall I suspect it will work connected direct to my desktop).

I've considered Untangle as well and have seen m0n0wall though I've never used either. I have two WAN circuits, one being PPPoE DSL, the other Comcast. It's being used for just a basic internet router/firewall. I have used HAVP (inline virus scanner) and played around with snort but do not use either currently. Nothing special really

m0n0wall doesn't handle multi-WAN. But it still would be worth trying on your Comcast circuit.

I suggest the Live-CD with a floppy or USB stick to store the configuration. Nothing to install, just try it and see what happens.

reply to JoelC707

reply to graysonf
It's certainly worth a try, just with the Comcast circuit but yeah if no support for multi-wan then that's a no-go for me as a permanent solution. That may be why I went with pfSense instead of m0n0 at first because I've been using pfSense since the 1.2.1 days lol.

reply to plencnerb
I confirmed with NetDog that my CMTS was IPv6 enabled before beginning this adventure but alas what should work what that actually happens are sometimes two entirely different things LOL. Regardless, I should try that and see what happens.

Though I did note in the thread you pointed me to, your IPv6 IP shown was a 2001: address. If the PD provided 2601: address is the source of the issue, I may very well be able to connect the modem direct to my computer and get IPv6 connectivity and then turn around and still not get it to work with pfSense.

reply to JoelC707
If it were an issue of the PD not being routed properly, we wouldn't be able to ping it (we can ping both WAN and PD addresses).

I'm 99% certain the issue lies with pfsense.

Might also want to grab the active rules pfsense is using.

via CLI
cat /tmp/rules.debug

Edit:
Also post an traceroute6 from both the router and the client computer.

You can use one of my boxes as the target.
v6.znc.0x1a4.com

Can you re-run the IPv6 test page and bring up technical info?

The large packet indicates path mtu problems still.