While I was on a cruise recently, I was using the ship's wifi network
(which gets its backhaul via satellite).

My phone and laptop could access most websites, but not ones which used
a non-standard TCP port (ie not 80).

I've set my router at home to use port forwarding, so

WAN_IP:8080 is routed to LAN_IP_1:80
WAN_IP:9981 is routed to LAN_IP_2:80
WAN_IP:8998 is routed to LAN_IP_3:80

I use DDNS to map a network name to the current value of my WAN IP
address, which my ISP changes from time to time.

And any attempt to access WAN_IP:8080 (or any other of the ports that
I'd configured) timed-out.

It looks as if the ship's network configuration was only allowing
traffic to standard ports such as 80 (for web), 25/110/995 (for POP/SMTP
email) and a few others, and blocking everything else.

I ended up connecting to my always-on Raspberry Pi (at home) over VNC
and then using that to access the LAN_IP_n devices (weather station,
PVR, security camera) from within my home LAN. Or else waiting till the
ship was in a port and using my mobile phone's mobile internet. Thank
goodness they allowed VNC access...

Is there anything I could have done differently in my laptop network
configuration such that I could access web sites that didn't use port
80, when their port numbers were (apparently) blocked by the ship's wifi?

Am 22.05.2023 um 01:08:40 Uhr schrieb NY:

> My phone and laptop could access most websites, but not ones which
> used a non-standard TCP port (ie not 80).

An annoying firewall.

> I've set my router at home to use port forwarding, so
>
> WAN_IP:8080 is routed to LAN_IP_1:80
> WAN_IP:9981 is routed to LAN_IP_2:80
> WAN_IP:8998 is routed to LAN_IP_3:80

You could use IPv6, so you can have multiple machines running on TCP
port 80 on an individual global address.

On Mon 22/05/2023 01:08, NY wrote:
> While I was on a cruise recently, I was using the ship's wifi network
> (which gets its backhaul via satellite).
>
> My phone and laptop could access most websites, but not ones which used
> a non-standard TCP port (ie not 80).
>
> I've set my router at home to use port forwarding, so
>
> WAN_IP:8080 is routed to LAN_IP_1:80
> WAN_IP:9981 is routed to LAN_IP_2:80
> WAN_IP:8998 is routed to LAN_IP_3:80
>
> I use DDNS to map a network name to the current value of my WAN IP
> address, which my ISP changes from time to time.
>
> And any attempt to access WAN_IP:8080 (or any other of the ports that
> I'd configured) timed-out.
>
> It looks as if the ship's network configuration was only allowing
> traffic to standard ports such as 80 (for web), 25/110/995 (for POP/SMTP
> email) and a few others, and blocking everything else.
>
>
> I ended up connecting to my always-on Raspberry Pi (at home) over VNC
> and then using that to access the LAN_IP_n devices (weather station,
> PVR, security camera) from within my home LAN. Or else waiting till the
> ship was in a port and using my mobile phone's mobile internet. Thank
> goodness they allowed VNC access...
>
> Is there anything I could have done differently in my laptop network
> configuration such that I could access web sites that didn't use port
> 80, when their port numbers were (apparently) blocked by the ship's wifi?

That is an issue when travelling anywhere. Go to France and you will
find free wi-fi around Tourist Information offices and the local Mairie
(Mayor's) office BUT whilst the former is usually open access the latter
more often than not is supplied by Orange France and they block
everything bar port 80. If you use a mail client, forget it, the only
option is webmail.

Was the ship of French parentage by any chance?

"Woody" <harrogate3@ntlworld.com> wrote in message
news:u4f388$23jfm$1@dont-email.me...
>> Is there anything I could have done differently in my laptop network
>> configuration such that I could access web sites that didn't use port 80,
>> when their port numbers were (apparently) blocked by the ship's wifi?
>
> That is an issue when travelling anywhere. Go to France and you will find
> free wi-fi around Tourist Information offices and the local Mairie
> (Mayor's) office BUT whilst the former is usually open access the latter
> more often than not is supplied by Orange France and they block everything
> bar port 80. If you use a mail client, forget it, the only option is
> webmail.
>
> Was the ship of French parentage by any chance?

No, it was P&O, so *nominally* British. It was fitted with UK 3-pin mains
sockets so it's likely that the firewall would have been configured to UK
specs.

There were several different tariffs of wifi available for purchase on the
ship, and I imagine that the difference was the data-throughput speed and
the TCP ports that were blocked. The Youtube website was accessible but
playing of videos timed-out - not that I'd try to play a video over a slow
laggy connection. On a port-intensive cruise like we were on, there wasn't
too long between being in one port or another and therefore being able to
use mobile internet (with my laptop tethered to my phone).

The other embuggerance with the ship's wifi was that it would only allow one
device at a time to connect to a given user ID, so my wife and I had to kick
each other off the connection. I did take a travel router which I've used in
the past to get round this, but for some reason this time it could not see
the ship's SSID. (*) Maybe the ship have started blocking MAC addresses
which are known to belong to travel routers - is that how MAC-filtering
works, or does the client always see the SSID and only get gets blocked when
it tries to connect?

(*) Every time I scanned for networks, I found that the router (Hootoo) saw
a different subset of the SSIDs that my laptop and phone could see - and
never the passengers' network.

NY wrote:

> Is there anything I could have done differently in my laptop network
> configuration such that I could access web sites that didn't use port
> 80, when their port numbers were (apparently) blocked by the ship's wifi?

Setup your own "road warrior" openVPN at home listening on port TCP/443
and UDP/53 (assuming you don't run a web or DNS server)

Andy Burns <usenet@andyburns.uk> wrote:
> NY wrote:
>
> > Is there anything I could have done differently in my laptop network
> > configuration such that I could access web sites that didn't use port
> > 80, when their port numbers were (apparently) blocked by the ship's wifi?
>
> Setup your own "road warrior" openVPN at home listening on port TCP/443
> and UDP/53 (assuming you don't run a web or DNS server)

Or forward port 443 to a machine that has SSH and then use it as a SOCKS
proxy, where your traffic will emerge from the SSH server:

https://ma.ttias.be/socks-proxy-linux-ssh-bypass-content-filters/

It's not quite as easy to use as OpenVPN (you need to configure each app
that connects separately) but, apart from listening on port 443, there's no
prior setup of the server needed. This will work with any SSH server you
can connect to.

Theo

On 22/05/2023 09:34, NY wrote:
> No, it was P&O, so *nominally* British. It was fitted with UK 3-pin
> mains sockets so it's likely that the firewall would have been
> configured to UK specs.

There are no UK specs for firewalls. We're not a totalitarian
dictatorship like China. Individual business owners and users are
allowed to configure things the way they want.

--
Brian Gregory (in England).

"Brian Gregory" <void-invalid-dead-dontuse@email.invalid> wrote in message
news:kdahmgFg33bU1@mid.individual.net...
> On 22/05/2023 09:34, NY wrote:
>> No, it was P&O, so *nominally* British. It was fitted with UK 3-pin mains
>> sockets so it's likely that the firewall would have been configured to UK
>> specs.
>
> There are no UK specs for firewalls. We're not a totalitarian dictatorship
> like China. Individual business owners and users are allowed to configure
> things the way they want.

True, but any departure from "everything is permitted" needs to be justified
to the satisfaction of the end-user: "Why (*) are not you allowing this port
to be open? Convince me that it is necessary".

(*) And anyone who uses lazy, woolly, imprecise phrases such as "for
security reasons" will die a slow and painful death ;-). Be precise and
specific.

On 26 May 2023 09:41, "NY" wrote:
> "Brian Gregory" <void-invalid-dead-dontuse@email.invalid> wrote in message
> news:kdahmgFg33bU1@mid.individual.net...
>> On 22/05/2023 09:34, NY wrote:
>>> No, it was P&O, so *nominally* British. It was fitted with UK 3-pin mains
>>> sockets so it's likely that the firewall would have been configured to UK
>>> specs.
>>
>> There are no UK specs for firewalls. We're not a totalitarian dictatorship
>> like China. Individual business owners and users are allowed to configure
>> things the way they want.
>
> True, but any departure from "everything is permitted" needs to be justified
> to the satisfaction of the end-user: "Why (*) are not you allowing this port
> to be open? Convince me that it is necessary".
>
>
> (*) And anyone who uses lazy, woolly, imprecise phrases such as "for
> security reasons" will die a slow and painful death ;-). Be precise and
> specific.

Firewalls should start "all blocked" and then holes made where
necessary.

>> Is there anything I could have done differently in my laptop network
>> configuration such that I could access web sites that didn't use port
>> 80, when their port numbers were (apparently) blocked by the ship's wifi?
>
> That is an issue when travelling anywhere. Go to France and you will
> find free wi-fi around Tourist Information offices and the local Mairie
> (Mayor's) office BUT whilst the former is usually open access the latter
> more often than not is supplied by Orange France and they block
> everything bar port 80. If you use a mail client, forget it, the only
> option is webmail.
>
> Was the ship of French parentage by any chance?

Using a VPN should get you around that sort of problem.

"Jason H" <DarthPiriteze@deathstar.gal> wrote in message
news:u5028s$v28e$2@dont-email.me...
>
>>> Is there anything I could have done differently in my laptop network
>>> configuration such that I could access web sites that didn't use port
>>> 80, when their port numbers were (apparently) blocked by the ship's
>>> wifi?
>>
>> That is an issue when travelling anywhere. Go to France and you will find
>> free wi-fi around Tourist Information offices and the local Mairie
>> (Mayor's) office BUT whilst the former is usually open access the latter
>> more often than not is supplied by Orange France and they block
>> everything bar port 80. If you use a mail client, forget it, the only
>> option is webmail.
>>
>> Was the ship of French parentage by any chance?
>
> Using a VPN should get you around that sort of problem.

Is it possible for a firewall to block traffic to/from a VPN while allowing
through direct traffic to a port-80 website? I wouldn't put it past P&O to
block VPN traffic. I imagine one reason for a tightly-locked firewall is
that they don't want people streaming high-bandwidth data such as films. I
noticed that although the Youtube website would open, it wasn't possible to
play a Youtube video that was displayed as a thumbnail. Not that I wanted
to, but I was experimenting in an idle moment to see what I was and wasn't
allowed to do. ;-)

The inability to access a non-port-80 website (my Raspberry Pi PVR at home
via port-forwarding on my router) was frustrating. I decided to record the
Coronation in HD rather than the SD recording I'd set before we left home.
Blocked :-( But a bit of lateral thinking worked: connect to the Pi by Real
VPN (thank goodness that worked) and then open up a browser on the Pi which
accessed the PVR software on the Pi's port 9981. Easy peasy, once I'd worked
out a workaround. I could have waited a day or so until we were in port and
I could access the internet by mobile phone rather than by ship's firewalled
wifi.

NY <me@privacy.invalid> wrote:
> Is it possible for a firewall to block traffic to/from a VPN while allowing
> through direct traffic to a port-80 website?

It depends on the type of VPN and which protocols it uses, but yes it's
common to block anything that doesn't go to a handful of TCP ports - 80
(http), 443 (https), 143 (imap), etc.

That's why a counter-move is to run your VPN server on TCP port 443, where
it looks a lot like https unless somebody is doing deep packet inspection.
That only works with VPN protocols that are happy to use TCP - eg OpenVPN.
Other VPNs use UDP or GRE (a separate protocol over IP than TCP or UDP).

Theo

On 30 May 2023 19:15:08 +0100 (BST), Theo wrote:
> NY <me@privacy.invalid> wrote:
>> Is it possible for a firewall to block traffic to/from a VPN while allowing
>> through direct traffic to a port-80 website?
>
> It depends on the type of VPN and which protocols it uses, but yes it's
> common to block anything that doesn't go to a handful of TCP ports - 80
> (http), 443 (https), 143 (imap), etc.
>
> That's why a counter-move is to run your VPN server on TCP port 443, where
> it looks a lot like https unless somebody is doing deep packet inspection.
> That only works with VPN protocols that are happy to use TCP - eg OpenVPN.
> Other VPNs use UDP or GRE (a separate protocol over IP than TCP or UDP).

A modern firewall can do more than check the port. It can check the
traffic, too. In which case using Port 80 for something that isn't HTTP
might still get blocked. It doesn't have to be DPI.

Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
> A modern firewall can do more than check the port. It can check the
> traffic, too. In which case using Port 80 for something that isn't HTTP
> might still get blocked. It doesn't have to be DPI.

I thought that was harder for 443, because HTTPS is mostly encrypted TLS.?
If you do DPI you can tell something about the encryption (eg whether SNI is
used in the TLS request), but if you are doing basic firewalling it just
looks like TLS. So if you choose to run a different protocol over TLS
(such as OpenVPN) the firewall can't tell.

Obviously running non-HTTP traffic over port 80 can be spotted a mile off,
but I thought with 443 it was more difficult?

Theo

Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
> On 30 May 2023 19:15:08 +0100 (BST), Theo wrote:
> > NY <me@privacy.invalid> wrote:
> >> Is it possible for a firewall to block traffic to/from a VPN while allowing
> >> through direct traffic to a port-80 website?
> >
> > It depends on the type of VPN and which protocols it uses, but yes it's
> > common to block anything that doesn't go to a handful of TCP ports - 80
> > (http), 443 (https), 143 (imap), etc.
> >
> > That's why a counter-move is to run your VPN server on TCP port 443, where
> > it looks a lot like https unless somebody is doing deep packet inspection.
> > That only works with VPN protocols that are happy to use TCP - eg OpenVPN.
> > Other VPNs use UDP or GRE (a separate protocol over IP than TCP or UDP).
>
> A modern firewall can do more than check the port. It can check the
> traffic, too. In which case using Port 80 for something that isn't HTTP
> might still get blocked. It doesn't have to be DPI.
>
So would it block *anything* that was encrypted? Surely encrypted
data can't be subject to analysis so how can a "modern firewall" (or
anything else for that matter) check the traffic? I suppose it could
block anything encrypted on port 80 on the basis that it should be
HTTP and thus not encrypted but I really don't see any way to block
port 443 (for example) using traffic analysis.

--
Chris Green
·

On 1 Jun 2023 12:20, Chris Green wrote:
> Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
>> On 30 May 2023 19:15:08 +0100 (BST), Theo wrote:
>> > NY <me@privacy.invalid> wrote:
>> >> Is it possible for a firewall to block traffic to/from a VPN while allowing
>> >> through direct traffic to a port-80 website?
>> >
>> > It depends on the type of VPN and which protocols it uses, but yes it's
>> > common to block anything that doesn't go to a handful of TCP ports - 80
>> > (http), 443 (https), 143 (imap), etc.
>> >
>> > That's why a counter-move is to run your VPN server on TCP port 443, where
>> > it looks a lot like https unless somebody is doing deep packet inspection.
>> > That only works with VPN protocols that are happy to use TCP - eg OpenVPN.
>> > Other VPNs use UDP or GRE (a separate protocol over IP than TCP or UDP).
>>
>> A modern firewall can do more than check the port. It can check the
>> traffic, too. In which case using Port 80 for something that isn't HTTP
>> might still get blocked. It doesn't have to be DPI.
>>
> So would it block *anything* that was encrypted? Surely encrypted
> data can't be subject to analysis so how can a "modern firewall" (or
> anything else for that matter) check the traffic? I suppose it could
> block anything encrypted on port 80 on the basis that it should be
> HTTP and thus not encrypted but I really don't see any way to block
> port 443 (for example) using traffic analysis.

Traffic analysis (sigint) has developed rather well. So, for example,
you can describe a flow as being for OneDrive and, without decrypting,
you can develop a degree of confidence that it is, in general, being
used just for that. In Palo Alto speak it is called APPID.

Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
> On 1 Jun 2023 12:20, Chris Green wrote:
> > Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
> >> On 30 May 2023 19:15:08 +0100 (BST), Theo wrote:
> >> > NY <me@privacy.invalid> wrote:
> >> >> Is it possible for a firewall to block traffic to/from a VPN while allowing
> >> >> through direct traffic to a port-80 website?
> >> >
> >> > It depends on the type of VPN and which protocols it uses, but yes it's
> >> > common to block anything that doesn't go to a handful of TCP ports - 80
> >> > (http), 443 (https), 143 (imap), etc.
> >> >
> >> > That's why a counter-move is to run your VPN server on TCP port 443, where
> >> > it looks a lot like https unless somebody is doing deep packet inspection.
> >> > That only works with VPN protocols that are happy to use TCP - eg OpenVPN.
> >> > Other VPNs use UDP or GRE (a separate protocol over IP than TCP or UDP).
> >>
> >> A modern firewall can do more than check the port. It can check the
> >> traffic, too. In which case using Port 80 for something that isn't HTTP
> >> might still get blocked. It doesn't have to be DPI.
> >>
> > So would it block *anything* that was encrypted? Surely encrypted
> > data can't be subject to analysis so how can a "modern firewall" (or
> > anything else for that matter) check the traffic? I suppose it could
> > block anything encrypted on port 80 on the basis that it should be
> > HTTP and thus not encrypted but I really don't see any way to block
> > port 443 (for example) using traffic analysis.
>
> Traffic analysis (sigint) has developed rather well. So, for example,
> you can describe a flow as being for OneDrive and, without decrypting,
> you can develop a degree of confidence that it is, in general, being
> used just for that. In Palo Alto speak it is called APPID.
>
Silly game! :-)

Surely the encrypters will soon start chopping up the data into
different sized bits such that they won't look like something they are
(or not).

There's not much you can do by analysing an encrypted data stream
except look at the chunks it's in. Anything else would depend on how
it has been encrypted and although you might try and guess at that
it's no more than a guess.

--
Chris Green
·

On 2 Jun 2023 19:59, Chris Green wrote:
> Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
>> On 1 Jun 2023 12:20, Chris Green wrote:
>> > Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
>> >> On 30 May 2023 19:15:08 +0100 (BST), Theo wrote:
>> >> > NY <me@privacy.invalid> wrote:
>> >> >> Is it possible for a firewall to block traffic to/from a VPN while allowing
>> >> >> through direct traffic to a port-80 website?
>> >> >
>> >> > It depends on the type of VPN and which protocols it uses, but yes it's
>> >> > common to block anything that doesn't go to a handful of TCP ports - 80
>> >> > (http), 443 (https), 143 (imap), etc.
>> >> >
>> >> > That's why a counter-move is to run your VPN server on TCP port 443, where
>> >> > it looks a lot like https unless somebody is doing deep packet inspection.
>> >> > That only works with VPN protocols that are happy to use TCP - eg OpenVPN.
>> >> > Other VPNs use UDP or GRE (a separate protocol over IP than TCP or UDP).
>> >>
>> >> A modern firewall can do more than check the port. It can check the
>> >> traffic, too. In which case using Port 80 for something that isn't HTTP
>> >> might still get blocked. It doesn't have to be DPI.
>> >>
>> > So would it block *anything* that was encrypted? Surely encrypted
>> > data can't be subject to analysis so how can a "modern firewall" (or
>> > anything else for that matter) check the traffic? I suppose it could
>> > block anything encrypted on port 80 on the basis that it should be
>> > HTTP and thus not encrypted but I really don't see any way to block
>> > port 443 (for example) using traffic analysis.
>>
>> Traffic analysis (sigint) has developed rather well. So, for example,
>> you can describe a flow as being for OneDrive and, without decrypting,
>> you can develop a degree of confidence that it is, in general, being
>> used just for that. In Palo Alto speak it is called APPID.
>>
> Silly game! :-)
>
> Surely the encrypters will soon start chopping up the data into
> different sized bits such that they won't look like something they are
> (or not).
>
> There's not much you can do by analysing an encrypted data stream
> except look at the chunks it's in. Anything else would depend on how
> it has been encrypted and although you might try and guess at that
> it's no more than a guess.

Most encryption passing gateways is application-level (e.g. M365) which
is entirely amenable to this approach. There is more fingerprinting
available than you might think. Worth looking at some white papers.

Yes, VPNs of the sort being talked about here are different but then,
back to the original post, I imagine the CSP (the ship operators in
this case) probably want to stop VPNs to enable them to manage their
costs and obligations well

Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
> On 2 Jun 2023 19:59, Chris Green wrote:
> > Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
> >> On 1 Jun 2023 12:20, Chris Green wrote:
> >> > Rupert Moss-Eccardt <nin@moss-eccardt.com> wrote:
> >> >> On 30 May 2023 19:15:08 +0100 (BST), Theo wrote:
> >> >> > NY <me@privacy.invalid> wrote:
> >> >> >> Is it possible for a firewall to block traffic to/from a VPN while allowing
> >> >> >> through direct traffic to a port-80 website?
> >> >> >
> >> >> > It depends on the type of VPN and which protocols it uses, but yes it's
> >> >> > common to block anything that doesn't go to a handful of TCP ports - 80
> >> >> > (http), 443 (https), 143 (imap), etc.
> >> >> >
> >> >> > That's why a counter-move is to run your VPN server on TCP port 443, where
> >> >> > it looks a lot like https unless somebody is doing deep packet inspection.
> >> >> > That only works with VPN protocols that are happy to use TCP - eg OpenVPN.
> >> >> > Other VPNs use UDP or GRE (a separate protocol over IP than TCP or UDP).
> >> >>
> >> >> A modern firewall can do more than check the port. It can check the
> >> >> traffic, too. In which case using Port 80 for something that isn't HTTP
> >> >> might still get blocked. It doesn't have to be DPI.
> >> >>
> >> > So would it block *anything* that was encrypted? Surely encrypted
> >> > data can't be subject to analysis so how can a "modern firewall" (or
> >> > anything else for that matter) check the traffic? I suppose it could
> >> > block anything encrypted on port 80 on the basis that it should be
> >> > HTTP and thus not encrypted but I really don't see any way to block
> >> > port 443 (for example) using traffic analysis.
> >>
> >> Traffic analysis (sigint) has developed rather well. So, for example,
> >> you can describe a flow as being for OneDrive and, without decrypting,
> >> you can develop a degree of confidence that it is, in general, being
> >> used just for that. In Palo Alto speak it is called APPID.
> >>
> > Silly game! :-)
> >
> > Surely the encrypters will soon start chopping up the data into
> > different sized bits such that they won't look like something they are
> > (or not).
> >
> > There's not much you can do by analysing an encrypted data stream
> > except look at the chunks it's in. Anything else would depend on how
> > it has been encrypted and although you might try and guess at that
> > it's no more than a guess.
>
> Most encryption passing gateways is application-level (e.g. M365) which
> is entirely amenable to this approach. There is more fingerprinting
> available than you might think. Worth looking at some white papers.
>
> Yes, VPNs of the sort being talked about here are different but then,
> back to the original post, I imagine the CSP (the ship operators in
> this case) probably want to stop VPNs to enable them to manage their
> costs and obligations well
>
My approach is usually to use an end-to-end ssh tunnel which I think
is probably as difficult to analyse as a VPN.

--
Chris Green
·