6in4 IPv6 Tunnel natively on Technicolor TG582n
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Trials
- :
- IPv6 Trial
- :
- 6in4 IPv6 Tunnel natively on Technicolor TG582n
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
10-03-2013 6:28 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Quote from: purleigh I'm really not happy that they publish the postcode info, because if you happen to point a registered domain at the 6to4 tunnel then the 'WhoIs' lookup gives enough info for your full name and address to be deduced.
I signed in just to close my sixxs account (I'm not going to get round to making the dynamic thing work before they kill me off for being inactive) and I do remember ticking a box to say "keep my details private".
If I whois myself, it says: "remarks: User Details (address, country, phone, e-mail, url) hidden on request of user".
Anyway, on the other matter, having been told by plusnet that the IP charge was a *ONE OFF* charge, I then needed to briefly put it back in order that I wasn't losing credits from sixxs.
Only AFTER I pushed the button did it say I'll be charged *AGAIN*!! So I got charged £5 once for you to tell the world my full name, then I got charged again for trying to undo the problems caused by ceasing it.
I've made it clear that these charges shouldn't be appearing on next month's bills or I *WILL* be taking it further with the Information Commissioner's Office - I cannot stress how angry I am with this clear breach of trust, if not the data protection act.
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
12-03-2013 2:09 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I've done this with Bytemark to provide my own tunnel brokerage and am quite happy to help anyone like minded to set up their VPS in a similar style.
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
12-03-2013 10:20 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Cheers!
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
12-03-2013 10:26 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
{admin}=>:tunnel 6in4 help
Following commands are available :
add : add a 6in4 tunnel
modify : configure a 6in4 tunnel
delete : delete a 6in4 tunnel
list : list all 6in4 tunnels
flush : remove all 6in4 tunnels
I've not tried it, but give
:tunnel 6in4 flusha go and then start over from the top.
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
13-03-2013 1:36 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
13-03-2013 9:40 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Quote from: ljwhitehouse Followed it from the start once again, but no luck. Doesn't helt, still can't ping the sixxs ipv6 address or google :(.
Took my tunnel 5 hours to be enabled. Did you do
:tunnel 6in4 flush
before starting again?
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
13-03-2013 9:12 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Disable IPV6 stack in windows networking.
Just wondering if there's a better way though.
Is there any way to disable anything outgoing from using the 6in4 tunnel and ipv6, but keep IPv6 open for pinging?
The reasons are:
1: The packet loss from sixxs is unbelievable - around 50%. And because google resolves to an ipv6 address, I spend large amounts of time not being able to use google.
2: All the messing about with static IPs meant that I'm now out of sixxs credit but keeping it alive for a couple of weeks should earn me some credits.
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
13-03-2013 9:21 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
01-05-2013 11:21 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I upgraded my TG582N to 10.2.2.9 and did the list of telnet commands from your post here http://community.plus.net/forum/index.php/topic,106578.msg914793.html#msg914793 - now I can successfully assign Game and Application sharing profiles (the bug that forced me to try the upgrade) and my fibre appears to be working well.
However, my USB / Content Sharing appears disabled. Is there a separate set of telnet commands to switch the port back on?
Cheers
Chris
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
16-04-2014 10:23 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
16-04-2014 8:38 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
16-04-2014 9:04 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
:nat tmpladd intf=Internet type=nat protocol=ipv6 outside_addr=0.0.0.1 inside_addr=0.0.0.1 foreign_addr=212.113.147.150
An immediate, corresponding mapadd occurs, apparently. The result ought to be that an external address is routed to an internal one, but if you type this:
:nat maplist expand=enabled
The result is the following (where xx.xx.xx.xx is my *external* IPv4 IP address in all cases):
xx NAT Internet xx.xx.xx.xx xx.xx.xx.xx 0
Access List................... xx.xx.xx.xx
Foreign Address............... 212.113.147.150
Protocol...................... ipv6
Flags......................... Instance
Weight........................ 10
Description................... Two-way NAT
Creator Data.................. 0
But you would expect:
xx NAT Internet xx.xx.xx.xx 127.0.0.1 0
Access List................... 127.0.0.1
Foreign Address............... 212.113.147.150
Protocol...................... ipv6
Flags......................... Instance
Weight........................ 10
Description................... Two-way NAT
Creator Data.................. 0
Which can only be the result of this command:
:nat tmpladd intf=Internet type=nat protocol=ipv6 outside_addr=0.0.0.1 inside_addr=127.0.0.1 foreign_addr=212.113.147.150
I have tried not using this rule at all, or using 192.168.1.xx instead of 127.0.0.1 (but all the other rules in the list use 127.0.0.1, i.e. the IPv4 loopback, to refer to the router, rather than by its own local static address). However, no amount of experimentation allows incoming traffic to flow via the IPv4 NAT "Game and Application" rules. Am I wrong to expect this? Should I use direct firewall rules and assume that IPv6 will always simply bypass NAT? In which case, why does the above tmpladd instruction (which leads to an immediate mapadd being carried out without my input, and vice versa with tmpldelete --> mapdelete) even need to be done? It doesn't seem to have any obvious effect, as far as I can see. What am I missing here?
Simply, if, say, 192.168.1.x is my server, with ports 80, 443 and others forwarded by NAT ("Game and Application settings"), how can I get the same result in IPv6 with 6in4?
As an alternative, if I do *not* use NAT but use firewall rules instead (duplicates of those already on the firewall on the server, but ho hum), can I, for example, have multiple machines as IPv6 servers (or otherwise as directly addressable machines) in theory? (Obviously, I realise this is not possible via IPv4 and thus not in a dual stack, but it would be nice to know, all the same.) You could see how each could have a different domain name on the same ports, for instance, which NAT prevents in the normal IPv4 stack...
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
16-04-2014 9:29 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
:firewall config state=disabled
Suddenly the server was reachable by IPv6 ping. Naturally, seconds later, I typed:
:firewall config state=enabled
And, hey presto, ping fails. Clearly we need some separate firewall rules here, as NAT doesn't seem to work for this. This fits with my general understanding of IPv6, although, as you can tell from the above comments, I am an "explorer" or "enthusiast" rather than a "sage", in Hurricane Electric's terminology 🙂 I hope this process of answering my own questions helps someone.
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
16-04-2014 10:35 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Quote from: talat To clarify my issue briefly, I noticed that the following goes wrong (using Matt Turner's example SixXS IP addresses rather than my HE one): :nat tmpladd intf=Internet type=nat protocol=ipv6 outside_addr=0.0.0.1 inside_addr=0.0.0.1 foreign_addr=212.113.147.150
An immediate, corresponding mapadd occurs, apparently. The result ought to be that an external address is routed to an internal one [...]
I'm not sure that's the case. I'm not overly familiar with that command but I believe 0.0.0.1 could be Thomson notation for 'this address' i.e. it gets substituted for the router's address (of the WAN interface most likely).
Quote But you would expect: xx NAT Internet xx.xx.xx.xx 127.0.0.1 0
Access List................... 127.0.0.1
Foreign Address............... 212.113.147.150
Protocol...................... ipv6
Flags......................... Instance
Weight........................ 10
Description................... Two-way NAT
Creator Data.................. 0
As above, I don't think that is what you're after because the tunnel is established between the remote endpoint and the router. Both addresses need to be globally routable which 127.0.0.1 obviously isn't.
Quote However, no amount of experimentation allows incoming traffic to flow via the IPv4 NAT "Game and Application" rules. Am I wrong to expect this?
They will only affect IPv4 traffic which, if my understanding of your requirement is correct, won't aid your IPv6 traffic routing.
Quote Should I use direct firewall rules and assume that IPv6 will always simply bypass NAT?
Yes. All IPv6 traffic will be coming through the IPv4 tunnel and sitting on your router ready to be routed in to your LAN i.e. only the IPv4 traffic (which includes the tunnel) passes through the NAT - the IPv6 on the inside of the tunnel never sees that NAT at all. However, without the necessary firewall rules the IPv6 traffic will, once 'unwrapped', be subsequently dropped given that, I believe, the default IPv6 firewall on the Thomson's only allows solicited responses to pass through. Unsolicited traffic, such as requests originating on the outside for services listening on the inside, are blocked unless you poke the necessary holes through to allow it (like how you do with the IPv4 Game and Application settings).
Quote In which case, why does the above tmpladd instruction (which leads to an immediate mapadd being carried out without my input, and vice versa with tmpldelete --> mapdelete) even need to be done? It doesn't seem to have any obvious effect, as far as I can see. What am I missing here?
I'm no expert on those commands but I think they are simply telling the router what to do with the traffic it receives. Normally an IPv4 NAT rule would pass it on to a LAN device however in this case you want the router to pass it to itself, at which point the router will unwrap the IPv6 traffic and the IPv6 stack will then pass it to the LAN.
Quote Simply, if, say, 192.168.1.x is my server, with ports 80, 443 and others forwarded by NAT ("Game and Application settings"), how can I get the same result in IPv6 with 6in4?
I think you will have to set up the necessary IPv6 firewall rules (I'm not familiar with exactly how - it looks pretty complicated to me). Or disable the firewall as you have done (notwithstanding the caveats in doing so).
Quote As an alternative, if I do *not* use NAT but use firewall rules instead (duplicates of those already on the firewall on the server, but ho hum), can I, for example, have multiple machines as IPv6 servers (or otherwise as directly addressable machines) in theory?
Absolutely, and that's one of the key benefits of IPv6 whether you are running it natively or via a tunnel. The vast address space means that an ISP can (and do) assign a range of addresses to end users and thus you can assign each device a globally unique, and routable, IPv6 address.
Quote (Obviously, I realise this is not possible via IPv4 and thus not in a dual stack, but it would be nice to know, all the same.) You could see how each could have a different domain name on the same ports, for instance, which NAT prevents in the normal IPv4 stack...
Spot on.
Re: 6in4 IPv6 Tunnel natively on Technicolor TG582n
17-04-2014 5:19 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Thanks a lot: your reply really helped me understand where I was going wrong. I have learned a lot about IPv6 and IPv4 routing, and firewalls, over the last few hours! 🙂
I see now that the unusual routing where outside_addr, inside_addr and access_list all end up being identical is something of an interesting hack that re-routes the IPv4 traffic encapsulating the IPv6 traffic over the tunnel back to the external interface, i.e. in order to make it appear to come from the WAN side like normal IPv6 traffic would. That is, if I understand your meaning correctly when you describe the traffic as being "unwrapped". Since it's such an unusual way of doing things, perhaps it's not surprising that I was a bit misled - anyway, thanks a million for putting me right 🙂
(From some rather haphazard efforts at testing before I realised what I needed to do, I suspect that it will work without this instruction, but it's quite possible that the traffic would then always be logged as though the originator was the tunnel and there might be other problems that I don't fully understand - but I've not tested this very thoroughly, to be honest, so this is speculation based on it seeming to work without the tmpladd instruction or with the wrong one above that I was using before you corrected me...)
It's interesting and useful that the router seems to automate the translation of tmpladd and tmpldelete instructions into mapadd and mapdelete instructions consistently: saves time! 🙂
Anyway, after much heartache, it did turn out to be very much simpler than I anticipated to set up the firewall rules. When you "turn off" the firewall, you actually only turn off a small part of it by switching from the forward_level_Standard to the forward_level_Disabled chains (there is also forward_level_Blocked for a very tough firewall with no access from the LAN). The one of these that you have activated, in turn, is linked to the forward_level chain, which is the parent. This is third from the bottom of the chains of rules in the firewall table, quite far down.
What foxed me for any hours is that you should NOT specify "srcintf=wan" (in "firewall add rule") or else it won't forward your traffic. Just leave that part out entirely.
Supposing we use an alias for the server called "server1", we can do this:
:expr add name=server1 type=ip addr=<ADD THE IPv6 ADDRESS OF YOUR SERVER HERE>
If you don't do this, you could replace "server1" in the following with the IPv6 address instead, if you like, but it's neater and easier to change later if you use the previous instruction, especially if you have lots of rules. Call the rule whatever you like, where I have chosen "IPv6HTTP" etc. You can choose "log=enabled" or leave it out if you want it disabled.
:firewall rule name=IPv6HTTP add chain=forward_level_Standard dstip=server1 serv=http log=enabled action=accept
:firewall rule name=IPv6HTTPS add chain=forward_level_Standard dstip=server1 serv=https log=enabled action=accept
If you need to set up any other "services" for ports, you'll need to find their names with:
:expr list
You may need to add some that aren't listed with, for example (for IRC):
:expr add name=irc type=serv proto=tcp dstport=6667
It's also possible to set up a custom firewall setting instead of using the "Standard" one:
:firewall level add name=Normal text=”How I like the firewall set normally” policy=drop
:firewall rule add chain=forward_level_Normal srcintf=lan action=accept
You can change the order by inserting them with "index=xx", which will place it above the one that currently has that number, and re-numbering the original +1 below it.
The second command (optional) ensures access from within your LAN (like the default "Standard" firewall setting"). You'll then want to activate it. I expect you can do this from the CLI but it's easy enough to switch firewall setting levels from the web interface so I didn't bother to find out how. What you can't do from the web interface is edit them, of course.
It goes without saying that using "nat tmpldelete index=xx" (and also "nat mapdelete index=xx"), "firewall rule delete chain=forward_level_Standard index=xx" needs to be undertaken with considerable care unless you feel like getting totally lost and needing to hard reset your router, losing all your own configuration! 😉
Another important thing to do - which I will do in just one second! - is ":saveall", which will save it to user.ini on the router. You can download a copy by ftp:
ftp 192.168.1.254 (or whatever)
(user name and password)
binary
get user.ini
exit
The ftp interface doesn't have the peculiar backspace deleting forwards behaviour that was a pain until I realised that you actually *can* delete errors in the telnet interface 😉
It's obviously possible to put this back on the router in the same way by using "put user.ini" later.
I hope that this experience helps someone who follows. Many thanks to MJN and apologies if I've still misunderstood anything above. Anyway, it works, so hooray!
Lastly, most of what I figured out came from a combination of playing with settings one by one and then putting them back, but the following was invaluable:
http://phil.tinsleyviaduct.com/tg582nfirewall.html
All the best,
Talat
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page