I use a digital signage services that is doing some updates that will require me to add Host Names so that I can communicate with their services. These will be all outbound connections from me to them. I don’t see a way to add any.networkname.com to the firewall rules. I have tried and I keep getting an error of “Invalid Destination IP address”. I have attached the information that I received about the updates. Maybe I am in the wrong section but I feel like this would be creating rules for the Firewall and not port forwarding.
The firewall functions at the transport layer of the OSI stack. DNS resolution operates above that layer, which means it can’t be managed by the firewall in its current form. Your options are to either create a rule using the corresponding IP address and port, or utilize a different tool that operates at the required level of the stack. This means employing a proxy level tool, such as Access Control Lists. However, implementing this would require you to enforce proxy usage among your users by blocking all direct traffic that doesn’t pass through Squid, and guiding your users in configuring their browsers to use IPFire as a proxy.
@kclark
Outgoing connections on 80 and 443. So no stange exotic ports and are outgoing.
You have the IP list of those domains and sub domains?
104.20.38.199 cms.embedsignage.com
104.20.38.199 devices.embedsignage.com
134.213.3.68 app.embedsignage.com
134.213.210.78 analytics.embedsignage.com
134.213.210.78 websockets.embedsignage.com
162.13.152.25 embedsignage.com
162.13.152.25 embed.cloud
94.236.56.96 storage101.lon3.clouddrive.com
??? rackcdn.com
Make sure they are not blocked by ping to IP and name, were resolved by name.
Make sure that they were not cached by Proxy.
Make sure they are whitelisted at URL filter.
Make sure they were not blocked by IDS. You are able white list the IP for the time of use.
If you need permit domain name to IP, for ex. a security maner, then add those to DNS of IPFire as Hosts or as DNS Forward.
BR
Trash
You can add them to hosts under Firewall->Firewall Groups. There you can define individual hosts and group them together as Host Group to refer to all of them at one in the firewall rules section. While the host definition accepts either ip or mac addresses the latter can‘t be used for outgoing connections. But this is only a convenience as it won‘t resolve the hostnames from your internal net! All it does is telling the firewall that the mentioned hostnames designate the respective ip addresses. If you want to resolve the fqdn you‘ll have to add them to the hosts under network->hosts.
I would like to jump on this train, too (although I’m late 
).
Over time many servers do not change their DNS name, but their IP, because they are roaming through the clouds of Amazon, Microsoft etc. Even if I know a set of valid IPs today, it will soon change and I have to become aware of that and adapt my firewall rules.
If we could have DNS names in firewall rules, I think that would introduce lots of DNS queries upfront and it would need in-flight replacement of DNS names with all currently corresponding IPs before the rule (or rules) is even ready for use. That would certainly draw on firewall performance.
Still I humbly ask: is it possible to have that some time? Pretty please?
thanks for a great firewall
Kulm
The underlying iptables (firewall) cannot work sensibly with FQDNs. When it loads, if resolves the FQDN to and IP and uses that IP. There is no facility to re-resolve the FQDN/IP apart from reloading the firewall and you don’t want to be doing that all the time in case an IP address has changed.
2 Likes
I agree, Nick. We need IPs for iptables and we cannot follow changing IPs in real-time. But even if resolving the current IPs and regenerating / reloading the firewall rules would only happen e. g. once per night that would still be sufficient for most scenarios.
Just to detail the motivation:
imagine you want to allow access to debian.org. you would have to build four rules for four IPs
debian.org. 17 IN A 151.101.194.132
debian.org. 17 IN A 151.101.2.132
debian.org. 17 IN A 151.101.130.132
debian.org. 17 IN A 151.101.66.132
In a month’s time maybe these have changed without you knowing. You would then need to lookup all IPs again and adapt the rules manually. If on the other hand the firewall rules would allow for FQDN and the firewall would re-check the underlying IPs during a nightly reload of the ruleset, you would never have to change the rules with FQDN again, because they are still true.
@helix has a unofficial addon called banish.
The old version worked with iptables
The new version works with ipsets and is linked to the Geo block.
The old version I think may have had the capacity to make individual firewall rule.
But I have never used either.
Others have made iptables rules that use ASN . Unfortunately no such capacity is in the WUI of IPFire 2.
I do not see the Limited resources of the IPFire team working on such thing.
That would be better server on IPFire 3.
Which we can only hope will be sooner that latter.
Sorry but that isn’t totally true. If an FQDN has multiple IP addresses (Facebook, Google etc) and your DNS lookups are on a round robin so any IP you get when the firewall reloads may not be what you get when you try to use the FQDN, say in your browser. That depends on the DNS TTL.
My current version of Banish resolves ASN’s with the location database and cache’s the result. When the location database is refreshed (about once per week) the cache is refreshed.
Banish sorts the ASN FQDN/IPs along with CIDR’s and IP range addresses from the Banish cgi into a ipset list which is then used as a resource in ipblocklist.
https://people.ipfire.org/~helix/banish/README
Rob