Scanning for open ports on my crap ISP, anyone got any ideas?

Hey fellas

I've got an internet connection with a (static) public ip, but all the incoming ports I've tried are blocked so I can't tunnel in to my home when I'm out. It's not the router config because it works when I am on the LAN side and connect to the WAN ip.

Before giving up I'd love to scan more of the ports. I have a port scanner app on my phone that works great.

I just need to prepare my openwrt router to actually listen on all ports so I can run the scanner.

What's the easiest way for me to do that? I tried this in iptables but I didn't get far.

iptables -t nat -A PREROUTING -i eth0.2 -p udp --dport 1000:65000 -j DNAT --to-destination :61002

I'm trying to get the wan interface to forward all incoming ports to a port I know is open on the router. (port 61002)

Do I need to use TCP for a port scanner? I'm doing something wrong. Is there perhaps some sort of debug flag I can tick in Openwrt to listen to all ports temporarily?

Thanks!

PS. I'm trying to direct connect. I have no problem to connect through an intermediary like Softether/Zerotier etc. Problem is, performance takes a big hit.

You can't test wan connectivity from lan, it'll give you false positives.
Here's another user who thought he could User misconfiguration keeps port 53 open on the wan interface

Tcpdump, add the public ip of your cell phone, as filter, to minimize the amount of data collected.

4 Likes

Thank you frollic. Always friendly. Much appreciated.

I didn't only do that. Of course I tried from the outside (cellular). From the outside everything tested looks closed.

It's like I'm a rookie, but I've configured a few dozen OpenWRT devices to allow incoming connections. It's like there's a firewall between the client and the internet, while still having a public ip.

I want to probe for open ports.

One idea was to try udp connections because I read there no "source" header so they're less distinguishable between incoming and outgoing. Still no go. Incoming connections are not allowed. I'd like to test a greater range of ports.

if you scanned the (non standard, I assume) ports, and they all came back closed, they're probably blocked by your ISP. but then I'd ask myself, why provide a public IP, in the 1st place ...

I also assume the wan IP of your openwrt device matches the IP given by any random whatsmyip site out there ?

post your /etc/config/firewall file

1 Like

Yes, very unusual indeed. (I can see the same static ip on whatsmyip.com, yes.) I tried DHCP too and I get a private IP. I tried to run a upnpc port open request on it but it can't find an IGD device.

Ok, I'll post it. Just a moment.

Nope, UDP still uses unambiguous source and destination IP addresses and ports...

But start by opening up ports of your router to the wan side, and then check whether you can reach these from the outside, if not check wether your mobile carrier or your ISP might helpfully trying to filter these out. To make life easier start with a port >> 1024 and do not use one of the commonly abused ports (like SMB/CIFS).

2 Likes

In your case simply ask the isp about it, bc there is no need for public ip if they dosent allow you to open ports?

Its very strange to me why your isp is doing that, just give them a quic call and im sure they will help you out?

And if its not a secret what isp are you using?

Also if you dont wanna call your isp you can try and brige 1 of the wan ports to a port in the switch of the router and then try to acsess it that way if it still dosent work ssh in to the router and post the output of:

cat /etc/config/firewall

AND DONT FORGET TO EDIT ANY SENSITIVE INFO!

2 Likes

Thanks for the tip.

It's the isp of my parents-in-law. They're very old so I'd avoid the trouble.

I'm seen like the computer geek in the family and they're already putting up with a lot of my experiments. Ha!

It's a China Mobile fiber connection. I've had that before and it's lately not been public, and never static.

Imagine my disappointment after getting the good news that it's public. How ironic.

If there is a sort of firewall between, the question is if there's a way to circumvent it.

Thanks again!

You need a VPS or service supplier that offers public IP addresses (public_addresss), then you can built up a tunnel from within your in-laws network to that VPS or service and then route your traffic via public_addresss to reach your in-laws' network, assuming that such tunnels are permitted and will not be intercepted by your ISP.

2 Likes

Thanks!

That's not a problem. I'd first like to do a comprehensive port scan to exclude the possibility of direct connections.

As i said in the previous post you can check by just briging the wan and 1 of the lan ports and then try to acsess your router ip that way, if you are 100sure its not something with the router

You need to stick to the method of using a vps + vpn
/they are some public ones that work with ssh tunel and are free of Charge but its not a deticated ip /
If you have any questions just ask :slight_smile:

1 Like

It would make sense for us to review your firewall config to make sure the rules are properly specified. We still haven’t seen it… I’d recommend that you post that now.

I just want to confirm — you’re setting a static IP (with information provided by the ISP) in the OpenWrt wan interface?

1 Like

Thanks to everyone replying and reading. I really appreciate it!


config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option name 'Support-UDP-Traceroute'
	option src 'wan'
	option dest_port '33434:33689'
	option proto 'udp'
	option family 'ipv4'
	option target 'REJECT'
	option enabled '0'

config include
	option path '/etc/firewall.user'

config rule
	list proto 'tcp'
	option src 'wan'
	option target 'ACCEPT'
	option name 'SoftetherTCP'
	option dest_port '61002'

config rule
	option name 'SoftetherUDP'
	list proto 'udp'
	option src 'wan'
	option dest_port '40000-40010'
	option target 'ACCEPT'

config rule
	option name 'Test'
	list proto 'all'
	option src 'wan'
	option target 'ACCEPT'


this rule is extremely dangerous and should be removed immediately.

2 Likes

Yes, I am. I'm replacing an older router and that's the config that was set on the old one. It surprised me to see it. I tried DHCP and it works too, but a private IP is supplied. I'm fine with that as long as upnp is supported to open ports, but it's not. (I'm successfully tunneling into a friend's home with upnp and cron so I'm familiar with the openwrt config for that. To get it to work you need to allow the WAN interface to be exposed to all protocols, as it seems that the upnp protocol isn't udp nor tcp for some reason.)

Haha, I knew this post was coming. I just explained this in my previous post.

It's not so dangerous if I'm behind a firewall or trying to run a port scanner for testing purposes.

I don't plan to keep it since upnp isn't available. Just for testing...

Thanks for the quick reply by the way. You guys are awesome!

Fantastic suggestions. Unfortunately I tried ridiculously obscure ports around the 60000 range and no go.

The internet connection works great from the LAN side. I don't notice any dropped connections.

So I'm just impressed with how well this "firewall" works. It seems to block EVERYTHING.

Before I give up I just want to do a scan and see if some of the essential ports are blocked. Maybe I can tunnel through ICMP or DNS or some crazy stuff like that. I'd love to explore that. I'm not familiar with it so I just thought to scan common ports first. But how do I set up OpenWRT to listen to all those hundreds or thousands of ports so I can run the port scanner?

Yes, the default firewall does exactly what it should in terms of blocking everything that is not explicitly allowed by user-added rules.

That said, WRT the port scans, are there really active services running on the ports that you opened? The port will still be reported as closed unless there is a service that will respond to the port scan.

If anyone is wondering "why bother?" here's the reason for tunneling with a direct connection to a "seemingly" crappy isp.

There are a lot of much worse ISPs in China. Here the ISPs don't buy lots of bandwidth to account for the need during peak hours. That means that during peak hours, you can only access parts of the internet at a snail pace. When that happens it's extremely useful to have a set of domestic relay points to try and route some or all of the traffic over. That's why using a VPS as an intermediary isn't practical. First of all there's red tape to set up a domestic VPS. (They're seen as more business oriented.) Setting one up abroad defeats the purpose of accessing better peering onto the internet.

You can try and get the best ISP for one location but then you might encounter lots of bad ones in other locations. Not good if you stay in different places or want to save some money on the fees.

Yes. I tried to use iptables to redirect all incoming traffic to a single port, to run the scanner, but, it didn't work. I'm not too familiar with iptables.

This is what I tried.
iptables -t nat -A PREROUTING -i eth0.2 -p udp --dport 1000:65000 -j DNAT --to-destination :61002

And I had a service listening on 61002.