TCP Mux port open

Hello, even though i have a firewall rule to drop the new incoming packets from outside wan, and ping rule disabled, when i run the GRC shields up it shows port 1 (TCP Mux) to be blocked only (not stealth).
Why is it showing port 1 to be blocked, while others are stealth.

Long story:
i was just installing internet to flat after restoration and i chosen the Omnia router (instead an older cisco 7301 which was there previously as this flat will not longer be joined to my DMVPN), and when i ran the GRC Shields Up it showed all ports are blocked(blue) (not stealth…) and ping was allowed. so i went to luci and changed the reject for incoming traffic to a drop, and disabled the ping rule. After that the GRC showed all ports as stealth and ping was unsuccessfull. So far everything good and as expected.
I think this is on turris OS v3. have to confirm.

Then i remember that on another flat i have also omnia installed (one of the units from early bidders indiegogo campaign) where i have not run the shields up. So i have run also GRC shields up from that router and it also showed that all ports are blocked only and ping allowed. So i made the same changes (to change it to drop and disable the ping rule), but the grc shields up are still showing port 1, TCP Mux as blocked only, not stealth. other ports are stealth and ping is unsuccessful.

I did not understand why it may show up, and i did not really had time to investigate, so i rather reflashed the router with latest medkit from hbs branch and configured it from scratch. Of course after completing the configuration guide the GRC shields up was showing as blocked only and ping allowed. so again i made changes to drop and disabled ping rule. but again the same problem the port 1 shows as blocked only instead of stealth. It seems strange to me.
Anybody care to elaborate what might be causing this ?

Both “sites” have same ISP and reserved static public IP via NAT 1:1 and the config is pretty bare bone, nothing fancy on those two sites.

How do you make these changes?

through the luci interface. As Foris ui does not have firewall manipulation.
This:

Changed both Reject to Drop.

You realize that that dropping packets still gives a different response as a non-existent device? IMHO “stealth” mode is not really adding security over rejecting (as an offender will still easily figure out that there is a machine connected). So unless generating the rejection responses puts a noticeable load on te router, why bother with dropping? Same for ICMP echo requests, if you are under attack, by all means shut this off, otherwise it can be used quite effectively for remote monitoring from services like dslreports smokepink/line monitoring or thinkbroadband’s “Broadband Quality Monitoring” or even OpenWrt’s collectd statistics with the ping module (so your different routers ping each other, which probably also requires ddns).
In short, I agree that there are use-cases in which dropping/stealthing and Ping droping seem a good idea, but in general there is little risk in not doing this.

1 Like

That does not reflect on the topic but rather calls into question the merit of dropping packets vs rejection, an age old discussion that leads nowhere.

2 Likes

in principle I agree with you, there are many more ways to detect if there is any device on the line or if it is a dead connection.
I dont want to get sidetracked, if this has any benefits or not, this is not the question. I am glad for your feedback which has its merit , but i am more intrigued by what is causing this.
Its a non standard behavior.

I have configured a lot of routers and firewalls (both for my home, others and in work) based on openwrt previously, even more “profi” ones, like cisco, palo alto, checkpoint, vyos, openbsd(to a degree :slight_smile: ) etc.
This worked like a charm every time as a quick check if everything applied correctly etc before doing more hardening and in some cases pentesting. Just one of many check i would say.

So the question is why not this time. what is the root cause.

The one thing that might explain is, that for some reason a NAT1:1 from ISP on this installation is missing the port 1 in its configuration and its landing on the equipment of the ISP rather than on my router. Which would be quite rare, but not impossible.
i think i am going to play with the tcpdump, if the packet on port 1 actually arrives.

1 Like

Could be that the results are cached somewhere? Using different browsers for the different test locations?

The posted test screen shot also shows port 0 as stealth, which is strange and looks like more of a glitch.

Try other test nodes, e.g. https://www.ipfingerprints.com/portscan.php ?

ok, i have run a tcpdump and the packets are arriving on my router.

First a GRC search only on port 22, 10 packets are recieved. after that GRC shows as “stealth”:

root@turris:~# tcpdump -n -i eth2 port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:06:21.805171 IP 4.79.142.206.53833 > X.X.X.X.22 Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
18:06:22.320479 IP 4.79.142.206.53833 > X.X.X.X.22: Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
18:06:22.820221 IP 4.79.142.206.53833 > X.X.X.X.22: Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
18:06:23.335909 IP 4.79.142.206.53833 > X.X.X.X.22: Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
18:06:23.836093 IP 4.79.142.206.53833 > X.X.X.X.22: Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
18:06:24.351884 IP 4.79.142.206.53833 > X.X.X.X.22: Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
18:06:24.851986 IP 4.79.142.206.53833 > X.X.X.X.22: Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
18:06:25.367869 IP 4.79.142.206.53833 > X.X.X.X.22: Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
18:06:25.867941 IP 4.79.142.206.53833 > X.X.X.X.22: Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
18:06:26.383871 IP 4.79.142.206.53833 > X.X.X.X.22: Flags [S], seq 1889460264, win 8192, options [mss 1460], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
root@turris:~#
root@turris:~#

Second a try only on port 1, only 1 packets recieved. after that GRC shows as “blocked”:

root@turris:~#
root@turris:~# tcpdump -n -i eth2 port 1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:06:46.022343 IP 4.79.142.206.53839 > X.X.X.X.1: Flags [S], seq 3550263260, win 8192, options [mss 1460], length 0
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel
root@turris:~#

when capturing for source:

root@turris:~# tcpdump -n -i eth2 host 4.79.142.206
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:11:43.502374 IP 4.79.142.206 > X.X.X.X.1: ICMP echo request, id 0, seq 0, length 8
18:11:43.510868 IP 4.79.142.206.53878 > X.X.X.X.1: Flags [S], seq 3558747805, win 8192, options [mss 1460], length 0
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@turris:~#

But i still dont see any “reply” packets from my side, the reject should be recorded as an outgoing ICMP or maybe RST correct ?

2019-12-26%2018_22_49-Window

This site reports the port 1 as filtered. And me seeing no outgoing “reply” reject packets.
Shows the same in different browser (where i have never run grc) and incongito mode.
So i guess its as you implied, there is a glitch on GRC site.
Interesting…

Its the first time for me to happen, lets see if i can send this to guys at GRC, if they can shed some light on it, if they do support for their tool.