thanks for your time
I’m planning to move form landline to SIM based internet access. The problem is that I have few servers home so I need to open some ports
Before I even decide it is the right way to go I need to understand if the provider I’m intent to use leave port 80 and 443 open.
For this reason I created a DDNS entry and now I need to create a iptable/firewall rule. I’m new to ipfire. In the “New rule” section I can’t realize how to open port from RED to the ipfire machine.
Can someone pass some hints
By all mean, is there anyone who is doing the same in Italy? what SIM provider?
do you mean doing a destination NAT, a port forward of 80 and 443? Meaning, you have a web server in your LAN that you want to be available from Internet?
Source; standard networks: RED
NAT activated → destination NAT; firewall interface:automatic
Destination address (IP address or network): IP of your server
Protocol preset, Service Group: web (this opens both 80/443)
or
Services: either HTTP or HTTPS (this opens either one or the other port)
the rest should be obvious, but ask if it is not.
At the moment I’m testing ipfire box with LTE modem and I need to test if the ISP block some ports
For this reason the only thing I can try at the moment is reaching the ipfire machine with DDNS from a different machine online, in other terms how I see it allow INPUT to WAN connections. For this option I should not need port forward (I think).
As soon as I will be able to test one port I can change fw rule for all ports I need
Bottom line of this thread is:
Testing if ISP keep ports open or close
Source; standard networks: RED
NAT activated → destination NAT; firewall interface:automatic
Destination; Firewall: all
Protocol TCP, Destination port 444
I believe this should work, but I never did it myself. In case, I hope someone else can confirm this.
Obliviously after your test, destroy this rule and never speak of it again. Unless you like having your machines owned.
If I understand you correctly you are trying to use your DDNS url from your green network to access through RED to the internet and then back into IPFire to see if the ISP has blocked a port.
If that is what you are trying then I believe that it will not work. IPFire will recognise that the url is leading to a machine on the same subnet and will go directly to the server without going out via the RED interface.
An option would be to use a mobile phone connected to the internet via a Data Connection as long as you have one available.
The only other thing I can think of is to use the GRC Shields Up test from a computer on your green network. This will test what ports are marked as open but for that to show up the port 80 and 443 you would need to have a working Port Forward in place otherwise the Shields Up test will not get to your machine. https://www.grc.com/x/ne.dll?bh0bkyd2
I assume he wanted to open the wui of ipfire to the red interface and by connecting to the DDNS domain from another network (say, his telephone) he wanted to see if the web page would show up in the browser. However very likely I misunderstood.
Just for the information my own experience with lte / mobile connections is they are buried deep in carrier grade Nat CGNAT) and rarely, if at all, you will get a live external wan address.
Typically you will get a wan ip in the private range… 10. Or 100 And the real wan ip is several layers above that and shared by many users so port forward in the router or firewall would not pass the traffic anyway.
Actually here in Greece we see this on some dsl connections where the ISP assigns a 100 range ip the services like dydns appear to work OK as they find the real ip but it is not what’s is allocated directly to you.
Ciao @Ian, this is exactly what is happening at the moment, the RED has IP 10.x.x.x and this is also the reason why I’m trying before change from DSL to SIM.
Once I has similar issue I decided to use odd ports with eventually port forwarding.
I have to change ISP and I’m also fearing the possibility the new one will block standard port and call the call center is useless when it goes down to such specific questions.
@cfusco , that was exactly my intention, simulate an external connection to the IPFIRE unit.
Said all the above, I gave it a go reading the iptables. If I change to INPUT to ACCEPT by default insead of DROP and considering there is no other rule this should open all ports with all interfaces. Correct?
I know it wrong as firewall but it is for testing and there is no machine connected. the policy will be changed ASAP
If I understand you correctly, you want to use IPFire as a sensor. You want to put it in there, and scan the whole range of possible ports with something like nmap. Then, you have a list of closed ports, which will lead you to conclude that those are blocked by your provider network.
You can’t do that.
Let’s say you have no filtering what so ever in IPFire and you do a nmap scanning of all the ports, what would you see? Only the ports that have a server or a process waiting for incoming packets. IPFire has a web server waiting for connections on port 80. If you follow the steps I highlighted in my previous post, you should see an open port 80, unless your provider is not allowing it. But any other ports? Maybe the DNS, but I am not aware of any other process running on IPFire opening a port. Maybe there are others I cannot think at the moment, but not ALL the possible ports or even the most common ones.
I do not understand routing enough to tell you if you would achieve your goal by creating a firewall entry using a destination NAT, one for each port, where you instruct IPFire to accept those packets even if there is no real process running and waiting to receive packets in those ports. Maybe someone else can clarify that, but even if this is possible, you have to create a rule for each port.
In other words, if you scan a computer attached to internet, without any firewall protection, but with no process waiting for incoming packets with a given port number, a nmap scan of this computer will detect 0 open ports.
@gipsea As I said, I do not know that just by creating rules in the firewall, you can signal that those ports are open. Also, I do not think you can create rules with just INPUT and ACCEPT, you need to create a rule to tell IPFire where to send those packets, even if it is to itself. Therefore you need a destination NAT. Maybe some of the IPFire developers or someone that really understand routing can chime in and clarify this point.
If I have to guess, even with a destination NAT rule correctly formed in the firewall, but no process behind it that accepts the packets, the port will not be open. If I am right, you need to install in one computer behind IPFire, or on IPFIre itself, an honeypot-like server. One for each port you want to check. Or you have to write a shell script that tells the operating system: “I am accepting those packets, send them to me”. But you need an end point to the communication. This is my guess. I hope someone can clarify that, because now I am really curious to know the answer.
just got 2 minutes to check some suggestions of this port.
iptables -P INPUT ACCEPT
NMAP result
Nmap scan report for ISP_IP
Host is up.
PORT STATE SERVICE
443/tcp filtered https
444/tcp filtered snpp
as @racerock mentioned, the ISP_IP is a public IP while RED shows and private IP.
I don’t know IPFIRE well enough if it implements some further filtering by default to confirm the ports are closed by the ISP rather box itself.
Can someone confirm or ammend the test is consistent with the goal of my investigation? Is port forwarding required to access port like 444 from RED zone?
