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

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Main Menu

openSUSE 11.1 ifcfg issues

Started by biafrarepublic, August 04, 2009, 02:29:22 PM

Previous topic - Next topic

biafrarepublic

I'm trying to get my tunnel working via ifcfg, but I seem to hit a roadblock

To the best of my knowledge, my router does forward proto41 without difficulty

/etc/sysconfig/network/ifcfg-sit0
STARTMODE='onboot'
BOOTPROTO='static'
TUNNEL='sit'
TUNNEL_LOCAL_IPADDR='192.168.1.47'
TUNNEL_REMOTE_IPADDR='216.218.224.42'
IPADDR='2001:470:1f0e:10f::2/64'
TUNNEL_TTL='255'


/etc/sysconfig/network/ifroute-sit0
::/0 2001:470:1f0e:10f::1

results of 'ping6 -c 5 www.kame.net'
PING www.kame.net(orange.kame.net) 56 data bytes
From biafrarepublic-1-pt.tunnel.tserv8.dal1.ipv6.he.net icmp_seq=1 Destination unreachable: Address unreachable
From biafrarepublic-1-pt.tunnel.tserv8.dal1.ipv6.he.net icmp_seq=2 Destination unreachable: Address unreachable
From biafrarepublic-1-pt.tunnel.tserv8.dal1.ipv6.he.net icmp_seq=3 Destination unreachable: Address unreachable
From biafrarepublic-1-pt.tunnel.tserv8.dal1.ipv6.he.net icmp_seq=4 Destination unreachable: Address unreachable
From biafrarepublic-1-pt.tunnel.tserv8.dal1.ipv6.he.net icmp_seq=5 Destination unreachable: Address unreachable

--- www.kame.net ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4014ms


Help?

jimb

#1
I think you might need to use sit1?  (this is more of a guess than anything)  I sort of remember that sit0 isn't used for the actual tunnel but must be there, etc, etc.  Is iptools not available on that distro?  I find those much easier to work with for IPv6.

Also, when you say it forwards 41, do you mean that you're behind a NAT and have set up a forward from your public to your 6in4 router?  This is something you have to be pretty sure about.  :P

jrowens

Did you try pinging anything besides www.kame.net?  I couldn't get through to them by IPv6 for a little while recently, though most other sites were still fine for me.  Probably related to the routing issues that were mentioned elsewhere, I'd suppose.

biafrarepublic

#3
Quote from: jimb on August 04, 2009, 09:07:23 PM
I think you might need to use sit1?  (this is more of a guess than anything)  I sort of remember that sit0 isn't used for the actual tunnel but must be there, etc, etc.  Is iptools not available on that distro?  I find those much easier to work with for IPv6.

Also, when you say it forwards 41, do you mean that you're behind a NAT and have set up a forward from your public to your 6in4 router?  This is something you have to be pretty sure about.  :P

iptools is there, but openSUSE bitches for an ifcfg script. In addition, yes, I am behind a NAT (as I use a Verizon DSL wireless router), when I tried the tunnel on my windows notebook, it worked. Now I want it on Linux to stay. Also changed the files to be *-sit1, no dice/

Quote from: jrowens on August 06, 2009, 03:06:15 PM
Did you try pinging anything besides www.kame.net?  I couldn't get through to them by IPv6 for a little while recently, though most other sites were still fine for me.  Probably related to the routing issues that were mentioned elsewhere, I'd suppose.

I had tried pinging -6 ipv6.google.com in addition to www.kame.net, no dice

egonalter

#4
This configuration works here (you really need sit1):
ifcfg-sit1:
STARTMODE='onboot'
BOOTPROTO='static'
TUNNEL='sit'
TUNNEL_LOCAL_IPADDR='<local-ipv4>'
TUNNEL_REMOTE_IPADDR='<remote-ipv4>'
IPADDR='<local-ipv6>/64'
TUNNEL_TTL='255'

ifroute-sit1:
::/0 <remote-ipv6>

I'm not behind a NAT/Firewall
For NAT, you need the local ip 192.168... (as you already posted)

biafrarepublic

Quote from: egonalter on September 12, 2009, 02:45:52 AM
This configuration works here (you really need sit1):
ifcfg-sit1:
STARTMODE='onboot'
BOOTPROTO='static'
TUNNEL='sit'
TUNNEL_LOCAL_IPADDR='<local-ipv4>'
TUNNEL_REMOTE_IPADDR='<remote-ipv6>'
IPADDR='<local-ipv6>/64'
TUNNEL_TTL='255'

ifroute-sit1:
::/0 <remote-ipv6>

I'm not behind a NAT/Firewall
For NAT, you need the local ip 192.168... (as you already posted)


The config above will only take an IPv4 address for TUNNEL_REMOTE_IPADDR

egonalter

Quote from: biafrarepublic on September 12, 2009, 07:21:14 AM
Quote from: egonalter on September 12, 2009, 02:45:52 AM
This configuration works here (you really need sit1):
ifcfg-sit1:
STARTMODE='onboot'
BOOTPROTO='static'
TUNNEL='sit'
TUNNEL_LOCAL_IPADDR='<local-ipv4>'
TUNNEL_REMOTE_IPADDR='<remote-ipv6>'
IPADDR='<local-ipv6>/64'
TUNNEL_TTL='255'

ifroute-sit1:
::/0 <remote-ipv6>

I'm not behind a NAT/Firewall
For NAT, you need the local ip 192.168... (as you already posted)


The config above will only take an IPv4 address for TUNNEL_REMOTE_IPADDR

you are right - corrected

biafrarepublic

Quote from: egonalter on September 13, 2009, 11:00:49 AM
Quote from: biafrarepublic on September 12, 2009, 07:21:14 AM
Quote from: egonalter on September 12, 2009, 02:45:52 AM
This configuration works here (you really need sit1):
ifcfg-sit1:
STARTMODE='onboot'
BOOTPROTO='static'
TUNNEL='sit'
TUNNEL_LOCAL_IPADDR='<local-ipv4>'
TUNNEL_REMOTE_IPADDR='<remote-ipv6>'
IPADDR='<local-ipv6>/64'
TUNNEL_TTL='255'

ifroute-sit1:
::/0 <remote-ipv6>

I'm not behind a NAT/Firewall
For NAT, you need the local ip 192.168... (as you already posted)


The config above will only take an IPv4 address for TUNNEL_REMOTE_IPADDR

you are right - corrected

Still nothing.

jimb

#8
Have you tried to bring things up by hand?  If so, and it works, you may just need to pour over the init script and network scripts which start up the device and figure out how they work and what they need.  I've often found myself doing so on poorly documented or buggy distros versions.

I also note from above that you are behind a DSL router doing NAT.  You also had windows doing 6in4 and it was working for you.  That might be the problem.  If the windows box is still doing 6in4, (sending IPv4 protocol 41 packets out to the internet), then the DSL router will have a NAT/connection table entry mapping that protocol to your windows box's IP.

Or, if the windows box isn't doing it anymore, the DSL router could have a super long timeout for the connection table entry.  Or it could have a bug or behavior where that mapping becomes permanent.  Or a bug/behavior where new traffic from a new IP doesn't reset the mapping to point to your linux box.

One way to test this is to do a tcpdump on your linux box's interface and see if you see return 6in4 traffic.  If you don't, this is likely the culprit.

You should see traffic like this:
{root@gtoojimb/pts/2}~# tcpdump -n -i eth0 proto 41
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:35:33.548960 IP 192.168.0.4 > 72.52.104.74: IP6 2001:db8:1234:0:201:2ff:fe6d:5aa4.13957 > 2001:dc0:1:0:4777::140.53: 8946% [1au][|domain]
10:35:33.712706 IP 72.52.104.74 > 192.168.0.4: IP6 2001:dc0:1:0:4777::140.53 > 2001:db8:1234:0:201:2ff:fe6d:5aa4.13957: 8946-[|domain]

^^^ my 6in4 router (192.168.0.4) talking 6in4 with HE's Fremont tunnel server (72.52.104.74).


You may need to (if possible) set up a static NAT entry on the DSL router pointing proto 41 to the IP of your SuSe box.