• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Everything blocks after a setup. FreeBSD issue.

Started by nemods, May 08, 2008, 10:04:14 AM

Previous topic - Next topic

nemods

Hello dears.
I've been registered on the site for a while, and unluckily never sorted my problem within my FreeBSD server.
Will explain myself, as fair as i can: i do have this computer in my local network, running FreeBSD, and attempted to setup a ipv6 connection.
Among all the ipv6 projects, i successfully connected to freenet6, achieving to ping myself on my own pc, and having outsides ipv6 connections aswell. Well, i would be glad to setup a tunnel with he.net as well.

Now, the problem gets whenever i try to setup the tunnel itself: i attempt to go through all the instructions provided in the examples on the site, ifconfig and such, but here comes the deal. Once the tunnel is created, and the computer ipothetically try to attempt an external connection, everything freeze. I mean: both pc, one equipped with XP and the other with FreeBSD, gets a full connection block, and i can't reach the internet unless i put down and destroy the ipv6 tunnel between the FreeBSD server and He.net.

I fear it might be me setupping some wrong config, but i just followed main site instructions.
FreeBSD's version is 4.11.

Internet -> Router -> Net Switch --> FreeBSD's PC
                                             --> XP
                                             --> Fon, Laptop and moar.

Now, shall it be the external ipv4 has to be set as the one of the local network? Just a random idea i'm thinking about. I've no clue.
The problem appears even within the other ipv6 connection disabled.

I hope someone already did the trick, connecting to he.net and other ipv6 services aswell. Thanks in advance!

Regards.
PS: Sorry for non-native english. :)

broquea

Behind your router, do you use private IP space? (10.0.0.0/8 192.168.0.0/16)

If you do, then when you use our example configuration commands make sure that you specify the IP of the FreeBSD machine, and not your external IPv4 endpoint.

nemods

#2
Thanks for the reply. Yeah, i'm behind a private ip space.
So, i did modify my settings, specifically:

iconfig gif0 create
ifconfig gif0 tunnel 192.168.1.100 216.66.80.30
ifconfig gif0 inet6 myipv6sidepoint serversidepointipv6 prefixlen 128
route -n add -inet6 default serversidepointipv6
ifconfig gif0 up

Now, as a matter of fact after some tests, connection doesn't drop. Altho, i can't ping neither home or server side ipv6 point.
I also noticed the error trying to add the new -n add server side ipv6, saying it already exists. Probably, cause another ipv6 tunnel is up?
So, i tried:
route -n add -inet6 mysideipv6point serversidepointipv6

But nothing aswell. Am i doing something wrong?
Sorry for newbieness.

broquea

Try taking down any and all IPv6 tunnels, and just try to bring up ours, and also flush your ipv6 route table.

Also make sure that your router/firewall that provides the private network addressing, passes Protocol 41 to hosts behind it.

nemods

#4
Eureka!
Thanks broquea, it seems it started to work. I didn't put down the other one, and this shall be the good thing. Altho, i performed these commands:
ifconfig gif0 create
ifconfig gif0 tunnel 192.168.1.100 216.66.80.30
ifconfig gif0 inet6 64client 64server prefixlen 128
ifconfig gif0 up
ifconfig gif0 inet6 add 48routed::1
ifconfig gif0 inet6 add 64routed_b::1


Now, it seems i can ping myself, even on /64 or /48. I added a rDNS on the first ::1 /48, and works aswell.
Although, it is not connecting to outside. I can ping my 48 from the connectivity page, but not using outside connections. I tried to connect to a irc ipv6 server: once it worked, then no more. It goes ping timeout. In fact, i think it might still be a routing add issue.
Would be fine to add a
Quoteroute -n add -inet6 routed64::1 routed64::2
for the /64?

Or still the default?
Quotenemo@nemo.nemo.it:~ route -n add -inet6 default routed64::1
route: writing to routing socket: File exists
add net default: gateway routed64::1: File exists

Attempting to netstat:

Quotetcp6       0     54  routed64onlocal.4887  irc.efnet.ch.ircd      ESTABLISHED

It connects, but then hang, going in ping timeout. I fear it might be something blocking protocol 41. Would it be necessary to allow something in FreeBSD firewall or my router? Cause, i've no access over router, apart usual virtual server ports allows and such. Some TCP / UDP port to open? The other tunnel on go6 works, it is a proof protocol 41 is allowed?

Thanks still!

EDIT: Can't ping the Server ipv6 address. Is it normal?
I guess it is the main fault.

nemods

Pardon for double post. Well, i can't even ping myself now.
Apart the success of some hours ago to connect, even with a ping timeout just after a while, i can't ping local ipv6 setupped in the gif from outside.

I fear it's all about the route, the part within
route -n add -inet6 default ipv6server

and so on. Since i can't add default as per it's already busy, which might be the solution?

Many thanks.

karlbrose



route -n add -inet6 default ipv6server

This route is the correct one, where ipv6server is the HE-side tunnel IPv6 address, flush all others.
Your prior setup command appear to be correct too.
Make sure you have IPv6 forwarding enabled in the kernel if you want to route to your Ethernet. And then you need to run an RA daemon, radvd.

Or if you want to use the rc.conf method (this is from FreeBSD 7.0 though, not 4.1)

ipv6_enable="YES"
ipv6_network_interfaces="auto"
gif_interfaces="gif0"
gifconfig_gif0="<LOCAL-INTERFACE-IP4> <HE-SERVER-IP4>"
ipv6_defaultrouter="-interface gif0"
ipv6_ifconfig_gif0="<TUNNEL-CLIENT-IP6>/64"
ipv6_gateway_enable="YES"

# additional addresses on tunnel end if needed
ipv6_ifconfig_gif0_alias0="<some-routed-IP6>"
ipv6_ifconfig_gif0_alias1="<another-routed-IP6>"

# adresses on ethernet interface
ipv6_ifconfig_eth0_alias0="<another-routed-IP6>"
ipv6_ifconfig_eth0_alias1="<another-routed-IP6>"

All this works easily and perfectly in the latest FreeBSD versions.

nemods

#7
Quote from: karlbrose on May 09, 2008, 06:00:38 PM


route -n add -inet6 default ipv6server

This route is the correct one, where ipv6server is the HE-side tunnel IPv6 address, flush all others.
Your prior setup command appear to be correct too.
Make sure you have IPv6 forwarding enabled in the kernel if you want to route to your Ethernet. And then you need to run an RA daemon, radvd.

Or if you want to use the rc.conf method (this is from FreeBSD 7.0 though, not 4.1)

ipv6_enable="YES"
ipv6_network_interfaces="auto"
gif_interfaces="gif0"
gifconfig_gif0="<LOCAL-INTERFACE-IP4> <HE-SERVER-IP4>"
ipv6_defaultrouter="-interface gif0"
ipv6_ifconfig_gif0="<TUNNEL-CLIENT-IP6>/64"
ipv6_gateway_enable="YES"

# additional addresses on tunnel end if needed
ipv6_ifconfig_gif0_alias0="<some-routed-IP6>"
ipv6_ifconfig_gif0_alias1="<another-routed-IP6>"

# adresses on ethernet interface
ipv6_ifconfig_eth0_alias0="<another-routed-IP6>"
ipv6_ifconfig_eth0_alias1="<another-routed-IP6>"

All this works easily and perfectly in the latest FreeBSD versions.

Well, thanks for the reply.
But, as i said, i can't route the ipv6 server of the tunnel within HE to default, due to the other tunnel which is _already_ routing to default.
Adding that command, will show the previous message, as i stated above. So, i just wonder which is the other way to route to the ipv6 he server, and routing it to which address.
I guess it's just a matter of that route, and would be helpful to whoever want to setup more than one tunnel.

About rc.conf settings, i fear would not fit the 4.11, would them?

Thanks.


broquea

I think the issue here is you are trying to operate 2 tunnels to the same IPv6 internet at the same time. Since you already have a default route specified for another service, I can't think of a way to have a sort of "alternative" or "backup" default route through ours.

karlbrose

Sorry, my misunderstanding. I thought you had now taken down the first tunnel and it still didn't work completely. Isn't that what you indicated?
As a general rule, during any testing, I would only test one component at a time. Take down the first tunnel completely and install the second and test/reconfigure it until every aspect works repeatedly and reliably. Then when you understand the parameters involved you can add the first tunnel back into the experiment.

Which interface is your first tunnel using?
In your setup commands for the HE tunnel you are using interface gif0, but if you have a tunnel already, it may already be using the gif0 device, so you can't create a second tunnel on it.
Try creating another interface, gif1, and use that for the second tunnel.

A second default route on the box should not be a problem.

nemods

Quote from: karlbrose on May 10, 2008, 09:09:09 AM
Sorry, my misunderstanding. I thought you had now taken down the first tunnel and it still didn't work completely. Isn't that what you indicated?

As a general rule, during any testing, I would only test one component at a time. Take down the first tunnel completely and install the second and test/reconfigure it until every aspect works repeatedly and reliably. Then when you understand the parameters involved you can add the first tunnel back into the experiment.
Actually, i'd prefer to keep up the first tunnel, while working on the second one. Mainly cause some kind of services are running by ipv6 there, and it would be great to find a way to setup the second one, letting it route properly, while the first is up and running.

Quote from: karlbrose on May 10, 2008, 09:09:09 AM
Which interface is your first tunnel using?
In your setup commands for the HE tunnel you are using interface gif0, but if you have a tunnel already, it may already be using the gif0 device, so you can't create a second tunnel on it.
Try creating another interface, gif1, and use that for the second tunnel.

A second default route on the box should not be a problem.
First tunnel is actually using tun1, and i do create gif0 for he.net tunnel, as examples states.
netstat -rn also shows every kind of routing in act, and i've been trying tricks there aswell.
As a matter of fact, the only routing which is missing is the one to default.
I wonder which should be the way to "exit" from ipv6 within he.net tunnel, while the other one is running.
Weird thing is i could exit from the /48, once, at the begin: altho, with an abnormous lag, and a timeout few minutes later. So, the routing shall be working, the thing to understand is where to point the server local side of the tunnel from he.

Quote from: broquea on May 10, 2008, 04:11:37 AM
I think the issue here is you are trying to operate 2 tunnels to the same IPv6 internet at the same time. Since you already have a default route specified for another service, I can't think of a way to have a sort of "alternative" or "backup" default route through ours.
Yeah, but another guy, amph, stated he ran he.net and sixxs.net withouth glitches, while running even a third one from his pc to another local one or something. His post is in a sticky thread in this section.

I guess an answer from him would be glad to have, since the only "seems-to-be" issue is the routing, not assignable to default. :D

Still thanks!

karlbrose


To revisit the routing issue:

>>> I can't think of a way to have a sort of "alternative" or "backup" default route through ours.

>>> I guess an answer from him would be glad to have, since the only "seems-to-be" issue is the routing, not assignable to default. :D


Indeed, even though you can assign several default routers, they won't function as a real automatic backup, if that's what you're looking for.
For that you need to run a dynamic routing protocol, RIP for IPv6 or better OSPF, and remove the static routes.

testmonster


actually, in order to multihome between two providers that operate their own networks you need to use BGP.

OSPF or RIP would only really work well for redundant connections to the same network.

nemods

Quote from: testmonster on May 12, 2008, 05:16:30 PM

actually, in order to multihome between two providers that operate their own networks you need to use BGP.

OSPF or RIP would only really work well for redundant connections to the same network.
That's interesting, i've never heard about it.
Due to that, you've got any hints or walkthro for it?

Thanks.

testmonster