Print

[Ninho]

A smiley for a start, since I've setup a first working tunnel !!!

Now for the remarks with questions :

This here machine is running Windows 2k SP4, connected to ADSL thru a Speedtouch ST510 modem/router/switch. The Speedtouch has the IPv4 addie assigned by ppp0A, and the LAN machines use non routable 10.x.x.x addresses assigned by the router's DHCP server. Quite classical home installment. Also, the NAT passes 'protocol 41' packets to the selected machine.

For the setup page to work, I had to (temporarily):

1- allow the ST to reply ICMP 'pings',
2- define the Win 2k machine as a "default server"

Apparently this is no more necessary once I received my parameters, the tunnel is happily humming.

The remark is that settings 1 and 2 were not evident to find.
The question is why should they be necessary, and if so why only for the setup phase ?
Also, I assume/fear that, should I have to make a change in the setup page (as I'll have to), I'll have to redo all the temporary changes to the modem config, which is a chore :=(

I have another question ,which I'll open another thread for.

Thank you!

[jimb]

A smiley for a start, since I've setup a first working tunnel !!!

Now for the remarks with questions :

This here machine is running Windows 2k SP4, connected to ADSL thru a Speedtouch ST510 modem/router/switch. The Speedtouch has the IPv4 addie assigned by ppp0A, and the LAN machines use non routable 10.x.x.x addresses assigned by the router's DHCP server. Quite classical home installment. Also, the NAT passes 'protocol 41' packets to the selected machine.

For the setup page to work, I had to (temporarily):

1- allow the ST to reply ICMP 'pings',
2- define the Win 2k machine as a "default server"

Apparently this is no more necessary once I received my parameters, the tunnel is happily humming.

The remark is that settings 1 and 2 were not evident to find.
The question is why should they be necessary, and if so why only for the setup phase ?
Also, I assume/fear that, should I have to make a change in the setup page (as I'll have to), I'll have to redo all the temporary changes to the modem config, which is a chore :=(

I have another question ,which I'll open another thread for.

Thank you!

I believe HE requires your tunnel gateway endpoint IPv4 to respond to pings in order for it to allow tunnel setup.  In your case, since your tunnel gateway is behind your NAT router (speedtouch), so the NAT router needed to respond to the pings.  This just allowed the tunnel to be set up.

Setting up your tunnel gateway as the "default server" caused all unsolicited traffic to be NATed and mapped to your tunnel gateway.  So, when IP protocol 41 traffic arrived at your speedtouch's public IP, it was routed to your tunnel server automatically.

In all likelihood, this wasn't actually needed.  If you had your tunnel gateway fully configured, and caused it to generate tunnel traffic by doing something like pinging the other side of the tunnel by IPv6 address, it likely would have caused the speedtouch to create a NAT/connection table entry associating traffic for IP proto 41 with the IP of your tunnel gateway, like this:

Outside IP	Outside SPort	Outside DPort	Protocol	Inside IP	Inside SPort	Inside DPort	TTL
123.45.67.89	N/A	N/A	41	10.0.0.10	N/A	N/A	300

(where 123.45.67.89 is your public IP, and 10.0.0.10 is your tunnel gateway's IP on your LAN)

This would have caused the same effect as putting in that "default server" entry.  This is why it's working after removed it.

However, not the TTL field.  When the router/firewall stops receiving traffic matching that entry, it will start counting down from whatever the TTL is on your router.  Once it hits zero, the entry will be removed.  When that happens, it will only be recreated when your tunnel gateway generates traffic again.  This means that if the HE tunnel server sends traffic down the tunnel when this entry is not present, your firewall will simply drop it and your tunnel will be down until your gateway triggers another entry.

This is why I say it's always best to create a static NAT entry on the router specifically pointing that traffic to your tunnel gateway.  That way, it will never time out.  Unfortunately, not all consumer grade router/firewalls are capable of doing this.

[Ninho]

Hi, Jimb !

For the 1st question (pingability), I got an email from friendly HE support personnel asserting that the working of the tunnel - not only the set up phase - requires it. So be it ! I was surprised because automatic 6to4 using the well-hown public anycast definitely does NOT require pingability of the local end point.

As for the second question, I have a permanent rule in the Speedtouch which NATs protocol 41 packets to the machine hosting the tunnel end point, there is no expiry. This is sufficient to make the tunnels work as designed, be it 6to4 or (HE) 6in4, BUT again for the setup script at the web site it didn't work till I added the "default server" kludge, which I removed after I received my connection details. I am not sure this description matches your analysis. Apologies for my being not overly precise in the original question.

This is why I say it's always best to create a static NAT entry on the router specifically pointing that traffic to your tunnel gateway.  That way, it will never time out.  Unfortunately, not all consumer grade router/firewalls are capable of doing this.

Fortunately the ST can do this. It also features a "helper" or ALG for protocol 41, which needs to be removed (unbound) first since whatever that helper does is clearly not intended for modern 6in4 operation. I didn't mention this detail because I thought it was irrelevant to the question - adding this point now just in case this thread may be searched and found by Speedtouch owners in the future.

[jimb]

Hi, Jimb !

For the 1st question (pingability), I got an email from friendly HE support personnel asserting that the working of the tunnel - not only the set up phase - requires it. So be it ! I was surprised because automatic 6to4 using the well-hown public anycast definitely does NOT require pingability of the local end point.

Yeah this would just be something HE would do to verify reachability of your end node and eliminate support calls, do a bit of a sanity check, verify that it's a real reachable IP to help with DOS/griefer type stuff, etc. 

As for the second question, I have a permanent rule in the Speedtouch which NATs protocol 41 packets to the machine hosting the tunnel end point, there is no expiry. This is sufficient to make the tunnels work as designed, be it 6to4 or (HE) 6in4, BUT again for the setup script at the web site it didn't work till I added the "default server" kludge, which I removed after I received my connection details. I am not sure this description matches your analysis. Apologies for my being not overly precise in the original question.

Hrm not sure why that happened.  If the speedtouch had a static DNAT then everything should have just worked, unless the entry was messed up in some way.  Also, you not only need a NAT entry, but you also need to allow the traffic through in the security policy.  Some router/firewalls combine these, others have completely separate entries for this.

This is why I say it's always best to create a static NAT entry on the router specifically pointing that traffic to your tunnel gateway.  That way, it will never time out.  Unfortunately, not all consumer grade router/firewalls are capable of doing this.

Fortunately the ST can do this. It also features a "helper" or ALG for protocol 41, which needs to be removed (unbound) first since whatever that helper does is clearly not intended for modern 6in4 operation. I didn't mention this detail because I thought it was irrelevant to the question - adding this point now just in case this thread may be searched and found by Speedtouch owners in the future.

Not sure what this would do beyond a normal NAT.  Maybe proto 41 has something the ALG can grab onto to uniquely map outside/inside.  I haven't really looked at the packet format for 6in4.  Or it's for translation of payload stuff, although I can't imagine what would need it in 6to4 or 6in4 off the top of my head.

[Ninho]

this would just be something HE would do to verify reachability of your end node and eliminate support calls, do a bit of a sanity check, verify that it's a real reachable IP to help with DOS/griefer type stuff, etc.  

According to HE (I assume I may quote them) :
"We ping6 your side of the tunnel from the tunnel-servers for determining
latency reports."

the ST ... features a "helper" or ALG for protocol 41, which needs to be removed (unbound) first since whatever that helper does is clearly not intended for modern 6in4 operation.

Not sure what this would do beyond a normal NAT.  Maybe proto 41 has something the ALG can grab onto to uniquely map outside/inside.  I haven't really looked at the packet format for 6in4.  Or it's for translation of payload stuff, although I can't imagine what would need it in 6to4 or 6in4 off the top of my head.

No idea either. Sure enough, the helper is no help & MUST be removed using the Telnet interface.

thanks for your instructive insights !

[Ninho]

Not sure what this would do beyond a normal NAT.  Maybe proto 41 has something the ALG can grab onto to uniquely map outside/inside.  I haven't really looked at the packet format for 6in4.  Or it's for translation of payload stuff, although I can't imagine what would need it in 6to4 or 6in4 off the top of my head.

I've given this question some (very limited) thought. Here's a hypothesis, on outgoing proto-41 packet the helper may be noting the destination IPv6 address in the payload, in addition to the IPv4 addresses.
Use that info to address ingoing proto 41 packets back to the right machine on the inside LAN.
This would be a 6-over4 scenario without an IPv6 router on the inside, the Speedtouch playing the role of a 6-over-4 router. Suppose it's possible ?

I aint going to break my working network in order to try this idea anyway :=)

[Ninho]

For the record, I think I've determined how that ALG is supposed to work :

on INcoming protocol 41 packets, extract the MAC address from the host part of the Destination (local) IPv6 address - use that to route the packet to the correct machine.

Of course this strategy works only for that subset of local IPv6 addresses which have the adapter MAC number embedded, making it was not suitable for use with HE or most other tunnels.

Fortunately the solution as I explained earlier is to forget about the ALG entirely and have the Speedtouch forward all proto 41 packets to one host designated as IPv6 router on the LAN.

[sujay]

I was stuck with the same problem as the first post and my router does not allow a static NAT entry.
I also fail to understand the logic that a default route will cause things to work.
Anyways, the way I got it working was to put the DSL to bridged mode and have dial up PPPoE session
from the desktop, the desktop was then reachable and pingable.
Hope this also helps newbies.

[Ninho]

Anyways, the way I got it working was to put the DSL to bridged mode and have dial up PPPoE session
from the desktop, the desktop was then reachable and pingable.

Well I would not recommend bridging unless you only have the one computer; and even then, bridging is not advisable from a security point of view since it is putting the computer on the wild Internet (v4).

[kriteknetworks]

ninho, but you dont state why you wouldn't. Surely you must know there are hundreds of thousands of PCs acting as routers, and firewalls.

You drew some conclusion that "putting the computer on the wild internet (v4)" is somehow a bad thing. That leads me to believe you think NAT is some panacea of security, and few are aware of, let alone capable of, installing a firewall on the PC itself, regardless if its a standalone machine, or functional router.

If I'm wrong, please correct me.

[Ninho]

You misinterpreted me, I think, Kriket. I don't think NAT to be a panacea, as you say, or that few are capable of understanding network security. Come to think of it, I do think that few are understanding it, but those few certainly include you, Sujay and me. I sure hope Sujay has his settings tightened.

But... since he explicitly mentioned "helping newbies", I believe it is not so much a good idea to tell them to bridge one computer and then use that as a router and/or  internet sharing device (if they know how to do it) when they already have a dedicated device on their LAN.

Now I /assumed/ Sujay's post was using the same Thomson router I discussed above in thread. Re-reading, possibly I was mistaken and is Sujay saying /his/ (unspecified) router won't pass proto 41 thru NAT ? If this is indeed the case, for(give|get) my remark  ;=)

[snarked]

The pinging is required not just for latency reports but to make certain that the tunnel is still functional, especially in the case where the remote IPv4 endpoint is a dynamically assigned address (which can be "down").  It's not really needed for static IPv4 assignments other than to detect routing errors.

6to4 is based directly on the IPv4 address, so it doesn't need pings.  When one's IPv4 address changes, so does one's 6to4 address prefix.


Re: "NAT being a panacea of security:"   In one sense, it can be.  Without further configuration, it tends to reject inbound connections since they are not related to any outbound connections that have passed through the translation table.  However, I do agree that such was never intended by design as security.

[BobRobertson]

The problem I'm having is that the budget-priced Belkin router I'm using cannot filter by "protocol", only "port". The poor router knows only about TCP and UDP. I'm left to conclude that the packets labeled IPv6 are being dumped.

So it's off to make my system the "DMZ", and see if that makes the difference...

Yep. Turning on the DMZ setting to the private address of my (by Cromm I hate this term) "desktop" did the trick.

If my VoIP phone service worked through a Linux box acting as a router, I wouldn't have this problem. But Noooooo.

Re: "NAT being a panacea of security:"   In one sense, it can be.  Without further configuration, it tends to reject inbound connections since they are not related to any outbound connections that have passed through the translation table.  However, I do agree that such was never intended by design as security.

While certainly true that NAT was not designed for security, the effect has been to create a default of "no inbound initiated connections" that is very nice to have in a world where the vast majority of users get their box home from the store, turn it on, and expect it to just work.

Services that the naive user doesn't know exist, such as an enabled web server that can be cracked with just a malformed request, make such blocking a godsend to those of us who have to pick up the pieces. I remember looking at my Linux server log files as millions of requests from hapless CodeRed and Nimda infected systems scrolled by.

It shouldn't be too hard to configure routers to reject unsolicited packets, as NAT does now, without that address translation.

Having every system direct reachable again, in theory anyway, will certainly require better default settings on commodity software.

Thanks for helping me get my second IPv6 tunnel up.

[BobRobertson]

Well, sadly, I've had to disable the DMZ setting in my budget router.

The unsolicited traffic from my idiot service provider was slowing down my local network.

So unless I can find someone who has enabled a tunnel through a budget NAT router, I'm SOL and will have to give up on IPv6 for the forseeable future.

[bombcar]

If my VoIP phone service worked through a Linux box acting as a router, I wouldn't have this problem. But Noooooo.

This should work. I mean, the Linux box can (like zombo.com) do anything with networks, so you should be able to get it to work.

Do you have hardware you could run m0n0wall on?