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 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 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
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.
[UPDATE 4]
Ok, I revoke the request for a firewall rule. 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 192.168.0.1 0.0.0.0 UG 202 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 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.
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.140 35
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
169.254.0.0 255.255.0.0 192.168.0.98 192.168.0.140 36
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.140 291
192.168.0.140 255.255.255.255 Auf Verbindung 192.168.0.140 291
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.140 291
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.140 291
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.140 291
===========================================================================
Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
169.254.0.0 255.255.0.0 192.168.0.98 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.
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: