I updated to 171 out going traffice is fine. The incoming from RED to Green none of the Web Pages, SSH, or SFTP seem to work, I reinstall 169 and restored it with the same backup file. Everything works fine with 169. 170 has the same problem I was hoping 171 fix it. I have looked up how to setup the firewall rules if any changes to the rules, No notes on it. The other reason I jumped to 171 no one said anything about this problem. Here is the odd part Email works on orange with 171. I did redo some of my rules by deleting and hand keying them back in. Did not fix anything. I am running 169 still, Hope someone has some insight on this. Clean install of 171 did the same thing with the restore file. Out fine, In not fine
in not fine.
Welcome to the community @dean8
We don’t know your rules, so it is not easy to help.
I think the plain CU 171 doesn’t have the issue. Just restore your FW rules step by step. This shows the rule responsive for the error.
Do you want to access the IPFire device from the WAN ( connected to red0 )? If yes, which rules have you defined to make this possible?
3 Likes
10,ACCEPT,FORWARDFW,ON,std_net_src,ALL,tgt_addr,172.16.168.253/32,ON,cust_srvgrp,Web-Page-SN,maidocs web,00:00,00:00,ON,www.maidocs.com,dnat,second
Web-Page-SN TCP 80 and TCP 443
Above is from the Config File on IPfire. Just one of many.
No, not accessing for the red side. nor do I have a rule to allow this. Yes, I have built and not restored the rules from the old system and keyed in by hand the rules. using what I have found per IPFire wiki.ipfire.org - Creating an External Access Rule not just copy and past of what rule I have. Still from my phone to see if I can get in from the outside. Timed out, I am working on another computer to test with in the am. Just to make it a fast plug and test. and Put it back if it fails
If you do not want to access from outside, WebGUI/SSH(if enabled)/SFTP should work out of the box.
Do you have any error messages in /var/log/messages ( can be listed from the console shell )?
I don’t think, you can use URLs in the firewall rules.
Hmmm… Set up a Nomal rule for accessing a web page. Being hosted on another computer on the green side of the firewall from the red side of the firewall. I do not want to access the firewall OS from the outside.Making a normal rule on 169 works but does not work in 170 or 171. and when you reinstall the os back to 169 it wipe the drive so no i do not have logs from the 171. SFTP is also being hosted from it own computer that works fine in 169 but not 170 or 171.
moved to new thread - moderator
1 Like
I forget what version IPFire stopped allowing Spaces in Alisses names. Broke the firewall then. Has IPfire stopped allowing - or _ in the names of HOSTS names? or any other new odd rules that maybe the problem. It would be an easy fix if that was the problem. and was Bernhard just trolling me? or does not understand the 10,ACCEPT, settings in IPFIRE? Yes, it looks close to what the DNS setting are in other software.
In CU154 the hostname check was made compliant with RFC1035.
This allows a-z, A-Z, 0-9 and - but not underscore. The hostname can be 1 character up to 63 characters in length and the first and last character can only be a letter or digit.
1 Like
@dean8 , no I’m not trolling you.
Maybe my posts are a bit imprecise, but I just want to know what you want to do.
Where is the system located, you want access WebGUI, … from?
Are there really URLs in the firewall rules? This doesn’t work!
I didn’t look into the syntax of the firewall settings file, yet. Therefore I can’t really interpret your example rule fully.
But, if this rule is faulty there should be messages about this line(s) in the logs.
I didn’t look at the source whether checks for correctness have been introduced into the software. I only know, that no evident faulty changes have been introduced. Some people ( including me ) on the development list would have noticed that.
EDIT: @dean8 , I just tried to put your example into my firewall config. It doesn’t match!
Did you upgrade from earlier CUs to 171, or did you a new install and restored an backup from an older CU? Maybe the format changed ( see the announcements of CUs ) or your backup is faulty. Have you edited the config?
Yes, The internet does say that, but the user readable name in the filewall had nothing to do with how it exposed itself to the internet. For the firewall is not the DNS server but an IP address that the DNS exposed the Real server behind it. So the names never got seen by the internet.
So, using a Alias name from the Aliases list www.maidocs.com that has the IP address of the server in it, Making it an easy task to change the IP when an IPS change happens is no longer allowed. I have access to the WebGUI of IPFIre. The odd thing is that it works in 169 no problem, Even Hand keying does not fix it in 170 or 171
The system that IPFire is on, I am holding on to it, it is in my hands. I have reinstalled it with a CD many times over the years. Even replaced the Motherboard and SSD. using the same case.
But if Aliases are no longer a thing, Are host names no longer a thing too? There for Service Groups wlll be dropped too.
But is still sounds like you never hosted a webpage thought IPFire.
if you tried the URL in the rules it works but it on IPFire 2.27 169
The last change to the Firewall Groups menu page was in November 2021 (CU162) with the following commit message so nothing related to the use of host names in the Service Groups and well before CU169
Aliases still works the way it worded before?
Just checked the Firewall Rules page and the last change for that was in CU165 in Feb 2022 and that change was to re-instate a hint when only hosts using mac addresses are used for the target.
See commit message. Again nothing to do with the use of url’s in the firewall rules and well before CU169.
By this do you mean the Aliases menu item which is only presented when you have a static ip on your red?
If it is the Aliases menu under Network on the WUI then the last change to that page was June 2021 which was CU157 or CU158 which just changed all WUI pages to use new system methods.
The Aliases page uses the validhostname check and so will have been affected by that change but that would have been from CU154 onwards, approximately two years ago. So I don’t believe that can be the cause of your current problems if CU169 works for you.
I make an Alieas for xxx.xxxxx.xxx with the IP 140.82.184.48
Then Make a Host maidocs with the IP of 172.16.168.48
Make a Service Groups WebPageSN add TCP 80 and TCP 443
I make the Firewall rule Source Standard Networks Any
NAT Destianion Nat(Port Forwarding) using the Pull down to get to xxx.xxxxx.xxx
Destination Hosts using the pull down to get maihome
Protocol Service Groups using the pull down to get WebPageSN
Remark Webpage for maidocs
Activate the rule
I am no longer allowed to post the link.
and it does not work.
As you are doing multiple posts using www dot maidocs dot com the Discourse forum software identified this as the pattern of a spammer. I have released and restored the mails but try not to repeat the same external url on multiple postings.
1 Like
LOL was the not allowed just was funny not the problem.
Hello,
Maybe it’s another setting on another rule that’s causing the problem
run on the console /etc/init.d/firewall restart
and check for any error messages.
1 Like