Support for creating a firewall rule needed

long time ago I tried to find a good solution for my vpn connection problem here. But as luck of the draw I found another solution/idea in the internet, much closer to my needs. Question was, how can I experiment with the new wireguard protocol without touching my network setup to strange. So in this mentioned solution he works with 2 raspberrys as vpn gateway for a site to site connection. For visualisation I add a draw for a better understanding.

I reached the point, that the ping from both sides works and from the frizbox site all other services too. But from the IPFire side it’s the ping only which works.
So now to my question. It seems it has to do with a, missing maybe, firewall rule I have to add in the ipfire. But I have no idea how it has to look like. Can somebody supports me please what I have to add to the firewall rules?

Thanks in advance.

Why I think, it’s a problem with firewall in ipfire? Because ping and traceroute work. I have a static route in ipfire, which says, every package for the Network route to If i set the route on local computer, it works.

I looked though the firewall logfile but have to rejected or dropped entry for this route.

I’m sure, it has to do with the static rule. It doesn’t work, because, when I set the on client side, it works fine. It seems IPFire ignores them.


Just to push my problem a little bit. Nobody with a hint here?

sorry you are not getting the needed answers. I am guessing IPFire users don’t use wireguard.

You may want to add info about the firewall rule tried. descriptions or screenshots might help.

1 Like

Hi Jon,
yes, I understand that. But I think, it’s not a problem with wireguard in general. Its a static route problem. Like I said, when I add the route on client side, erverything works fine, when I add the route as a static route in IPFire it doesn’t work. So there must be a difference in package routing. For my understanding, when I add the route on client side, the package goes directly to the gateway, because the routing information is already on client side. When I add the route in IPFire, the package went in first step to the IPFire and has to be routed to the gateway. So I’m not quite sure if it’s a really firewall problem. But on the other hand I don’t believe in a bug of the static routing modul or firewall modul. So I’m a little bit lost. I already checked the firewall logs but found nothing specific. So I have no idea what I have to add to the firewall rules. So as an answer of your question, what I added to the firewall rules. I added just the portforwarding (udp) for the wireguard service to the ip address who runs the gateway / wireguard service.
protocoll: udp
source: red

I tried to configure it once, but there was always some kind of error… couldn’t figure out what the problem was

Withough seeing the routing tables of the clients on both sides as well as the default route on both sides and the static route entries on both sides I’m not sure anyone would be able to provide any possible solutions.

The only clue that provides any insight is when you enter a static route, but then you do not define which device or host or local/remote the route has been configured on

Usually the routing table of 90% of devices are as follows

static route <defined interface/IP with access to that network>>with any metric or weight starting at 10 and incrementing ++
default gateway (dynamic route)
default route <primary egress interface/ip>

When you force a static route on the client you are bypassing the default gateway and the default route (whichever you have in your environment) and directly sending the traffic to the desired interface that has direct connection to the network you wish to access.

I would take a look on the device that is listed on the client as the default gateway and inspect those logs for a notice or warn “network unreachable”

troubleshooting I would perform the following:

arp all routing devices to ensure that hosts are visible on the remote side from both locations.
use mtr from all routing devices on both sides to routing devices on the remote side to ensure that your traffic is flowing as expected.

Repeat the same as above with a host machine to a host machine on both sides.

provide some logs with the above information and I’m sure you will find your problem or at the very least get more input to help provide a solution.

1 Like

Ok, I revoke the request for a firewall rule. :wink: So, meanwhile, I found out, that all linux clients in my network can reach the destination network without any problem. When I take a look into the routing table of the client, it works as designed, there are only tow entries inside:

Destination     Router          Genmask         Flags Metric Ref    Use Iface
default         UG    202    0        0 eth0   U     202    0        0 eth0

In my Windows-Clients, there are a lot of more.
That means, Windows interprets the routing a little bit in another way, than linux.

Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
     35   Auf Verbindung    331   Auf Verbindung    331   Auf Verbindung    331     36   Auf Verbindung    291   Auf Verbindung    291   Auf Verbindung    291   Auf Verbindung    331   Auf Verbindung    291   Auf Verbindung    331   Auf Verbindung    291
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik       1

Thank you frustro for your detailed explanation. Sorry, I’m not so familiar with all these routing stuff, so it will take a little bit to understand and to put into practice that. :wink: