1
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
General Discussion / Re: Wireguard site-to-site stopped working after setting dual wan failover
« on: November 26, 2023, 06:54:43 pm »Make an RFC1918 alias and use that for the higher rule as the destination, gateway "default". Then make another rule with destination any and gateway your failovergroup.
it is pretty much what I did. I set a pass rule from LAN to any on the default gateway above the "failover_group" one.
Now, the wireguard tunnel to PC_B works. Anyway, if WAN1 on PC A goes down it switches to WAN2 and I still have internet connection, but the wireguard tunnel to PC_B doesn't work anymore. I think I tried everything I could think of, but there was no way to make it work on the second/backup WAN2.
3
General Discussion / Re: Wireguard site-to-site stopped working after setting dual wan failover
« on: November 26, 2023, 04:07:48 pm »
I noticed that if I set the LAN pass rule to "default" instead of the failover group, the wireguard connection gets back to work. But I don't think it is what it is supposed to be.
4
General Discussion / Wireguard site-to-site stopped working after setting dual wan failover
« on: November 25, 2023, 09:50:21 pm »
Hi,
I started with this setup
PC A: Dual WAN failover + wireguard setup
PC B: One simple gateway (no failover) + wireguard setup
Everything worked as expected. PC A and PC B can access each other's resource via SAMBA, and PC B can even connect to PC A via RDP
I setup a dual wan failover on PC B (same setup as PC A) too, and the wireguard tunnel stopped working.
I mean, the handshake seems to be up, but devices on opnsense's LAN side can't reach devices on the other opnsense's LAN anymore, not even ping one another.
I haven't yet understood what may have been wrong.
Could you please give me an hint as a starting point, just to see where I need to check the possible misconfiguration? Thanks
for the record, here are the two tutorials I followed to setup dual wan failover and wireguard for both machine:
https://www.youtube.com/watch?v=CcXYiFj9mBA -> dual wan failover
https://www.youtube.com/watch?v=ah0Kkkqqfcg -> wireguard site-to site setup
Thanks
I started with this setup
PC A: Dual WAN failover + wireguard setup
PC B: One simple gateway (no failover) + wireguard setup
Everything worked as expected. PC A and PC B can access each other's resource via SAMBA, and PC B can even connect to PC A via RDP
I setup a dual wan failover on PC B (same setup as PC A) too, and the wireguard tunnel stopped working.
I mean, the handshake seems to be up, but devices on opnsense's LAN side can't reach devices on the other opnsense's LAN anymore, not even ping one another.
I haven't yet understood what may have been wrong.
Could you please give me an hint as a starting point, just to see where I need to check the possible misconfiguration? Thanks
for the record, here are the two tutorials I followed to setup dual wan failover and wireguard for both machine:
https://www.youtube.com/watch?v=CcXYiFj9mBA -> dual wan failover
https://www.youtube.com/watch?v=ah0Kkkqqfcg -> wireguard site-to site setup
Thanks
5
General Discussion / Re: error(s) loading the rule
« on: November 25, 2023, 09:39:41 pm »That's odd, the error message clearly shows a rule without direction ("pass quick") and with reply-to set to your home router ("reply-to (vtnet0 192.168.3.1)"). Is this your only rule? You might want to check Firewall: Diagnostics: Statistics: rules for duplicates. Or delete and recreate the rule.
Yes, it's odd.
Nothing meaningful in Diagnostics.
Thanks
6
General Discussion / Re: error(s) loading the rule
« on: November 25, 2023, 01:10:08 pm »You need to specify the direction of the rule (in). Also, since your PC is in the WAN subnet, you should disable reply-to.
Not sure how you were able to create a WAN rule without specifying the direction. Or is this a floating rule?
It's a simple pass [IN] rule, and reply-to is already disabled:

Thank you
7
General Discussion / error(s) loading the rule
« on: November 24, 2023, 03:13:05 pm »
Hi,
Could anyone please help me make any sense of this error message?
https://imgbox.com/8walW3or

OPNsense is running as a VM in Proxmox (just for practice purpose at the moment), and its WAN port gets an IP from my physical home router (192.168.3.1), which manages my home LAN.
IP 192.168.3.100 is my desktop PC. I set a WAN pass rule for my PC so that it can reach the OPNsense dashboard and devices on the OPNsense LAN side.
Thanks
Could anyone please help me make any sense of this error message?
https://imgbox.com/8walW3or
OPNsense is running as a VM in Proxmox (just for practice purpose at the moment), and its WAN port gets an IP from my physical home router (192.168.3.1), which manages my home LAN.
IP 192.168.3.100 is my desktop PC. I set a WAN pass rule for my PC so that it can reach the OPNsense dashboard and devices on the OPNsense LAN side.
Thanks
8
General Discussion / Re: Getting access to Opnsense GUI from WAN issue
« on: November 14, 2023, 02:08:56 pm »You can also disable reply-to per firewall rule and leave the setting at the default.
It is exactly what I did already.
Thanks
9
General Discussion / Re: Getting access to Opnsense GUI from WAN issue
« on: November 14, 2023, 12:51:32 pm »It's ok to keep it disabled. In the average case you don't access the GUI from the WAN and this is only an issue if you are locally attached. As soon as you pass the next hop over the router this problem doesn't exist anymore. The firewall wants to try to reply to the router, not the client in that scenario. This is required for multi-WAN to run smoothly so it is enabled by default.
Ok, I think I got it. But I am still wondering why I didn't have the same problem with my OPNsense VM running on VMware workstation. the Reply-to option is still set to default there. Strange thing really.
Moreover, I need to add a second WAN to experiment with dual WAN failover setup on OPNsense.
I guess that I have to set it back to "default" then. right?
Thank you
10
General Discussion / [SOLVED] Getting access to Opnsense GUI from WAN issue
« on: November 13, 2023, 08:41:26 pm »
hi,
I installed OPNsense on my Proxmox machine to practice with it, and wanted to get temporarily access to its Web GUI from the WAN port to set it up more easily from my PC running on my home LAN managed by a physical router.
I hadn't managed to do it until I set "Disable" for the reply-to option in the WAN rule advanced settings, which did the trick.
However, I haven't yet understood what the reply-to is really for, and if it is safe to keep it disabled.
Again, I also have OPNsense running as a VM in my WMware workstation. I only set the pass rule on its WAN without disabling the reply-to option which is still set as "default". I can access its WEB GUI from the WAN nonetheless.
Why?
I installed OPNsense on my Proxmox machine to practice with it, and wanted to get temporarily access to its Web GUI from the WAN port to set it up more easily from my PC running on my home LAN managed by a physical router.
I hadn't managed to do it until I set "Disable" for the reply-to option in the WAN rule advanced settings, which did the trick.
However, I haven't yet understood what the reply-to is really for, and if it is safe to keep it disabled.
Again, I also have OPNsense running as a VM in my WMware workstation. I only set the pass rule on its WAN without disabling the reply-to option which is still set as "default". I can access its WEB GUI from the WAN nonetheless.
Why?
11
General Discussion / Re: SSDP/DLNA across different subnets
« on: October 01, 2023, 10:32:44 am »12
General Discussion / Re: SSDP/DLNA across different subnets
« on: October 01, 2023, 10:07:18 am »The floating rule does not match, because this is not unicast traffic. Start with permitting from any to any port 1900 and if that works, use a packet trace again to watch what is involved in a successful communication.
The destination is not LAN net. The destination is the multicast address you see in your packet trace.
The alias "LAN net" does not mean "whatever might end up on that interface". It means "whatever has a unicast destination address matching the network configured on the LAN interface". So if e.g. LAN is 192.168.1.1/24 then LAN net is 192.168.1.0/24 and nothing else.
To make it even easier, I set any to any to any port for both interfaces/subnets. Still nothing unfortunately.
Thanks
13
General Discussion / Re: SSDP/DLNA across different subnets
« on: September 30, 2023, 09:15:02 pm »I'd move the firewall rule to the network the casting device is on and create a pass rule from the casting device IP, to the Network you want it to go to.
I've done exactly this to allow my SkyQ boxes (UK TV) to be discoverable on my main VLAN (they are on their own VLAN).
Failing that, ask in the udpbroadcastrelay thread.
The machine in which the server runs (Jellyfin on LAN subnet) has already unrestricted access to the GUEST subnet, and I created a rule to allow the client on the GUEST subnet to access the server.
I runs also Wireshark on the client machine (A windows PC in which I installed kodi) and got this result:

So, if I got it right, it is receiving the SSDP broadcast but still can't communicate
If I put the machines on the same interface/subnet the DLNA discovery works.
For the record, everything is running on a Virtual environment, my VMware workstation.
14
General Discussion / Re: SSDP/DLNA across different subnets
« on: September 30, 2023, 04:42:53 pm »15
General Discussion / Re: SSDP/DLNA across different subnets
« on: September 30, 2023, 10:23:47 am »
By looking it up on internet, it seems that there is no way to make it work on OPNsense unfortunately.
Pages: [1] 2