The rule I have is for Source IP: 10.0.0.2 Dest IP: 10.0.1.2. with any protocol allowed. I have tried adding other rules and static routes but no matter what I do I cannot get it to work.
When I have the network from pc to firewall to pc it works, I am able to ping each other and use a socket layer program to communicate. But when I add the routers into the mix it no longer works. I am able to ping from pc 1 to pc 0 and pc 0 can ping all the way to the red side of the firewall. It is not able to ping the green side of the firewall at all. I used a socket program to be able to send messages back and fourth hosted on PC 0 and they can send and receive messages. But when hosted on PC 1 it does not work. For some reason the green side can talk with the whole network but when coming from the red it does not work. One thing I noticed was the packets were being dropped due to it automatically blocking pings from the red zone so I added this rule and I was able to ping PC 1 but then when I implemented it in the whole network the same issue arouse.
I just don’t understand why it works, but then when I add it into the network it still works from green to red but not red to green no matter the rules I set. Once I added the rules the packets are no longer being dropped but it still will not go through.
edit: one thing I would like to add is this is on a raspberry pi which I know is no longer supported and the software is out of date so is it just glitchy and doesn’t work?
I‘m just tossing in a guess. You don‘t have any routes defined? I’m not sure whether default routes would suffice to route packets back and forth. The netmasks are pretty rigid so each of your devices (fw, router1 and router2) will need a route from one side to the other. That doesn‘t seem like a fw rule problem.
To troubleshoot I would traceroute from pc0 to pc1 and look where the connection drops. If you get a ‚no route to host‘ (my guess) then you‘ll need those rules along the way.
I am not sure if it is a typo but your address definition for Fa0/0 is 10.0.0.1/28 which covers the Usable IP’s 10.0.0.1 to 10.0.0.14 which then overlaps with Fa0/1 and the second Fa0/0 on the output of router 1.
Routers need to have separate subnets for their different interfaces otherwise they will have difficulty routing.
If you made the first Fa0/0 to 10.0.0.1/30 then this would cover the usable IP’s of 10.0.0.1 to 10.0.0.2 which would make the two interfaces of Router 1 separate subnets.
What I don’t understand is why you need three routers between PC0 and PC1. IPFire is a firewall but also a router. This makes it very complicated to ensure that the routes to get through all three routers are correctly lined up. I would agree with @dal8moc that doing a traceroute through all three machines is the best way to identify where the traffic gets stopped.
The 64 bit aarch64 arm version is still supported and available.
If it is the 32 bit arm version you are using then the last Core Update version for that architecture was Core Update 173. It will still work as well as it did when it was first released at the end of Feb 2023 but as time goes on it will not get any fixes for new security problems that occur. Also any new bugs found in it will not be fixed.
I am going to test what you said, I think this may be the issue…
What happened was it originally was a /29 or /30 but the person in charge of my project wanted it changed and I forgot to change the IPs. I will let you know if this is the issue but I am willing to bet this is what is wrong… I have spent too many hours on this for it to be so simple thank you so much.
Also the reason there are so many routers is our Professor who is in charge of the project wants to simulate a larger network. I agree that many routers aren’t really needed but it is her choice.
I did a traceroute and on pc 1 it goes all the way to pc 0 but on pc0 I can pig 10.0.0.14 but when doing the trace route it goes to 10.0.0.1 and then stops…
also i did fix the ospf and the subnets it is now /29
I fixed the subnet and made it a /29 and fixed the ospf commands. The traceroute on pc 1 goes all the way to pc0 but when i do a traceroute on pc1 to pc0 it goes to 10.0.0.1 and stops. But I am able to ping all the way to 10.0.0.14. Does this mean that I should try adding a static route? I am not sure why I can ping but it just gets lost.
EDIT: also when taking ipfire out of the networking the two pcs can ping across the network back and fourth so there is for sure something wrong with IPFIRE.
If I read your drawing correctly then .14 is the RED interface of ipfire. That should stop the traffic. After all that‘s what a firewall is for. You‘ll need a rule to allow packets through RED to GREEN. PING would need a rule for ICMP Traffic (no ports here). Same goes for traceroute as it uses icmp under the hood if I‘m not mistaken. But the firewall protocol should give you enough hints. There should be DROP_INPUT messages with the icmp protocol. When you get that working you should try sending messages from the RED side to the pc on GREEN and watch the log again. The DROP_INPUT messages will tell you the protocol and the ports you‘ll need a rule for. The other way around shouldn‘t be a problem as green is allowed to send through red per default. And don‘t start sending messages from green side to red. As ipfire is a stateful firewall the return packets may pass through even without the rule. So it would look fine. The trouble starts when red is talking first. Then it should run against the (fire)wall.
I get what you are saying and I do have rules. Maybe my rules are wrong but when I plug both computers directly to the pi this allows everything to flow, it only gets stopped when it’s in the larger network. I have just kept adding rules and trying different ways of typing them to see if that is why traffic cant get through but nothing is working.
I‘m not really sure if these rules are correct. I‘d start fresh with NO rules. Then check the log for DROP_INPUT lines to see what the source and dest parameters are. To rule out silly mistakes I would start with a wide open rule (say interface:red → interface:green on all ports allowed) though and test the setup. If that connects you can tighten the rules. If you enable the log on the rule you‘ll see the relevant packets with FORWARDFW. Then you can read the source, dest and protocol right off the log and adjust your rule accordingly.
Just wondering how should they look then? Am I able to just do a whole interface I didn’t know that. Sorry I am fairly new. Also I would like to add that when both computers are plugged directly into the pi it does work fine with the rules I have, which leads me to think it is a routing issue but when ever ipfire isn’t plugged in it routes fine?
The selected option probably reads „default networks“ and should be RED on the source part. You don‘t want the RED on the right side reading ‚firewall‘ as that means packets originating on the firewall itself.
On the destination side there is another default networks option:
That should suffice for a start. The IP on green of course is different for you. And notice the mark on „Protokollierung aktivieren“. That is the logging option for a rule. You want that as you want to see what packets pass throuh this rule to refine the broad rule further.
