|
Re-establishing static tunnel
![[gb]](/s/countries/gb.gif) Shadow Hawkins on Saturday, 02 February 2013 19:25:05
I opted for a static tunnel, as I have an always-on static IP4 connection.
It works great unless my IP4 connection gets interrupted - I lose all IPv6 connectivity for an indeterminate amount of time.
My live tunnel stats say that the tunnel is up - but I cannot ping the IPv6 endpoint. I try dropping and upping the tunnel my-end but it makes no difference.
Is there anyway I can force it to re-establish on demand, or is it just a case of waiting until the PoP does something to get it working again?
Re-establishing static tunnel
It works great unless my IP4 connection gets interrupted
How does your IPv4 connectivity get "interrupted"?
My live tunnel stats say that the tunnel is up
From which information do you deduce it is 'up'?
- but I cannot ping the IPv6 endpoint.
Do the live tunnel statistics show packets arriving at the PoP? Does tcpdump show packets going out and back in again? What does your configuration look like, did you tcpdump? (And the other questions from the "Reporting Problems Checklist" on the contact page)
Is there anyway I can force it to re-establish on demand, or is it just a case of waiting until the PoP does something to get it working again?
The PoP is effectively static in configuration (except for port/IP changes in case of heartbeat and AYIYA tunnels).
Re-establishing static tunnel
Shadow Hawkins on Saturday, 02 February 2013 23:12:45How does your IPv4 connectivity get "interrupted"? e.g. I unplug/reboot the router or such
From which information do you deduce it is 'up'?
The "Live Tunnel Status" page on the Sixxs web-site tells me that the tunnel state is "up". The same page gives me last five minutes of activity being flat-lined.
I haven't done a tcpdump, but I will do the next time it happens.
I get the impression that it's the IP4 bit that doesn't come back immediately - I will look deeper into this too.
I assume from your reply, the answer to my question is no, there isn't a method to force the tunnel to re-establish from the client end.
Re-establishing static tunnel
Shadow Hawkins on Saturday, 02 February 2013 23:18:46
As an indicator of times - the last IPv6 ping request I received was at 15:53, about the time my IP4 connection was interrupted. I then started to receive them again at 20:45. I was having dinner at this time so it wasn't anything I did to spring it back into life.
Re-establishing static tunnel
e.g. I unplug/reboot the router or such
Your "router", is that a NAT? How is it connected?
The "Live Tunnel Status" page on the Sixxs web-site tells me that the tunnel state is "up".
That "up" is always the case because that is the configured state, it is no indication of liveliness though.
The same page gives me last five minutes of activity being flat-lined.
Because then it is not receiving/sending packets.
I get the impression that it's the IP4 bit that doesn't come back immediately - I will look deeper into this too.
That is likely the case, and depending on your "router" that is likely what it is (I am guessing that your 'router' is a NAT, and that until you send a protocol-41 packet outbound it won't work)
there isn't a method to force the tunnel to re-establish from the client end.
Protocol 41 tunnels (static tunnels) are very very stupid and simple. They just send packets.
If intermediary devices block the sending or receiving of packets then it does not work.
tcpdump or wireshark is your friend here to determine what goes on.
You can check the live tunnel status to see if the PoP received packets.
Re-establishing static tunnel
Shadow Hawkins on Sunday, 03 February 2013 18:52:09
Thanks for the tips, I'll try and hunt down with tcpdump.
Yes, I have a NAT router that passes protocol-41 through to a Linux box that has the tunnel configured on it.
Re-establishing static tunnel
Shadow Hawkins on Sunday, 03 February 2013 23:27:43I have a NAT router that passes protocol-41 through to a Linux box that has the tunnel configured on it.
Does this router have anything configured to forward stuff to your Linux host (in a DMZ maybe)?
If not then it is relying on your Linux host generating traffic to create a temporary hole in the firewall to permit return traffic. Once this times out then no tunnel traffic from the WAN side will make it through to your Linux box until it generates more traffic to re-open that hole.
From my experience if you have your tunnel endpoint behind a NAT then you are better off using AYIYA.
Re-establishing static tunnel
Shadow Hawkins on Sunday, 03 February 2013 23:29:39
Finally figured it with tcpdump. Whilst I had a DNAT rule setup for the inbound tunnel I didn't have a SNAT rule for outgoing data - and as I'm using an external IP4 address that is not the default for my router the connections would have been appearing from the incorrect source at the PoP.
My main stumbling block after figuring out this was that I needed to get the SNAT rule added in before the connection came online as the default NAT got established first.
Anybody else getting stuck on this you need to add something along the lines of:
iptables -t nat -I POSTROUTING -o eth1 -p 41 -J SNAT --to-source <PoP IP4>
And ensure that you apply that on startup and not after traffic has started floating around.
Re-establishing static tunnel
Great that you figured out what went wrong.
the connections would have been appearing from the incorrect source at the PoP.
Actually, I sincerely hope your ISP would simply have dropped or at least rejected those packets before sending them on the Internet. Then again BCP38 is apparently a hard thing to implement for some ISPs.
Anybody else getting stuck on this you need to add something along the lines of:
Actually, in most "DMZ" cases you simply configure the local endpoint of the tunnel to the RFC1918 address you use and the remote to the that of the PoP. The NAT box will then replace the RFC1918 address.
I am wondering a little bit why you think that you need to do NAT on a box behind a NAT.
(Unless your NAT is really stupid and acts as a half-bridge mode when set to DMZ mode, but in that case you should just set it to bridge and hang all your own clients behind your box and let that NAT, which will likely give much better results)
Re-establishing static tunnel
Shadow Hawkins on Monday, 04 February 2013 13:52:26
The reason I NAT is because I don't use a DMZ, being a small home network it's a little overkill.
Re-establishing static tunnel
The question is not why you NAT, it is why you have a box (likely ISP provided, what you call 'router') which does NAT, and then have also the host that terminates your tunnel have to perform NAT.
Note that "DMZ mode" is the configuration option that typically allows protocol-41 to work behind a NAT as then the NAT box forwards all 'unknown' packets to that inside mode. Typically this "DMZ" has nothing to do with a real DMZ though... (long live vendors and home equipment confusing the real naming schemes).
Re-establishing static tunnel
Shadow Hawkins on Monday, 04 February 2013 16:29:54
In a word, flexibility. I have a VM that deals with networking things like DHCP, DNS etc. It runs up-to-date kernels and such, where my Internet router is just an off-the-shelf unit that has limited functionality.
Re-establishing static tunnel
But you do not need to NAT behind a NAT as the NAT already NATs... hence you don't need to do DNAT/SNAT there.... (unless your 'router' is horribly broken NAT-wise)
Re-establishing static tunnel
Shadow Hawkins on Tuesday, 05 February 2013 09:14:44
Ah, sorry, no all NATing is being done on the Internet router, not the termination point of the tunnel. Yes, a NAT after a NAT would indeed get a bit convoluted.
Re-establishing static tunnel
Then why do you have to do the following? As quoted from a message above....
Anybody else getting stuck on this you need to add something along the lines of:
iptables -t nat -I POSTROUTING -o eth1 -p 41 -J SNAT --to-source <PoP IP4>
Note that a SNAT rule is a form of NAT...
Re-establishing static tunnel
Shadow Hawkins on Tuesday, 05 February 2013 12:45:31
That command is on the internet router, not the tunnel end-point.
Re-establishing static tunnel
Ah, now it starts to become a bit clearer, thus the setup you have is something like:
{{ network_one } -> { Linux with NAT } -------------> Internet
^
|
{ network_two } -> { Linux with Tunnel }
(I assume you have a 'network_one', but you stated you had no DMZ, while that would be exactly that)
And apparently, the Linux with NAT is not doing NAT for every packet, which was your issue.
The big confusion comes from the point that normally people would terminate the tunnel directly on the "Linux with NAT" if they are able to do that, and typically have not a Linux box they can control there but a ISP supplied NAT box that they have little control about.
Re-establishing static tunnel
Shadow Hawkins on Tuesday, 05 February 2013 16:23:10
Hope this works... (oh for preview or edit):
{ DD-WRT with NAT } { Linux with tun }
Internet <---> wan0 <-- * --> eth0
|-> wan0:1 <-- p41 --> eth0 <-> tun0
|-> wan0:2, etc...
I have a limited router with DD-WRT running on it, so limited amount of Linux. This connects to the Internet with the WAN interface. I have a block of IP4 addresses, so it also handles traffic for these IPs too.
My SixXS tunnel is just on my LAN.
Normally a single NAT on DD-WRT would be fine - but, I am not using the default WAN address for my tunnel, so outgoing traffic along the tunnel, by default, appears to be coming from wan0, and not the address I configured my tunnel with.
So my issue was I had to add a second SNAT to masquerade the outgoing packets correctly.
The reason why this was difficult to identify was when tunnel data came in initially the DD-WRT box would track the connection and maintain the NAT in both directions. But, if I sent the first tunnel packet going out, there would be no connection tracking at this point so get the default WAN address.
The extra SNAT rule I put in on DD-WRT meant that the correct WAN IP would be used in this scenario.
Re-establishing static tunnel
Thanks for the explanation, now I see why you have to do odd things to keep this going.
|
![[ch]](/s/countries/ch.gif)
on Saturday, 02 February 2013 20:23:40
Posting is only allowed when you are