Hurricane Electric's IPv6 Tunnel Broker Forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Pages: [1] 2 3 ... 10
 1 
 on: February 22, 2017, 12:53:20 PM 
Started by qdeqde - Last post by broquea
Right now, it seems fixed. The tunnel server of Prague is still emulated in Berlin, like before this outage. It seems that Prague server is gone for good.

Prague server is in Berlin until getting equipment bought in the US and shipped into the EU is made easier with customs. There are plans to replace the hardware in Prague and re-home the tunnels back to it.

 2 
 on: February 22, 2017, 12:04:17 PM 
Started by leifnel - Last post by cholzhauer
You would use something like wire shark to look at incoming packets, but as was mentioned, it won't normally work with CGN

 3 
 on: February 22, 2017, 11:52:29 AM 
Started by qdeqde - Last post by oskar
Right now, it seems fixed. The tunnel server of Prague is still emulated in Berlin, like before this outage. It seems that Prague server is gone for good.

 4 
 on: February 22, 2017, 11:38:56 AM 
Started by qdeqde - Last post by checkroot
Prague is responding to ping, but routing still fails. I hope you'll fix that soon.

OT: Are you planning to start offering paid tunnel service?

 5 
 on: February 22, 2017, 09:35:31 AM 
Started by leifnel - Last post by tjeske
I don't think proto 41 works like that. It's not like you open a connection, and this connection stays open and all data flows through it and the switches at your end will know where to send the data. No. Proto 41 needs end-to-end connectivity. How should the gateway know it is you that wants this package? You can monitor your interface with Wireshark to check for incoming proto 41 packages, but I think most 4G gateways will only work for TCP and - if you're lucky - UDP and ICMP.

 6 
 on: February 22, 2017, 09:12:05 AM 
Started by leifnel - Last post by tjeske
I know it's a lot of work, but there's also the option to take your server elsewhere, to a service, that offers a whole subnet. I wouldn't even think of IPv6-nat as well. Many devices probably won't even be able to work that way. At least you'd be the one controlling the port forwardings, so you wouldn't have to worry that much about your monitoring equipment.

And no, SixXS is/was the only service with ayiya.

 7 
 on: February 22, 2017, 09:03:00 AM 
Started by leifnel - Last post by leifnel
> There's always the option of renting an IPv6-capable server and setting up your own tunnel service.

I have that, but unfortunately it only have a single address; I have tried getting a subnet, but they can't handle that yet.

I don't want to have to nat all my hosts through a single ipv6 address (if at all possible), because that defeats the purpose of having "all" my monitoring equipment available from outside.

But us the AYIYA/AICCU available anywhere else than sixxs?

 8 
 on: February 22, 2017, 08:30:29 AM 
Started by bakaekze - Last post by bakaekze
Thanks for your help. Set other routers/AP to automatic ipv6 mode and it seems to work perfectly.   ;D

 9 
 on: February 22, 2017, 08:29:11 AM 
Started by leifnel - Last post by leifnel
Does there exist any linux tools which can test if protocol 41 gets through the network (4G) and my router?

I have access to linux boxes outside my network which can be used as endpoints.
But as my home network has no public IP; it is on Carrier grade Nat, the connections have to be initiated from my network to my external hosts.


 10 
 on: February 22, 2017, 07:42:43 AM 
Started by mijedk - Last post by mijedk
Turns out the above worked pretty badly for what i wanted, so went with ospfv3 instead, that however is working exactly like I wanted it now.

Still using the same Linux VM as above, with the same tunnel conf, but installed quagga with a simple zebra/ospf6d conf (ens192 is what's connected to the palo alto interface/vlan, ens160 is only used for ipv4 for the tunnel), moved the fde4:8dba:82e1::1 to ens192 instead, this is main parts of the quagga conf:

!
interface ens192
  ip address 10.10.90.1/24
  ipv6 nd suppress-ra
  ipv6 ospf6 network broadcast
!
interface he-ipv6
  ipv6 nd suppress-ra
  ipv6 ospf6 network point-to-point
  ipv6 ospf6 passive
!
router ospf6
  router-id 10.10.90.1
  interface ens192 area 0.0.0.0
  interface he-ipv6 area 0.0.0.0
!
ipv6 route 2001:470:xxxx::/48 ens192
!
ipv6 forwarding
!

I wanted to use different /56 on varies different interfaces/vlans on the palo alto fw, so this is how i configured it:

On the Palo Alto firewall, created a new (sub)interface on the same vlan as ens192 on the Linux VM, gave it an fde4:8dba:82e1::2 address, added 10.10.90.2/24, enabled ipv6 on the interface (L3), assigned the default virtual router to the interface, then went to ospfv3 on the default virtual router config, set the router id to 10.10.90.2, ticked enable, added a new 0.0.0.0 area, added the interfaces i wanted to use the different /56 networks on (default settings), on the main ospfv3 settings page, unticked "Reject default route", then went to "Static routes" -> IPv6, added a new default route for IPv6, dest = ::/0, interface = the interface the linux vm is connected to, next hop, IPv6 address = fde4:8dba:82e1::1.

Added firewall rules as needed (looked at the monitor tab).

Just posting in case anyone else is having issues getting it to work on the palo alto fws, it's not the easiest thing to find help on, and this is in no way best practices for anything, just pushing different things until it works :P

Pages: [1] 2 3 ... 10