I have just setup a tunnel from my firewall and I'm having a few issues that I could use some help with.
running the command:
ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::72.52.104.74
ifconfig sit1 up
ifconfig sit1 inet6 add xxxx::2/64
route -A inet6 add ::/0 dev sit1
Allows me to ping xxxx::1 just fine. When I do a ping6 ipv6.google.com I get destination unreachable. Same thing when I try to ping the name server 2001:470:20::2. Did I miss something or is there something more that I need to run other than these commands?
It seems that I can't get to the other side of the tunnel.
The firewall itself is a little more complicated. Under CentOS I have multiple interfaces that are bridged (eth0 and eth1) and another interface for the private lan eth2. I now have sit0 as the tunnel and sit1 as the ipv6 address.
With that said, if I want to add a machine on the bridge network to have access to the IPV6 through the tunnel, how do I assign the addresses? Do I need to break the /64 down further for my two seperate network segments?
If anyone could toss me a config sample on this type of scenario I would greatly appreciate it. I've been reading the http://tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO guide and it has some useful information but nothing that touches this specific scenario.
Thanks.
Couple things...First, I would get your tunnel working before you worry about everything else.
Second, are you sure you're passing protocol 41 to whatever device is hosting your tunnel?
Are you behind a NAT? If you are, did you use that NAT address to make your tunnel connection?
EDIT:
I would not split up that /64. If you need more networks, request a /48
#2,
That's my first and third rule. First time I addeded it as -p IPV6, second time as -p 41.
-A INPUT -p ipv6 -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -p ipv6 -j ACCEPT
This machine is not behind a NAT. It is a bridged firewall with a set of static IP's. When I run route -A -inet6 (filtering out lo) I get:
/sbin/route -A inet6 -n | grep -v " lo "
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::/96 :: U 256 0 0 sit0
xxxx::/64 :: U 256 3 0 sit1
fe80::/64 :: U 256 0 0 eth2
fe80::/64 :: U 256 0 0 br0
fe80::/64 :: U 256 0 0 eth1
fe80::/64 :: U 256 0 0 sit1
::/0 :: U 1 0 0 br0
::/0 :: U 1 0 0 sit1
::/0 :: U 256 0 0 eth0
::/0 :: U 256 0 0 eth1
ff02::1:2/128 ff02::1:2 UC 0 10 0 br0
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 eth2
ff00::/8 :: U 256 0 0 br0
ff00::/8 :: U 256 0 0 sit1
So, removing the ::/0 from all interfaces other than sit1, I can now ping ipv6.google.com. So the next question would be how do I get something on my bridge to be able to talk to the IPV6? Do I add one of the IPV6 addresses from the pool to the bridge or do I need to do something different (like assign the /64 to the bridge and not sit1)?
As a follow up, I requested the /48 network. I have also discovered that VMWare doesn't seem to be passing IP's across from one physical server to another. That'a a different problem though. All of the servers for this test are on the same physical VMWare server.
So, now that I have a /48 and a /64, what do I need to do in order to route DMZ and private LAN via IPV6 and where given:
firewall:
sit0 -> tunnel broker
sit1 -> ipv6 gw
br0 -> eth0 + eth1 (dmz)
eth2 -> private lan
ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::72.52.104.74
ifconfig sit1 up
ifconfig sit1 inet6 add (xxxx::/48 or yyyy::/64 here???, or what part of what?) <-- NOT SURE
route -A inet6 add ::/0 dev sit1
ifconfig br0 inet6 add xxxx:1::0001/64
ifconfig eth2 inet6 add xxxx:2::0001/64
client (dmz):
ifconfig eth0 inet6 add xxxx:1::0002/64
route -A inet6 add ::/0 gw xxxx:1::1
client (private lan):
ifconfig eth0 inet6 add xxxx:2::0002/64
route -A inet6 add ::/0 gw xxxx:2::1
Also, is there any special type of routing I need to do to make this work from the DMZ/LAN? In the background I will work on the VMWare issue to just get server to server connectivity first.
Real quick bEcause I'm on my iPod
First, always add addresses in /64 form
Second, I guess I'm not sure why your gateway interface is different than your tunnel interface... On every setup I've done or seen, the tunnel int is the gw int
Thanks for the follow up. I did verify that the firewall IP is the client ID assigned from HE and not the /64 network. I assigned the /64 network to the DMZ range and I can traceroute -s from the DMZ IP. I have assigned one of the /64's to a machine inside the DMZ and I can ping the /64 assigned range, the /64 client router IP but that's where it stops. I've forwarded my config over to the HE team for follow up.
The sit0/sit1 is the exact config generated from tunnelbroker script generator. I'm willing to try it any way that works.
I guess I'm going to need some more information
Which /64's did you assign to which interfaces? No need to block out the addresses
Here is some detailed information. On the firewall eth0 + eth1 = br0, eth2 is the private land and eth3 is a data lan. I have yet to put any IPV6's on those lans, but they too will have a /64 of the /48 when the time comes. I have also enabled forwarding in /proc/sys/net/ipv6/conf/all/forwarding. In iptables, the first two rules for both forward and input are to allow -p IPV6 and -p IPV6-ICMP.
Server IPv6 address: 2001:470:1f04:159d::1/64
Client IPv6 address: 2001:470:1f04:159d::2/64
Routed /48: 2001:470:852c::/48
Routed /64: 2001:470:1f05:159d::/64
Firewall:
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet6 2001:470:852c:1::1/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:470:1f05:159d::1/64 scope global
valid_lft forever preferred_lft forever
7: sit1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue
link/sit 0.0.0.0 peer 72.52.104.74
inet6 2001:470:1f04:159d::2/64 scope global
valid_lft forever preferred_lft forever
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::/96 :: U 256 0 0 sit0
2001:470:1f04:159d::/64 :: U 256 2 0 sit1
2001:470:1f05:159d::/64 :: U 256 0 0 br0
2001:470:852c:1::/64 :: U 256 0 0 br0
fe80::/64 :: U 256 0 0 eth2
fe80::/64 :: U 256 0 0 br0
fe80::/64 :: U 256 0 0 sit1
::/0 :: U 1 0 0 sit1
ff02::1:2/128 ff02::1:2 UC 0 13 0 br0
ff00::/8 :: U 256 0 0 eth2
ff00::/8 :: U 256 0 0 br0
ff00::/8 :: U 256 0 0 sit1
A DMZ Server:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
inet6 2001:470:1f05:159d::3/64 scope global
valid_lft forever preferred_lft forever
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
2001:470:1f05:159d::/64 :: U 256 1 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 2001:470:1f05:159d::1 UG 1 22 0 eth0
::1/128 :: U 0 90828 1 lo
2001:470:1f05:159d::3/128 :: U 0 4 1 lo
fe80::250:56ff:feb1:9cb/128 :: U 0 162 1 lo
ff00::/8 :: U 256 0 0 eth0
[root@ipv6dev1 ~]# ping6 2001:470:1f04:159d::1 -c 1 -w 3
PING 2001:470:1f04:159d::1(2001:470:1f04:159d::1) 56 data bytes
--- 2001:470:1f04:159d::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2068ms
[root@ipv6dev1 ~]# ping6 2001:470:1f04:159d::2 -c 1 -w 3
PING 2001:470:1f04:159d::2(2001:470:1f04:159d::2) 56 data bytes
64 bytes from 2001:470:1f04:159d::2: icmp_seq=0 ttl=64 time=0.191 ms
--- 2001:470:1f04:159d::2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.191/0.191/0.191/0.000 ms, pipe 2
[root@ipv6dev1 ~]# traceroute -n 2001:470:1f04:159d::1
traceroute to 2001:470:1f04:159d::1 (2001:470:1f04:159d::1), 30 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
I'm able to ping 2001:470:1f04:159d::2 which means your tunnel is up.
I can also ping 2001:470:1f05:159d::1 which is a host behind your firewall, right?
Sounds like a IP tables issue to me
Quote from: cholzhauer on December 01, 2010, 09:03:03 AM
I'm able to ping 2001:470:1f04:159d::2 which means your tunnel is up.
I can also ping 2001:470:1f05:159d::1 which is a host behind your firewall, right?
Sounds like a IP tables issue to me
Thats my feeling as well, but the catch rules are catching any drops, unless there is something else that I'm missing. I'll have to dig a little deeper.
Why not temporarily remove the firewall rules and see if everything works the way it should