Port forwarding on Spark wireless LAN

Forums › Spark New Zealand (including Skinny and BigPipe) › Port forwarding on Spark wireless LAN

1 | 2

batdan

79 posts

Master Geek

ID Verified

#2308868 31-Aug-2019 19:31

Petenz:
I have also discovered that PiAware cannot connect to Flightaware and is thus down the drain along with PlanePlotter now that I am on Spark wireless Broadband.

I run piaware on Skinny 4g broadband with CGNAT. Works fine. Does not require port forwarding as just uploads data.

Wise

Send money globally for less with Wise - one free transfer up to NZ$900 (affiliate link).

cyril7

9050 posts

Uber Geek

ID Verified

Trusted

Subscriber

#2308891 31-Aug-2019 20:21

Hi, just done a bit of reading on Flightaware, there seems absolutely no requirement for port forwarding, if so it should work fine from behind CG-NAT.......ymmv

Cyril

Oblivian

7276 posts

Uber Geek

ID Verified

#2308909 31-Aug-2019 22:36

If users have it on CG-NAT now, it would be needed to check if the servers MLAT data being fed back is on your local map (most people wouldn't bother and just rely on their data going out to get upgraded accounts)

It isn't clear if it is coming in via the 2-way link it starts up with FA, or establishes separate inbound. Quite possibly on the same datastream as I don't currently have a pinhole (like you suggest) and get results.

FR24 - your data goes out, MLAT is shown on the web only. Flightaware - your data is sent, they combine and calculate it and send results straight back.

By default, multilateration positions resulting from the data that you feed to FlightAware are returned to you by sending them to the local dump1090 process on port 30104; dump1090 will then include them on the web map it generates.

Planeplotter, does need inbound traffic (UDP 9742) if you wish to see similar MLAT raw results, or get Master User status and assist with generating them

Their system isn't as smart and needs it's own inbound stream

cyril7

9050 posts

Uber Geek

ID Verified

Trusted

Subscriber

#2308954 1-Sep-2019 08:35

So the following image shows the faup1090 process creates one outbound connection, and the fa-mlat-client creates an outbound connection 30005 and it would appear return traffic is on the same port or possibly 30104 which I assume the client opens to the server for it to return traffic on. ie all are outbound connections, ie no pinhole required, well thats how I read it, I could be wrong.

This is a client/server setup, it would be very poor engineering if the server required the client open inbound connections from it, surely the client initiates and creates all channels required.

Cyril

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#2308958 1-Sep-2019 09:24

When I look at that very same image I can't see any requirement for a port forward. It shows two way traffic over the same socket for MLAT traffic to and from the FA server.

That would be an incredibly sloppy design.

It's safe to say most people don't realise the security implications of port forwards.

I know @scottjpalmer has been feeding FR24 and FA for ages using CG-NAT, he might be able to offer some advice.

Oblivian

7276 posts

Uber Geek

ID Verified

#2308962 1-Sep-2019 09:42

Ok, so looks like the 2way data from Fa sorted. And somewhat established

I too have been feeding all of them since about 2010

Those 2 are very unlikely to see an issue. As I say most tend to be used out only anyway. And more use them than planeplotter

Planeplotter however, has a specific inbound test performed as part of it's setup checks to grant the ground station status that would likely fail.

But again, it's not a feature everyone takes advantage of.

cyril7

9050 posts

Uber Geek

ID Verified

Trusted

Subscriber

#2308967 1-Sep-2019 09:59

So only other thought I had is do the servers require you register your public IP with them (be it your real local one or the CG-NAT routers gateway) to let you through there firewall, this would explain why the OP might have been having issues, but not being a user of this service I cannot comment further.

Cyril

Oblivian

7276 posts

Uber Geek

ID Verified

#2308968 1-Sep-2019 10:03

Basically this, doesn't occur without one. It is a web-generated test that tells the server to try connect

I believe the MLAT/Raw data results server is different from the one you upload to. But it uses your connection to get the return IP and establish inbound on it

But the only advserse effect you would see, was no localised MLAT results (most tracking sites will do this now anyway) and can't use your data to help the others around you be more precise

cyril7

9050 posts

Uber Geek

ID Verified

Trusted

Subscriber

#2308978 1-Sep-2019 11:06

Hi so what you are saying is with newer servers its not required, so will work 100% without the port forwarding and or CG-NAT.

I recommend that if you Do require port forwarding and you know the server IP that will be using it then firewall the port forward to just that IP, if your router does not support that filtering then you are using the wrong device.

Cyril

Oblivian

7276 posts

Uber Geek

ID Verified

#2308985 1-Sep-2019 11:38

cyril7: Hi so what you are saying is with newer servers its not required, so will work 100% without the port forwarding and or CG-NAT.

I recommend that if you Do require port forwarding and you know the server IP that will be using it then firewall the port forward to just that IP, if your router does not support that filtering then you are using the wrong device.

Cyril

More, the chap who does planeplotter hasn't seem to considered public IPs disappearing. And as such his peer2peer / 2 source connection requirements implemented (1 server receive/send data and a 2nd separate MLAT results server or near neighbour direct) are going to bite anyone on CGNathat wish to use those
MLAT functions

(The planeplotter server so kindly offers others your IP as a source for data too to allow somewhat of a mesh calculation :/)

Whereas flightaware has taken care of it with sending the different MLAT data back down the same single connection you make.

In short. OP shouldn't see any change In operation. Other than noone will be able to use his data directly, and likely won't be able to calculate mlat targets within the planeplotter screen.

Anything out side of that is likely coincidental as I see no reason for it not to work. Planeplotter is the only odd one that needs open inbound

cyril7

9050 posts

Uber Geek

ID Verified

Trusted

Subscriber

#2308988 1-Sep-2019 11:49

Hi, if you do happen to enage with the flightawre developers I suggest you advise them to redesign both in the interest of security and with the increasing CG-NAT situation.

Also would it not make sense that data you forward to their servers, you can elect if this is forwarded to others, but not from you but from the server, surely a better engineered solution.

Cyril

Oblivian

7276 posts

Uber Geek

ID Verified

#2308990 1-Sep-2019 12:01

cyril7:
Hi, if you do happen to enage with the flightawre developers I suggest you advise them to redesign both in the interest of security and with the increasing CG-NAT situation.

Also would it not make sense that data you forward to their servers, you can elect if this is forwarded to others, but not from you but from the server, surely a better engineered solution

Flightaware is fine. It's all server side. And the data uses a sngle stream that we establish. Not the issue here.

Planeplotter is, and that spawned his later concerns of potential for flightaware to be the same. But now identified as fine/out only.

Planeplotter is the bugbear. And it is opt-in somewhat. As part of the request to enable the master user/ground station status.

Explained under security considerations http://www.coaa.co.uk/multilat.pdf

BarTender

3587 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#2308993 1-Sep-2019 12:04

Static IP on Wireless Broadband has been available for at almost 2 years since around November/December 2017 since that was when I built it. 😁

You have a Static IP address in the same range as the current Fixed Broadband Static IPs as your Wireless session gets terminated on the same BNGs that terminate fixed broadband and it gets terminated exactly the same way BUBA customers get terminated for the moment.

But I personally would recommend against getting a Static IP on Wireless Broadband unless you absolutely need it as if you get DDoSed there isn't much you can do to stop it plus there is a constant stream of background noise on the internet all of which you will go against your data cap. I remember there wasn't an easy way to flick between static and dynamic much like there is on fixed broadband putting in the username "NoStatic".

1 | 2