Hurricane Electric's IPv6 Tunnel Broker Forums
February 08, 2010, 11:29:52 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Welcome to Hurricane Electric's Tunnelbroker.net forums!
 
   Home   Help Search Login Register  
Pages: [1] 2 3 ... 10
 1 
 on: February 08, 2010, 10:30:22 pm 
Started by mbettinger - Last post by jimb
First, for whatever reason, you are getting a two IPv6s on your DMZ interface (vr0).  It looks like it's being autoconfigured, so either you have another router advertising the prefix on that LAN, or the rtadvd running on the box itself is actually causing an address to be autoconfed on that interface.  Or it's left over from before (maybe you haven't rebooted).

Set a static IPv6 /64 address from your /48 (looks like you did that already).  You need to advertise a /64 out of your /48 on the vr0 interface.  Advertise the prefix 2001:470:b84a::/64 not the whole /48.

On your LAN interface (vr2 presumably), set a static IPv6 from your routed /64.  Advertise your routed /64 on the vr2 interface only ("default" might mean all interfaces, but I don't know rtadvd conf file syntax since I don't run a BSD IPv6 router at the moment).

For example, set the IPv6 "2001:470:1f0f:39f::1/64" on vr2, but advertise "2001:470:1f0f:39f::/64".  Set "2001:470:b84a::1/64" on vr0 (you may have already done this), but advertise "2001:470:b84a::/64" (this is /64 subnet-zero of your /48, if you had a 4th LAN, you could use, say 2001:470:b84a:1::/64 on it, :2:: on a 5th, etc, etc.  You have 65,536 subnets to work with on your /48).

Ensure that your router interfaces don't autoconfigure by doing whatever is needed in rtadvd.conf file.  Use statics.  I suppose there might be a way to have them autoconfig and have rtadvd still announcing on them, but that seems a bit of an "unnatural act" to me.  

 2 
 on: February 08, 2010, 07:52:38 pm 
Started by mbettinger - Last post by mbettinger
Hi,

Still having some problems with using ipv6 tunnel on two subnets.  This is what I have so far from interfaces on my firewall:

vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:c9:58:d0
        priority: 0
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::200:24ff:fec9:58d0%vr0 prefixlen 64 scopeid 0x1
        inet6 2001:470:1f0f:39f:200:24ff:fec9:58d0 prefixlen 64 detached autoconf pltime 180920 vltime 2168120
        inet 172.18.1.1 netmask 0xffffff00 broadcast 172.18.1.255
        inet6 2001:470:b84a::1 prefixlen 64
vr1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:c9:58:d1
        priority: 0
        groups: egress
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::200:24ff:fec9:58d1%vr1 prefixlen 64 scopeid 0x2
        inet 98.196.132.150 netmask 0xfffffc00 broadcast 255.255.255.255
vr2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:c9:58:d2
        priority: 0
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.22.1.1 netmask 0xffffff00 broadcast 10.22.1.255
        inet6 fe80::200:24ff:fec9:58d2%vr2 prefixlen 64 scopeid 0x3
        inet6 2001:470:1f0f:39f:200:24ff:fec9:58d2 prefixlen 64 autoconf pltime 604515 vltime 2591715


# cat /etc/rtadvd.conf
default:\
        :addr="2001:470:1f0f:39f::2":prefixlen#64:raflags#64:
vr0:\
        :addr="2001:470:b84a::1":prefixlen#48:raflags#48:



For some reason my DMZ interface looks like it is getting assigned two ip's  Anyway  the systems behind the vr2 (10.22.1.0/24) can use the tunnel just fine.  The DMZ (172.18.1.0/24) lan still cannot.  As a matter of fact they do not appear to even get assigned an ip address.

Here is an rtsol output from an box on the DMZ.

# rtsol em0
get_llflag() failed, anyway I'll try
sendmsg on em0: Can't assign requested address
sendmsg on em0: Can't assign requested address
sendmsg on em0: Can't assign requested address



I launced rtadvd from firewall  and use the internal LAN interface  which starts up but apepars to have some error however internal LAN systems get ip address and can ping out fine.  Something not quite right i more than one place   in rtadvd.conf and the ip assignment on the DMZ interface I'm sure.... just not sure WHAT. 

# rtadvd -d vr2
Could not parse configuration file for vr2 or the configuration file doesn't exist. Treat it as default
add 2001:470:1f0f:39f::/64 to prefix list on vr2
RA timer on vr2 is set to 16:0
set timer to 15:977300. waiting for inputs or timeout
RA timer on vr2 is expired
send RA on vr2, # of waitings = 0
RA received from fe80::200:24ff:fec9:58d2 on vr2


Thanks for any nudge. ugh.

 3 
 on: February 08, 2010, 11:51:02 am 
Started by somegroup - Last post by bombcar
Um.

http://www.whatismyip.com/automation/n09230945.asp ?

 4 
 on: February 08, 2010, 03:55:24 am 
Started by somegroup - Last post by somegroup
The machine running the tunnel is BEHIND the machine with the external IP.

I can not see my external IP from the internal machine at my end of the tunnel.

I want the ipv4_end.php script to TELL me the IP even if has not updated the endpoint information, so that I can setup the tunnel automatically. My external IP is dynamic, but may persist through a restart of the internal machine - so in this case I can not setup the tunnel because I don't know the IP.

whatismyip.com is a pain to parse in a script - i'd much rather just parse a text response from the ipv4_end.php script.

Can you have ipv4_end.php include the IP of the end-point in the response message even when the requested ip (ipv4b=AUTO) is the same as the one already configured ?

 5 
 on: February 07, 2010, 09:14:54 pm 
Started by cholzhauer - Last post by bombcar
I've noticed that they seem to have one lame server in the IPv6.google.com rotation, but I'm not sure.

 6 
 on: February 07, 2010, 07:54:47 pm 
Started by jimb - Last post by jimb
I think you misunderstood.  I'm not talking about simply passing proto 41 through.  I'm talking about smarter connection tracking for 6in4 traffic so that multiple 6in4 clients can operate simultaneously behind the same NAT gateway/firewall, perhaps talking to the same tunnel server.  

For instance, in a campus environment, if multiple users are behind the same many-to-one NAT and each want to get a tunnel from HE, from the same tunnel server, because they want their own separate IPv6 networks, it won't work because of ambiguity of where to direct the return traffic.

One way I thought of doing this is by creating connection able entries with a "tracking module" which peeks at the outgoing IPv6 source addresses (which are unique) and records these in the connection table along with the IPv4/NAT information.  When the return 6in4 traffic comes back, it can again peek at the IPv6 destination address in the payload and figure out which inside 6in4 router to send it to.  This is something that'd have to be implemented as a separate module similar to "nf_nat_ftp" (which allows port mode FTP through a NAT). 

This might also be extended to 6to4 situations behind NATs, and with a bit of work, might be a means of completely automating 6to4 connection set up and making it work as easily as Teredo, but without the overhead.  The problem would be that you'd have to somehow automate the generation of a IPv6 subnet using the 16 bit subnet field available to 6to4 such that each user behind the NAT would get a unique IPv6 /64 subnet (perhaps using the last two octets of the 6to4 router's IPv4 address as the IPv6 subnet field).  Obviously, if you wanted more than a single /64, some other scheme would have to be employed (perhaps presuming a shorter prefix length while somehow ensuring uniqueness).  But I digress.  Tongue

 7 
 on: February 07, 2010, 06:51:36 pm 
Started by bombcar - Last post by jimb
These result from misconfiguration of remote name servers. Your name server is reporting these.  Not sure if you can specifically squelch these things in your log.  But have a look at the ARM section for logging:  http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch06.html#id2553006

You could always use the logging config/syslog to shunt BIND logs to a different file so it doesn't "pollute" your messages file.

 8 
 on: February 07, 2010, 06:34:07 pm 
Started by udha - Last post by jimb
You may also have to hose the default route with: netsh int ipv6 delete route ::/0 <interface or index>

Thanks jimb, I'm having touble with the syntax of this command though.

Does anyone know the specific input it is expecting?
That IS the specific input.  See my previous message.

netsh int ipv6 delete route help

Usage: delete route [prefix=]<IPv6 address>/<integer> [interface=]<string>
             [[nexthop=]<IPv6 address>]
             [[store=]active|persistent]

Parameters:

       Tag                Value
       prefix           - Prefix of route to delete.
       interface        - Interface name or index.
       nexthop          - Gateway address, if prefix is not on-link.
       store            - One of the following values:
                          active: Deletion only lasts until next boot.
                          persistent: Deletion is persistent (default).

Remarks: Deletes an IPv6 route.

Example:

       delete route 3ffe::/16 "Internet" fe80::1


Of course, you might not have that route in your routing table, or may have added it as 2000::/3, or not at all.

 9 
 on: February 07, 2010, 04:06:21 pm 
Started by udha - Last post by udha
You may also have to hose the default route with: netsh int ipv6 delete route ::/0 <interface or index>

Thanks jimb, I'm having touble with the syntax of this command though.

Does anyone know the specific input it is expecting?

 10 
 on: February 07, 2010, 02:07:46 pm 
Started by somegroup - Last post by snarked
Quote
Why are you registering an already registered IP?
I don't think you were thinking when you said this.

The script is meant for dynamic connections.  Obviously, someone else who previously was assigned that dynamic IP is also a tunnel holder and used it to establish his/her tunnel in an earlier session.  Of course, they're disconnected now, but such blocks any other tunnel from being established.

Perhaps HE should request the (initial) static vs. dynamic status of any IPv4 address a tunnel is being connected to.  When someone tries to (re-)assign a dynamic address, then HE should ping that tunnel, and if such pings fail, then reassign.  Static assignments would be protected from that procedure.  The former holder of that dynamic IPv4 endpoint would get 0.0.0.0 assigned to that field, thus deactivating that tunnel.

Pages: [1] 2 3 ... 10
Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!