Aside from aesthetic and functional improvements (hosts can now be enabled/disabled), there was an issue where, no matter how many times we updated the data, if the IPFire firewall wasn’t restarted, it wouldn’t recognize the change and wouldn’t function properly.
A soft restart was performed with the command:
/usr/local/bin/firewallctrl
Faster than a full restart
No interruptions to established connections
Official IPFire method for reloading rules (I think)
A first look at the source show 2 (little?) problems
the check for valid IP isn’t complete
general_functions.pl ( the method used throughout IPFire ) reads
sub validip
{
my $ip = $_[0];
if (!($ip =~ /^(\d+)\.(\d+)\.(\d+)\.(\d+)$/)) {
return 0;
} else {
my @octets = ($1, $2, $3, $4);
foreach $_ (@octets) {
if (/^0./) { return 0; }
if ($_ < 0 || $_ > 255) { return 0; }
}
return 1;
}
}
the lookup function catches the last ‘Address:’ line of nslookup only. this may be not the requested information.
example: nslookup heise.de yields the following address lines
Hello. Sorry for the delay in replying. There’s no limit to the number of objects, and when you perform a full backup of IPFire, the “customhosts” file in “/var/ipfire/fwhosts” is also backed up. Regards.
I’m going to connect to a FQDN VPN server using openvpn. I downloaded a client packet for openvpnconnect to my laptop in green zone and keyed-in the FQDN into your Firewall DYN DNS addon for Zone RED.
Later on I and inserted a rule into ipfires firewall rules allowing above ovpn udp port in/out connect to the host offered by your Firewall Dyn DNS addon.
openvpnconnect starts and creates its ovpn-net. The FQDN host gets an ip-address inside this opvn net: 10.9.0.1.
But this is very strange:: Why does the list of hosts in your Firewall DYN DNS addon show the ip-address inside this opvn net 10.9.0.1. instead of the ip of the FQDN host (85.x.x.x.).? No connection, of course. packets run within a circle.
How did this information find its way into your Firewall DYN DNS addon?
Let me repeat: ovpnconnect runs on a laptop in green zone; it does not run not on ipfire. The only piece of information I keyed into Firewall Dyn Addon was the FQDN for ip 85.x.x.x. No static rules, nothing else,
The plugin I created is designed solely for dynamic public IPs, allowing you to create rules for them using the “Hostname” configured in the “Dynamic DNS” module of the IPFire Firewall. That’s all.
This module I created has nothing to do with the configuration and operation of OpenVPN. Therefore, if you have any questions about how OpenVPN works and how it assigns IPs internally, please look for information in the IPFire Wiki (www.ipfire.org - Welcome to IPFire Documentation) or ask your question more concisely in the Community.
we’ve run into a little misunderstanding. Let me show a picture to you:
This IP (10.9.0.1) seen in this picture belongs to an ovpn-rw-client-subnet..
The rw-client is installed on my laptop. My laptop is
powered-off.
This rw-client belongs to a server running on an FQDN of
my webspace-Provider (85.xxx.xxx.xxx).
How does Firewall Dynamic Addon get to know about this IP?
I’ve never installed this rw-client on ipfire. Installation would be impossible because only n2n-connections can be imported.
ipfire has no static route.
Firewall Dynamic Addon should show 85.xxx.xxx.xxx instead of 10.9.0.1
If, when you create the rule in the Addon (before establishing a VPN connection), it’s not created at all, what does that solve?
The problem is that everything seems fine, but once the VPN connection is established, the Addon rule, which was correct, now shows version 10.9.0.1, right?
If so, from IPFire via SSH or the console, run the following command and see what it returns:
nslookup your-fqdn-vpn.com
And with google resolution:
nslookup your-fqdn-vpn.com 8.8.8.8
Try these tests before and after making the first connection to the VPN server.
IPFire uses dnsmasq as its DNS cache. If that FQDN previously resolved to 10.9.0.1 (perhaps due to a VPN provider configuration), it was cached. The TTL might be holding that incorrect entry.
Possible solution is: Clear DNS cache: Restart dnsmasq.
The operation of dnsmasq is completely independent of this add-on. You can search for how to purge/reset the dnsmasq tables and try to resolve the issue.
I just installed the add-on, but without connecting to the VPN, does the IP address appear correctly? To test this, delete it and recreate it without connecting the VPN client on your laptop.
Well. We’re getting fixated on the idea that the problem is the add-on. This add-on is completely neutral, not modifying IPFire’s functionality in any way. Therefore, if you’re getting the same results from the add-on via SSH or the IPFire Terminal Console, it’s IPFire itself that’s resolving the issue this way.
If the add-on shows this result, it’s because IPFire is resolving it this way.
The solution would be to determine why IPFire is assigning this IP address, and the best way to do that is to create a new issue and ask the community about it.
Yes the unbound cache is cleared when a reboot is carried out.
If you are using fixed IP’s for your access then you don’t need unbound or do you mean you use an FQDN that is assigned a fixed IP. Are you assigning this fixed IP in the Hosts menu or where? If you want to use an FQDN thgen the assignment of IP to FQDN has to be defined on the Hosts page if you are not using DHCP at all.
I would first uninstall the unofficial firewall_dyn addon and try whatever it is you are trying to do and then report if you still have the same issues. Then whatever logs you have can be reviewed on this forum to try and see what errors are occurring.
This has nothing to do with IPFire.
You are trying to move files on a server in your green lan to another directory on the same server.
Something else on that server is accessing the directory or files you are trying to move.
IPFire does not play any part in moving files from one directory to another directory on the same server.
Faster than a full restart
