Support for creating a firewall rule needed

Hi,
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.

[UPDATE]
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 10.0.0.0/8 Network route to 192.168.0.221. If i set the route on local computer, it works.

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

[UPDATE 3]
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.

Hi,

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.
Means
protocoll: udp
source: red
destination: 192.168.0.221:51820

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