OPNsense Forum
Archive => 19.7 Legacy Series => Topic started by: adrianschneider on August 14, 2019, 10:30:20 pm
-
Hi,
I have little problems since updating to 19.7:
I‘ve got a Multi-WAN (failover) setup (with double NAT) and need to make DynDNS updates from the OPNSense box on both interfaces. However I can‘t reach the internet from the non-active gateway anymore (missing routes).
This leads to the fact, that the DynDNS updates from the backup gateway don‘t work.
I now set up static routes for checkip.dyndns.org and my DynDNS provider on the backup gateway, but I assume this is just a temporary solution and not the best one.
What could have changed so that it doesn‘t work like before?
Best wishes
Adrian Schneider
-
had issues also but not same setup...
mine is load balance mode. cant figured out to reroute so I just went back to "production"
everything was working on .44 dev version but after upgrading to .72... routing got messed up for some reason...
going to production without any changes or re config fixed the routing issue.
-
Ok,
I've came a little further:
There are the following automatically generated rules:
* let out anything from firewall host itself (Floating, before user defined rules)
* let out anything from firewall host itself (force gw) (per WAN, before user defined rules)
So I guess the first one of them forces the usage of the default gateway. So the package is on the wrong interface and the force gw rule is never evaluated on the backup interface.
-
There is a Disable Force Gateway checkbox in Firewall : Settings : Advanced. Check it. With 19.7 Gateway groups arent supported anymore with DynDns, sorry.
-
Thank you for the answer.
I don‘t want to do DynDNS on the gateway group but on the single gateways. So this is unrelated. And why should I disable force gateway? I particularly want the box to use a specific gateway in this case.
-
agree, help said by checking the box opnsense will use the routing table not the asisgned gateway.
would that mean any rule assigned to wan2 will be diverted to system "default"
and
would multiwan(load ballance) used system default?
or is this just a temporary solution for the issue?
-
Disable Force Gateway lets you e.g. Port forward to internal on both WAN. Just test If it fits for you
-
it didnt help, confirmed issue is replicable.
from production (working) to delopment (no internet).
opnsense, has internet access, I can use diagnostic to ping and trace route outside/public IPs.
and I can easily switch from development to production.
but the internal LAN has no internet, from the looks of it is as if the gateway is not returnning data to LAN (not sure). I can see in the live view that the machine im using is making dns request (and it is green).
it is as if the gateway is not responding the the reuest or ignoring...
the captive portal shows up, but does not connect to the internet..
if you need me to do something, just instruct me and let me know
-
I‘m not sure, this is related, @tong2x, this sounds different to me.
@mimugmail:
Tried it, does not change anything. BTW, I can use port forwarding on both WANs without ‚disable force gateway‘ without any issue. Access from outside does work perfectly fine.
The only thing that does not work is to use a gateway other than the default gateway for traffic originating from the OPNSense machine itself. (It works perfectly fine for traffic from the LAN(s)).
Even when I use ping -S on the secondary interface: The packet leaves OPNSense on the interface with the default gateway and does not find its way to the secondary gateway.
-
Packets originated by the Firewall itself like Proxy always use default gateway only. When using LAN source it should work. Maybe there was a change with 19.7.
Can you search open and resolved issues in GitHub core?
-
I think I found the cause:
https://github.com/opnsense/core/commit/7bfadb2acd4660b05d11059152dec7d88a90b288
-
Looks good, apply the patch or wait for 19.7.3 after holiday season :)
-
I think I‘ll go with the patch.
But besides: Isn‘t there automatic testing for such stuff? I think this could have easily been prevented.
Nevertheless: Great work you‘re doing here! It‘s quite enjoyable to work with OPNSense!
-
OPNsense is way too flexible to fit every needs, No way to test every combination, sorry :(
-
No need to take care of all combinations, I think unit testing would be mostly sufficient. Is there a testing repo? I‘m prepared to contribute.
It also sounds like a very interesting task to set up a full virtual lab ;)
-
19.7.3 is out
that build was supposed to fix the issue
backup before you upgrade