openSUSE 11.1 ifcfg issues

[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

Code Select Expand

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

Code Select Expand

::/0 2001:470:1f0e:10f::1

results of 'ping6 -c 5 www.kame.net'

Code Select Expand

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]

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]

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/

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]

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]

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]

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]

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]

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:

Code Select Expand

{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.