Rsync and similar "stuff"

I don’t think so, but could IPFire somehow interfere with internal, 192.168.1.0/24, LAN and ports like Rsync 873 or some such, used for file transfer?

I have 0 custom fw rules and nothing at all particularly defined related to the internal network, except from some static addressing and a couple of host names.

The reason I ask is that rsync does not seem to be able to communicate on port 22 and while it is trying to sync with a Windows Server I have set a Windows Firewall rule opening up all ports on the local lan and that is not working.

if bug
   check logs
   if understood
      fix
   else post here
exit 0

To check the logs, my preferred way is the following:

  1. open a console to IPFire;
  2. issue the following command to watch the system logs in real time:
tail -f /var/log/messages
  1. trigger the behavior you are trying to debug
  2. see what happens to the kernel
  3. ctrl-c to exit
2 Likes

If the problem is within the lan subnet then I would be looking at the logs on the machines having the problems on the subnet. Any traffic within a subnet will not be dealt with by IPFire, with the exception of any dns translation if hostnames are being used. Beyond that IPFire only deals with traffic going from one subnet to another.

The only way IPFire could be involved is if the subnet definition is incorrect in some way and is overlapping with another subnet.

So for 192.168.1.0/24 on the dhcp wui page at the top of the Green interface on the right hand side the IP Address should be 192.168.1.xxx where xxx is the number chosen for the green interface.

Underneath it the Netmask entry should be 255.255.255.0 which is equivalent to /24

Just as a precautionary check, with subnet 192.168.1.0/24 the IP addresses 192.168.1.0 and 192.168.1.255 must not be used for the green interface or for any machine on the green subnet as they are reserved for special purposes. The first and last IP’s in a subnet definition are reserved addresses and must not be used.

If the above is okay then the issue is on the machines inside the subnet.

I was up 4 taking out the puppy so I may have issues reading logs today.

But yes, you are of course right. In theory. What code syntax is that?

Na, cant find any related to 873 in logs.

@bonnietwin I am pretty sure that was covered in my setup so nothing to adjust there. Thanks for the clarification. I must admit i was unaware of the 255 being reserved, but my span goes from 2-250.

The basic definitions for IP networks should be known if you want to administer an appliance like IPFire.
To make it short:

  • a network is defined with a.b.c.d/m, with a,b,c,d being out of { 0 … 255 } ( 8 binary digits ) and m out of { 0 … 32 } ( number fixed binary digits counted from left, 4*8 )
  • some combinations of a.b.c.d are reserved for local, private use. 192.168.c.d for example
  • m defines also the size of this network. 32-m arbitrary bits and the right end give 2**(32-m) addresses
  • each network has 2 special addresses ( which can’t be used for naming members of the network ) , all arbitrary bits = 0 is the network address, all arbitrary bits = 1 is the broadcast address
  • example for 192.168.0.0/24:
    network address : 192.168.0.0
    broadcast address : 192.168..0.255
    possible addresses : 192.168.0.1 ... 192.168.0.254
    sample address in full definition : 192.168.0.43/36
1 Like