Routing the Tunnelbroker /48 (brain fart)
-
Hello all,
I've definitely been enjoying pfSense. I recently replaced my DD-WRT LAN router with a virtualized pfSense setup backed off onto a quad port NIC with bridged ports. Anyways. I setup a HE.net IPv6 tunnel with Tunnelbroker. Everything's working great with the /64. I requested the /48 to set it up on my OpenVPN server, which is behind the pfSense router/firewall. I added the route in static routes with the gateway specified as the OpenVPN server's v6 address within the /64. I added an IP within the /48 on the OpenVPN server and then did some testing. No connectivity :(
Am I missing something obvious? It is a tad late, so it's probably something like that.
Any help y'all can provide would be very much appreciated!
Thanks!
-
Time flies when you're having fun! I actually got the /48 working with the OpenVPN server. I was accidentally filtering with the firewall rules. Whoops!
I recently got a routed /64 from Comcast and was able to take down the HE.net tunnel. Anyways. Comcast won't give me anymore beyond that /64 with residential service. (At first, they were only giving me a /128!) I'd love to be able to do IPv6 still with the OpenVPN server. The only option I'm aware of for getting more space is going back to the tunnel. Maybe someone can correct me if I'm wrong, but I don't think I can utilize both the tunnel and the native Comcast dual stack at the same time - right?
As always, any info is appreciated :)!
Thanks!
-
I guess you can, but I am not totally sure how since I never tried it.
But if your tunnel from he.net is tunneled over ipv4, then i suppose you can.You might (still) have to create a gateway group: System - Routing - Groups and then use your tunnel interface as one of the gateways in the tier.
This is what I guess! But I might be wrong.Maybe he.net also allows you to tunnel over ipv6 you could try investigate that - in that case it might even be possible to route the network to (one of) your routers ipv6 unicast addresses - but this is pure speculation - just something to investigate :-) Meaning that he.net routes statically instead of tunneling.
Cheers
Anders -
Comcast Residential will delegate up to a /60 prefix to you if you ask for it via prefix hint. (Note that this is completely different from the prefix that's used on the WAN interface.)
-
Comcast Residential will delegate up to a /60 prefix to you if you ask for it via prefix hint. (Note that this is completely different from the prefix that's used on the WAN interface.)
So I tried that setting and I never get a /60 prefix (not even the original /64). In fact, I get this error in the system logs: dhcp6c[79828]: add_ifprefix: invalid prefix length 64 + 4 + 64
Any hints?
-
On your WAN interface:
- Use IPv4 connectivity as parent interface: off
- Request only a IPv6 prefix: off
- DHCPv6 Prefix Delegation size: 60
- Send IPv6 prefix hint: on
On your LAN interface:
- IPv6 Configuration Type: Track Interface
- IPv6 Interface: WAN
- IPv6 Prefix ID: 0
If that still doesn't work, you may be hitting the issue described in this post.
EDIT: That issue would cause exactly the kind of error you're seeing, so seems pretty likely.
-
If that still doesn't work, you may be hitting the issue described in this post.
EDIT: That issue would cause exactly the kind of error you're seeing, so seems pretty likely.
That would be the problem. It's unfortunate, because it's not really an opportune time to get my v4 address changed or discontinue v6 for a week. Might be worth a call to Comcast I guess.
So just for my own edification, I tried to run both the HE.net tunnel and the Comcast /64. I can successfully route the /48 to a Linux box on my LAN. I can ping and surf from that /48. BUT, I can't seem to ping it from the outside or surf any of its available services. It's not a firewall issue according to pflog and no v6 firewall issues on the host itself. tcpdump shows the packets making it there and me responding. I'm puzzled as to why that's not working…
EDIT: Ugh, okay. Despite the policy routing firewall rules, traffic responses from the Linux host get shunt out the WAN interface vs. the gif0 tunnel. Not sure how to influence that, since it's already configured as such…
-
@JC:
Despite the policy routing firewall rules, traffic responses from the Linux host get shunt out the WAN interface vs. the gif0 tunnel. Not sure how to influence that, since it's already configured as such…
So I've got to admit, I'm stumped on this one. I looked at the rules.debug file and the pf rules look fine to me with the route-to entries. I still can't figure out why the packets for that network are leaving on em0 (WAN) vs. gif0 (HE.net tunnel).
-
Can you show you anonymized /tmp/rules.debug?