Re: [nznog] POSTing problems.
(copied back to NZNOG as it is semi-operational and others may be able to chip in)
Sorry Criggie, not certain as I don't know enough about CGN to say. I had just assumed CGNs would would handle non-80/443 TCP traffic! Otherwise you can't get your lulz catz emails without webmail?!
If you're ring-fenced behind http then yeah that's somewhat restrictive.
For what I'm using them for (quick remote tool for 1 person), I just use SSH outbound over a high TCP port into a (free :) EC2 instance that I reactivate when needed. The TCP session is kept alive with a minimal trickle of data until I'm ready to log in over it (Pi just keeps trying periodically if server is down because EC2 instance is paused).
So if they (cell carrier) only pass TCP/80 & 443 (and then probably transparently proxied & sanity-checked for HTTP compliance etc too?!), then no, I think maybe my wee boxes probably wouldn't work behind that. I do trigger a periodic 'call home with stats' poll over https as well, and that would probably get through, but the tunnel itself needs that high TCP port to operate.
I did set them up for IPv6 tunnels concurrent to the v4 ones though, and that can can actually sometimes be quite useful as sometimes one can get in via v6 when one's v4 is down! I don't suppose there is any chance your cell provider does IPv6?
If not then I guess tunnelling over DNS or maybe over HTTP or HTTPS might be the only option to get through that; and if they're mucking with the POSTs then maybe even that couldn't get through!
Pete
On 2/07/2014, at 5:42 PM, Criggie
Pete Mundy wrote, On 02/07/14 15:59:
I find the Raspberry Pi a most excellent tool for this purpose. I config them up to call home & hold a tunnel open through the users inevitable NAT. I post one out to the end user, get them to plug it in where the fault is occurring, and then I log into it though the tunnel and do all the testing and captures remotely. Coupled with capturing tcpdumps on the server's interface itself , this gives full visibility of both ends of the connection (and hence the ability to determine if the packets are coming through uninhibited).
Does this work through carrier grade NAT? I have to come up with a solution for remote access to a cellular site in Brisbane River (its on a pontoon and has no possibility of anything but cellular)
Problem is they get a 100.60.x.x IP address, and it can't use anything but http/https.
So I wonder if openvpn /tcp on port 443 will work. Have you tried this?
-- Criggie
I regularly use OpenVPN on 80/tcp. It's about the only thing I've found that works worldwide ( well, I've not tried China, but it works over the whole of the Americas and Europe ) over wired/wireless/cell, whereas the default 1984/udp is often firewalled. I'll take the tradeoff in performance for connectivity! I'm working on a similar problem and am looking at a CubieTruck based solution, as it also is very easy to add a backup battery to them, and I need a bit of extra grunt. USB Cell sticks are cheap, but soldering on a decent aerial pigtail on can be tricky with old eyes! ( Yeah, I know it's off-topic, but it's the least I can do given the help you're providing me with stuff I don't really understand too well! ) Steve On Thu, 2014-07-03 at 07:04 +1200, Pete Mundy wrote:
(copied back to NZNOG as it is semi-operational and others may be able to chip in)
Sorry Criggie, not certain as I don't know enough about CGN to say. I had just assumed CGNs would would handle non-80/443 TCP traffic! Otherwise you can't get your lulz catz emails without webmail?!
If you're ring-fenced behind http then yeah that's somewhat restrictive.
For what I'm using them for (quick remote tool for 1 person), I just use SSH outbound over a high TCP port into a (free :) EC2 instance that I reactivate when needed. The TCP session is kept alive with a minimal trickle of data until I'm ready to log in over it (Pi just keeps trying periodically if server is down because EC2 instance is paused).
So if they (cell carrier) only pass TCP/80 & 443 (and then probably transparently proxied & sanity-checked for HTTP compliance etc too?!), then no, I think maybe my wee boxes probably wouldn't work behind that. I do trigger a periodic 'call home with stats' poll over https as well, and that would probably get through, but the tunnel itself needs that high TCP port to operate.
I did set them up for IPv6 tunnels concurrent to the v4 ones though, and that can can actually sometimes be quite useful as sometimes one can get in via v6 when one's v4 is down! I don't suppose there is any chance your cell provider does IPv6?
If not then I guess tunnelling over DNS or maybe over HTTP or HTTPS might be the only option to get through that; and if they're mucking with the POSTs then maybe even that couldn't get through!
Pete
On 2/07/2014, at 5:42 PM, Criggie
wrote: Pete Mundy wrote, On 02/07/14 15:59:
I find the Raspberry Pi a most excellent tool for this purpose. I config them up to call home & hold a tunnel open through the users inevitable NAT. I post one out to the end user, get them to plug it in where the fault is occurring, and then I log into it though the tunnel and do all the testing and captures remotely. Coupled with capturing tcpdumps on the server's interface itself , this gives full visibility of both ends of the connection (and hence the ability to determine if the packets are coming through uninhibited).
Does this work through carrier grade NAT? I have to come up with a solution for remote access to a cellular site in Brisbane River (its on a pontoon and has no possibility of anything but cellular)
Problem is they get a 100.60.x.x IP address, and it can't use anything but http/https.
So I wonder if openvpn /tcp on port 443 will work. Have you tried this?
-- Criggie
NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa
It's not that _that_ off topic, is it? You wouldn't want to run your network on them, but these RPi's can still be operationally useful to network engineers (or fire fighters!).
I used a couple of RPis recently to demonstrate an IPv6 routing issue to a large ISP (heya fellas :), and having this sort of visibility was what allowed me to determine that it really was an upstream issue. Having pcaps or traceroutes and ping logs (whatever is suitable for the problem) can help both ends understand the issue clearly from the customers perspective and to get a fix in place more quickly.
Cheap, small & open. A fantastic operational tool for remote diagnosis purposes.
Pete
On 3/07/2014, at 8:19 AM, Steve Holdoway
I regularly use OpenVPN on 80/tcp. It's about the only thing I've found that works worldwide ( well, I've not tried China, but it works over the whole of the Americas and Europe ) over wired/wireless/cell, whereas the default 1984/udp is often firewalled. I'll take the tradeoff in performance for connectivity!
I'm working on a similar problem and am looking at a CubieTruck based solution, as it also is very easy to add a backup battery to them, and I need a bit of extra grunt. USB Cell sticks are cheap, but soldering on a decent aerial pigtail on can be tricky with old eyes!
( Yeah, I know it's off-topic, but it's the least I can do given the help you're providing me with stuff I don't really understand too well! )
Steve
participants (2)
-
Pete Mundy
-
Steve Holdoway