I currently have Red (192.168.1.245) connected to a switch which connects to the main router (192.168.1.1). Green is at 192.168.2.1.
PC A (192.168.2.11) from green can access internet fine.
I also have a PC B (192.168.1.190) from the same level as Red and can ping Red fine. However, this PC B ping 192.168.2.1 or any green result in an error Request timed out.
Since Red to Green is blocked by default so I need 2 firewall rules to solve the problem.
To fix the Green DHCP server access from 192.168.1.190, from the ipfire document, my understanding is that I need to create a firewall with the following requirements
My network setup is double NAT but to go from Red to Green is not double NAT since 192.168.1.190 is at the same level as Red. The only NAT that I have to deal with is the NAT from 192.168.2.1. So, to go from (192.168.1.190) to (192.168.2.1) do I have to go through the main router NAT first?
The problem you describe is normal. PC B is a device in the WAN, and those devices are not allowed to establish a connection to your LAN. This one main functionality of the IPFire firewall OS.
The reason being PC B (my work station) needs to communicate with other devices that do not need protection from the firewall and connected to the main router (same level with Red). Also, the function of the firewall rules is to enable that pathway which I would like to explore its possibility. It is not something one would want to do all the time but it is practical for me. Thanks for the reply.
All devices in the LAN can communicate with all devices in the WAN (with standard configuration of IPFIRE ), if the communication is initiated by the LAN device.
For communications from devices between the internet router and IPFire, you may need port forward rules or allow rules for 192.168.1.0/24 → 192.168.2.0/24. To deny the access from the world wide network, a block rule for 192.168.1.1 → 192.168.2.0/24 must be defined before the allow rule.
@ Phil SCAR
Out of desperation I did try https://192.168.1.245:444 yesterday but this son did not budge an inch. In the end still going to no where.
I am still curious if there is any hidden settings on ipfire that I might have missed. Like you said, I could not find anything is wrong with my rule.
Thanks for your reply.
A port forward rule can’t have the whole green network as destination, IMO.
Port forwarding is to allow dedicated access to single devices in green from red.
For example, you can define a rule to access a web server in green binding port 888 to :80.
From your reply, I assumed that LAN = Green and WAN = Red (192.168.1.x in my case)
Your saying “For communications from devices between the internet router and IPFire” makes me wonder, is there a difference between RED and other devices from the internet?
Please correct me if I am wrong, basically you suggested that I create a deny rule “first” for 192.168.1.1 → 192.168.2.0/24 before a second rule of allowing 192.168.1.0/24 → 192.168.2.0/24. I only need 192.168.1.190 to be able to access 192.168.2.1 so will 192.168.1.190/24 → 192.168.2.0/24 be ok?
Whatever it is, this thing is tough. It has consumed 2 days of mine and still getting to no where near anything. Essentially, no communication nor ping are happenning from 192.168.1.190 to 192.168.2.1 but 192.168.1.245 (Red).
@pvk177 , I supposed you have defined a special network on your local site.
Devices which do direct WAN access through the router, because of special reasons.
Two of this devices are your IPFire and your work station, PC B.
If you want to configure IPFire from your work station ( outside IPFire’s local network! ), I recommend to use VPN or SSH tunneling, as mentioned in my former post.
Don’t know what happened, maybe this son is affraid of you. I re-tried https://192.168.1.245:444 and it works. What I don’t understand is, if NAT is deployed, it should allow the possible pathway of 192.168.2.1 right?
So, I can access 192.168.2.1 (using 192.168.1.245) now. Not completely happy but am contented.
Still can not ping 192.168.2.11 even though the rule is already in place.
I have another pc (192.168.2.11) on green with Zerotier installed on it. I can punch a hole through it with no problem (192.168.1.190 → 192.168.2.11, of course with zerotier ip address). However, I am determined to get this done through ipfire because I believe that it can be done somehow.
The local network (192.168.2.0/24) is connected through IPFire to the WAN.
This means, you can it reach by IPFires RED IP (192.168.1.245). But your rule only works on port 444 (TCP).
A ping from WAN uses ICMP. And you can’t address LAN addresses from outside. Private addresses are not routed by default. Your red IP is a private IP, but the red interface is member of 192.168.1.0/24 with gateway 192.168.1.1. Therefore packets are sent on this interface, and answers received are handed out to the local device which initiated the connection.
192.168.2.0/24 isn’t known in 192.168.1.0/24 and the gateway doesn’t route private address.
A bit complicated, but I hope it is clear nevertheless.
Please correct me if I am wrong but this is how I try to wrap my head around this concept.
After I typed “ping 192.168.2.11” and press Enter from 192.168.1.190 this effectively sends a broadcast signal to all netword devices asking for where 192.168.2.11 is. Since only router 192.168.1.1 will respond to 192.168.1.190 and it knows nothing about it so it is considered Dead at Arrival. However, what confuses me is why ipfire responds to it with error messages when it should better know where 192.168.2.11. Here is the error I got:
@bbitsch
I conducted the test at 14:33 and 14:34 but seems like it did not even care to record it. Here is the log on 192.168.1.1:
Jun 11 14:30:08 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/directory: bad comm
Jun 11 14:35:01 rc_service: service 17534:notify_rc restart_letsencrypt
Jun 11 14:35:06 miniupnpd[679]: remove port mapping 39991 UDP because it has expired
Jun 11 14:35:08 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/directory: bad comm
Jun 11 14:35:12 dnsmasq-dhcp[277]: DHCPREQUEST(br0) 192.168.1.96 ac:37:43:a9:b8:69
Jun 11 14:35:12 dnsmasq-dhcp[277]: DHCPACK(br0) 192.168.1.96 ac:37:43:a9:b8:69
You brought up a very good point that I faintly remember I used to run into it when messing around with my raspberry pi and windows pc. Let’s see what I can do.
)