Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  


Welcome to Hurricane Electric's forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - kasperd

Pages: [1] 2 3 ... 64
IPv6 Basics & Questions & General Chatter / Re: automatic banning
« on: March 30, 2014, 04:22:03 AM »
So, I am seeking something like fail2ban working with ipv6.
I don't know specific software to suggest, but I can point out some of the design requirements for such software. Knowing this is important in order to evaluate any solutions.

An important challenge is the wide range of possible prefix sizes an attacker could have access to. An attacker with access to an entire /32 range is not the most common scenario, but it is certainly possible. A lot of /32s have been handed out already, it only takes one of them having an administrator with shady intentions, or simply a network configured in such a way that customers/users effectively have access to use addresses from all over the /32 allocated to the ISP. OTOH there may also be attacks with access to just a single IPv6 address where the neighboring IPv6 address belongs to a legitimate user.

A working solution need to be able to apply meaningful throttling if an attacker jumps all over a /32. Meanwhile an attacker with only a /128 must not be able to perform a DoS attack against legitimate users on the same /124.

The solution thus must be something, which applies different blocking thresholds for different prefix lengths. Thresholds that are exponential in the prefix length could give a way too high threshold for a /32. OTOH linear thresholds could end up in a situation, where it takes just two /64s to cause blocking of a /32.

One example strategy could be that a /128 gets to do 2 attempts before blocking happens, a /127 gets to do 4 attempts, a /126 gets 6 attempts, etc. A /64 would then be permitted 130 attempts and a /32 would be permitted 194 attempts. But two /64s using their 130 attempts each would then be more than enough to use the 194 attempts quota for the /32. In fact extrapolating this linear strategy would mean two /64s would hit the quota for 2000::/3 before they each had used their quota.

A better strategy could be to use a slower linear growth from /128 through /64 and quadratic growth for prefixes shorter than that. For example a /128 gets 2 attempts, a /127 gets 3, etc. with a /64 getting 66 attempts. Then you start adding increasing numbers such that a /63 gets 66+2 attempts, a /62 gets 66+2+3 attempts, etc. and a /32 gets 66+2+3+...+33 = 626 attempts before you block the entire /32.

SSH, telnet, SMTP, POP, Phones, ...
What are you trying to protect against? Software vulnerabilities or password brute forcing?

Many software vulnerabilities can be exploited using only a single connection, so you'd be compromised before even realizing you were under attack. For such cases keeping software updated is the way to go, blocking failed logins will do you no good.

Protecting against password brute force is something for which rate limiting does help. But enforcing stronger passwords may be a more useful solution. With ssh you can even disable password authentication completely. I usually configure sshd to only accept public key authentication.

Anyone tried this kind of ICMPv6 traffic before?
I have been playing a bit with it
Code: [Select]
ping6 -n -i0.2 -Nname 4620.kasperd.netI don't know if there is any kernel with RFC4620 support built in. It does seem like something you'd only have a user mode daemon to respond to. And for obvious reasons, this is a daemon one would not expect to be installed by default. I haven't even tried installing such a daemon on Ubuntu, but I have however implemented an RFC4620 responder in my own stack, and tested interoperability with the ping6 command on Ubuntu. (Ubuntu 12.04 or later needed, since earlier versions did not have this option for ping6).

Zone failed validation test. (

Any clue what validation test this is failing?
I have four guesses for what might cause software to reject that as an invalid domain:
  • Checking TLD against an outdated list of all valid TLDs
  • Using the first character to distinguish between IP address and domain name.
  • Checking the length of the domain name against the maximum length of a label (63) instead of against the maximum length of a domain name (255).
  • Off-by-one error in checking label length against maximum permitted length.

I guess I could bring the Tunnel up on the VPN server.  That seems kind of silly, but I figure it'd work?
That could work. There is a few gotchas to watch out for.
  • You could end up having two different default routes on the VPN server. If you end up with such a setup, you have to solve the routing problem on the VPN server instead. If the VPN server is running a different OS that might be easier than on the router.
  • If the VPN server is configured with only one default gateway (which is going through the tunnel), then you cannot use any of the Comcast IPs on the VPN server.
  • How are you going to address the VPN servers interface to the LAN? Using an address from the /48 routed from HE? Using an address from the /64 routed from Comcast? Both? Neither and only link-local?
  • You want to make sure your current router has statics route specifying the VPN server as gateway for all the prefixes you got from HE.
  • You want to make sure the VPN server has a static route specifying it is directly attached to the /64 routed from Comcast. (This would happen automatically, if that interface had an IP address from the comcast range, but if it does not, then you have to configure it manually.)
  • If the VPN server does not have a public IPv4 address, you'll need to forward protocol 41 to it.

I can come with more suggestions, if I know a bit more about your current setup.

Comcast won't give me another /64 or a /60, etc.
Really? Are they using DHCPv6? Have you tried requesting delegation of a /48, /56, or /60 through DHCPv6?

I see no reason for handing out less than a /60 by default.

I know I can keep the Tunnelbroker tunnel up, but for whatever reason, even with policy-routing firewall rules, traffic meant to go out the tunnel ends up going out the Comcast v6 link.  Obviously, this is breaking routing for my routed /64 and /48 from Tunnelbroker.
And this is why I am opposed to reverse path filtering. Reverse path filtering breaks legitimate use cases such as yours. Anybody with nefarious purposes will most likely be able to perform any spoofing they desire, regardless of reverse path filtering.

Has anyone else attempted this kind of setup? If so, have you been able to get it working properly?
In principle, what you want is for each routing table entry to be valid only for a range of source IP addresses. If you could have two different default routes - one valid for Comcast sources and one valid for HE sources, then your setup would work.

I have no specific experience with such a setup with pfSense, I have however made such a setup using my own stack, so I know it can work.

Actually it could work even better, if most important hosts have one IPv6 address from each range and then uses MPTCP. But you need to figure out the routing first before you could possibly take advantage of MPTCP.

If you post your current pfSense configs, there might be forum users, who can spot where your problem might be.

BTW. Anybody else noticed the pfSense website is unreachable over IPv6?

Tried again, leaving off '/64' from client and server ipv6 addresses. Output attached.
Output looks better. I think that is the format, which the script expects. But the error messages sounds like cleanup after the previous run was needed. That means either you need to figure out the sequence of commands needed to clean up after the previous run, or you need to reboot the machine and then run the script again.

If it still doesn't work, there are two likely explainations. Either the client IP on the server does not match the external IP of your NAT, in which case you just need to update the setting on the tunnel server. Or the NAT cannot pass protocol 41 in its current configuration, in which case you need to figure out, if the NAT need to be reconfigured.

Looks like the input you gave the script is not in the expected format. What does the output look like, if you omit the /64 from client and server address?

General Discussion / Re: cannot locate the AAAA records from my Domain
« on: March 12, 2014, 11:20:49 PM »
We only need to get to administrator.
Good, cause you won't make it all the way to Sage, with the DNS server, the domain is hosted on.

Now I have my domain, thanks to godaddy, I went in and added the AAAA record info with my end local point ipv6 address...
I see a AAAA record on your domain. But when I try to connect I get connection timeout, presumably because you turned off the computer.

I played with the IIS stuff, but when I run the cmd nslookup, set q=aaaa, cannot find my aaaa record.
I cannot reproduce this. But it should not matter, since you are not using HE for authoritative DNS.

Also when I try to reach my domain using firefox I get a 401.3 error. that I am not authorised.
Sounds like your problem is with IIS. In other words, the IPv6 part is working, but you need to find a guide to configuring IIS. All I know about IIS is that it runs on an OS, which I have no experience with. But Google can find thousands of pages about that particular IIS error message, one of them might answer your question.

However, what is meant by "client IPv4 address" in my case? I am connected on a laptop via wifi to a modem/router supplied by my isp (Time Warner Cable). Would it be the internal LAN ip4 address assigned to my laptop by the router?
Looks like it expects the internal IPv4 address of the machine you run the script on. Configuration of NAT (if needed), and update of the tunnel server (in case your extern IP is dynamic) does not appear to be done by this script.

Easier to service non-prod when you can drive down the street to the other facility :)
I know what it's like. I have previously had to service a production system with lots of moving parts nine time zones away.

IPv6 on Routing Platforms / Re: ipv6 on comcast
« on: March 11, 2014, 11:36:50 AM »
Isn't Comcast one of those few ISPs who are serious about IPv6? The configuration page looks like it is intended for native IPv6 not tunneling. I suggest you forget about the service for a bit and instead contact Comcast asking, how you should be configuring this router. If you can get native IPv6, that should give you a better end result than a tunnel.

one just has to guess the DNS64 address in order to be able to use it.
I have guessed that address. I see now what the quotes around anycasted are implying. Using a tunnel server in Frankfurt and connecting to an IPv4 address in Europe, my traffic got routed through a NAT64 in Fremont (based on reverse DNS on last hop before the NAT64). With that sort of latency, I don't see myself using that NAT64 for much.

Searching on Google I see 6 hits when searching for the IPv6 prefix of the NAT64 and 57 hits when searching for the IPv4 address. But zero hits when searching for pages mentioning both the IPv6 and IPv4 address.

The 'anycasted' nat64/dns64 service I set up there appears to still be working years later, and should only be usable for people connecting from 2001:470::/32
Since it wasn't really a publicized project, I'll not mention how to use it.
If it was using the well-known NAT64 prefix, I would have found it already. So for some reason it must be using different addresses. One reason for not using the well-known prefix could be, that using an anycasted prefix can be a bit tricky. It may be easier to just use an anycast address for the DNS64 servers, and let the servers use a unicasted NAT64 prefix in replies. That way which NAT64 instance will be used is decided at the time of the lookup. The DNS64 server could even include two (or more) different prefixes in different AAAA records, such that clients can do failover between the NAT64 instances.

If that is how the setup looks, one just has to guess the DNS64 address in order to be able to use it.

General Discussion / Re: Having a slight problem on Sage level test
« on: March 10, 2014, 02:05:23 PM »
What do I need to do to fix this?
What is the domain name? Without knowing the domain name, we can't figure out what your problem is.

and then you'll turn it off when sites/applications using IPv4 literals breaks the experience.
This is the canonical example of a situation where NAT44 works better than NAT64. Supposedly there are also situations, where NAT64 works better than NAT44.

I have been wondering if a user could configure just the DNS64 setup on their network but not the NAT64 part. It could work if HE was running a NAT64, such that users do not have to run their own. I think such a setup would probably be closer to what was asked for.

However as far as I can tell, HE is not providing any NAT64. Has HE ever considered NAT64? Or has it simply been assumed, that none of the users would make use of NAT64 even if it was available?

Pages: [1] 2 3 ... 64