Hi,
after the update (without any issue) to 23.7.7_3 my Internet connection is broken (Germany, Vodafone/ Arcor VDSL line via Draytek Vigor 130). Worked fine before and works again after re-install of 23.7; confirmed that a couple of times now.
Do you have an idea what goes wrong?
Thanks in advance,
Torsten
I had the same problem, I reinstalled completely opnsense, but now it is asking to update to 23.7.7_3 for additional packages, which I have not yet done, fearing it will break again.
For me the main gateway is fine, its the PIA Wireguard gateway that is failing.
@SvenTorsten For PPPoE check that your PPPoE gateway is marked as default... it's probably not which is a consistency fix from 23.7.6.
Everybody else not on PPPoE I suppose?
Cheers,
Franco
I updated from 23.7.5 to 23.7.7_3 without any issues so far (also PPPoE in Germany, but Telekom Dual IP Stack; and also Draytek, but Vigor 167).
@sbellon yeah the unlucky ones don't have their gateway marked as upstream (mostly likely edited at some point to get it working)
But I haven't done that either, if you are talking about System -> Gateways -> Single -> WAN_PPPOE: "Upstream Gateway". Or what setting are you referring to?
Yes, this. Are you using default gateway switching perhaps?
Cheers,
Franco
System -> Settings -> General: Gateway switching is also off here.
Hmmmmmmm, nope, I'm lost now. :)
Cheers,
Franco
OK, fixed here also by enabling the default gateway (was disabled throughout).
@Franco Enabling upstream gateway for PPPoE worked for me as well, thank you very much!
@franco Would you advise me to a) set Upstream Gateway, b) set Gateway switching, c) set both, or d) never touch a running system? ;-)
I have the same setup as in OP ... but without the issues. I also don't have those gateway settings enabled.
I've looked at a test system. I'm not entirely sure what's happening. Maybe this "problem" only exhibits when you have more than one gateway (others for internal purposes perhaps) and not make clear that you want the WAN gateway to be upstream so it falls back to the wrong one?
Generally I would recommend marking at least the primary WAN connection as "upstream" in any installation.
Cheers,
Franco
And for Dual IP stack, I assume one IPv4 and one IPv6 gateway should be marked? Or does it only apply to the IPv4 one (if the IPv6 one is DHCPv6 and not PPPoE)?
Yes, this pertains to both IP families.
Cheers,
Franco
FYI - In my configuration there are in fact two gateways (one internal to access the DSL modem) and no IPv6.
OK, that means it could prefer the internal one when it has to decide which one to use (because both are not marked upstream).
Cheers,
Franco
Hello,
I had the same issue, almost 2 or 3 times lost pppoe after latest update in a day. also my default gateway already checked. And have only 1 gateway
attached error log.
help would appreciated
thnx
This doesn't look related at all, attached kernel panic:
db:0:kdb.enter.default> show pcpu
cpuid = 2
dynamic pcpu = 0xfffffe0095bc69c0
curthread = 0xfffffe00ef704900: pid 15917 tid 100461 critnest 2 "python3.9"
curpcb = 0xfffffe00ef704e10
fpcurthread = 0xfffffe00ef704900: pid 15917 "python3.9"
idlethread = 0xfffffe0017905560: tid 100005 "idle: cpu2"
self = 0xffffffff82c12000
curpmap = 0xfffffe00ef6dd518
tssp = 0xffffffff82c12384
rsp0 = 0xfffffe00ed6f0000
kcr3 = 0x2d71b1000
ucr3 = 0x2d7007000
scr3 = 0x2d7007000
gs32p = 0xffffffff82c12404
ldt = 0xffffffff82c12444
tss = 0xffffffff82c12434
curvnet = 0
db:0:kdb.enter.default> bt
Tracing pid 15917 tid 100461 td 0xfffffe00ef704900
kdb_enter() at kdb_enter+0x37/frame 0xfffffe00ed6ef810
vpanic() at vpanic+0x182/frame 0xfffffe00ed6ef860
panic() at panic+0x43/frame 0xfffffe00ed6ef8c0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe00ed6ef920
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00ed6ef980
calltrap() at calltrap+0x8/frame 0xfffffe00ed6ef980
--- trap 0xc, rip = 0xffffffff80d5310a, rsp = 0xfffffe00ed6efa50, rbp = 0xfffffe00ed6efb10 ---
cache_fplookup() at cache_fplookup+0x20a/frame 0xfffffe00ed6efb10
namei() at namei+0x124/frame 0xfffffe00ed6efbc0
kern_statat() at kern_statat+0xf6/frame 0xfffffe00ed6efd00
sys_fstatat() at sys_fstatat+0x2f/frame 0xfffffe00ed6efe00
amd64_syscall() at amd64_syscall+0x10c/frame 0xfffffe00ed6eff30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00ed6eff30
--- syscall (552, FreeBSD ELF64, fstatat), rip = 0x825595b1a, rsp = 0x8209db9d8, rbp = 0x8209dbb00 ---
So if not running PPOE at all, and I have 2 gateways (dual WAN provider), should I be checking upstream gateway at all or on both or just one?
Pick the preferred one or none at all if the system should chose one for you.
Mark multiple as upstream if you use default gateway switching so it can use these to change between lines during downtimes (but it also requires the gateway monitor).
Cheers,
Franco
What can i do about it?
thnx
Quote from: franco on November 01, 2023, 12:23:50 PM
This doesn't look related at all, attached kernel panic:
db:0:kdb.enter.default> show pcpu
cpuid = 2
dynamic pcpu = 0xfffffe0095bc69c0
curthread = 0xfffffe00ef704900: pid 15917 tid 100461 critnest 2 "python3.9"
curpcb = 0xfffffe00ef704e10
fpcurthread = 0xfffffe00ef704900: pid 15917 "python3.9"
idlethread = 0xfffffe0017905560: tid 100005 "idle: cpu2"
self = 0xffffffff82c12000
curpmap = 0xfffffe00ef6dd518
tssp = 0xffffffff82c12384
rsp0 = 0xfffffe00ed6f0000
kcr3 = 0x2d71b1000
ucr3 = 0x2d7007000
scr3 = 0x2d7007000
gs32p = 0xffffffff82c12404
ldt = 0xffffffff82c12444
tss = 0xffffffff82c12434
curvnet = 0
db:0:kdb.enter.default> bt
Tracing pid 15917 tid 100461 td 0xfffffe00ef704900
kdb_enter() at kdb_enter+0x37/frame 0xfffffe00ed6ef810
vpanic() at vpanic+0x182/frame 0xfffffe00ed6ef860
panic() at panic+0x43/frame 0xfffffe00ed6ef8c0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe00ed6ef920
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00ed6ef980
calltrap() at calltrap+0x8/frame 0xfffffe00ed6ef980
--- trap 0xc, rip = 0xffffffff80d5310a, rsp = 0xfffffe00ed6efa50, rbp = 0xfffffe00ed6efb10 ---
cache_fplookup() at cache_fplookup+0x20a/frame 0xfffffe00ed6efb10
namei() at namei+0x124/frame 0xfffffe00ed6efbc0
kern_statat() at kern_statat+0xf6/frame 0xfffffe00ed6efd00
sys_fstatat() at sys_fstatat+0x2f/frame 0xfffffe00ed6efe00
amd64_syscall() at amd64_syscall+0x10c/frame 0xfffffe00ed6eff30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00ed6eff30
--- syscall (552, FreeBSD ELF64, fstatat), rip = 0x825595b1a, rsp = 0x8209db9d8, rbp = 0x8209dbb00 ---
Same as this apparently... https://forum.netgate.com/topic/182617/crash-reporter
Problem is the stack trace doesn't tell us much. Worse is that FreeBSD 14 appears to crash in the same way indicating that this is not fixed...
Cheers,
Franco
Dear all,
may you are interested in.
I faced the same issue "No internet connection" after update.
Even though I've only one gateway I had to check the "Upstream Gateway" checkbox, afterwards everything worked again.
Next issue I had was during the next reboot. Again the same issue and I had to "uncheck and check" the same checkbox again to make it work again.
br
Well I had (and have) internet connection (I could for example web surf to 1.1.1.1), but I did not have DNS name resolution. So I think there is at least two different issues here...
> Next issue I had was during the next reboot. Again the same issue and I had to "uncheck and check" the same checkbox again to make it work again.
Misconfigured default gateway switching when using a single gateway and monitoring it? If it's down it will not be used.
Cheers,
Franco
Hi franco.
May I explain it a bit more in detail:
Before update:
- 2 Gateways configured (1xPPPoE, 1xIPv6 Tunnel)
- 1 Gateway enabled (PPPoE) and active
- Upstream gateway - disabled (was never enabled since years)
- Disable Gateway Monitoring - enabled
- IPv6 Gateway disabled
After update:
- No internet access possible. Initially I thought it is an unbound issue with external name resolution, but when I tried to PING external IP on the sense I got
- "No route to host" message", which points me to the a possible issue with the default route.
- no "default route" after update
- after checking "Upstream Gateway" route was added and it worked again
After next reboot I had to disable "Upstream Gateway"
br
Hi, just upgraded from 23.7.5 to 23.7.8_1, and I also got problems reaching out to the world outside.
Gateway-wise my system is pretty simple. I have two WAN gateways, one for IPv4 and one for IPv6, both created automatically, if I remember correctly. No gateway switching settings (default). I ended up in this thread via https://forum.opnsense.org/index.php?topic=37007.0
After having fumbled around with the "Upstream Gateway" setting and done multiple reboots, I ended up with a little bit of extra explicit gateway config. Before, this element in the config was just
<gateways>
<gateway_item/>
</gateways>
but now has become
<gateways>
<gateway_item>
<interface>wan</interface>
<gateway>dynamic</gateway>
<name>WAN_DHCP</name>
<priority>254</priority>
<weight>1</weight>
<ipprotocol>inet</ipprotocol>
<descr>Interface WAN_DHCP Gateway</descr>
<monitor_disable>1</monitor_disable>
</gateway_item>
<gateway_item>
<interface>wan</interface>
<gateway>dynamic</gateway>
<name>WAN_DHCP6</name>
<priority>254</priority>
<weight>1</weight>
<ipprotocol>inet6</ipprotocol>
<descr>Interface WAN_DHCP6 Gateway</descr>
<monitor_disable>1</monitor_disable>
</gateway_item>
</gateways>
Not entirely sure where/why things stop, but after each reboot of OPNsense, I have to take action to get internet working again. It seems like pretty much every change that enables me to apply the gateway config brings internet/gateway(s) back, regardless of the "Upstream Gateway" setting.
Hi
Sounds pretty similar to my issue. After every reboot I've to configure "something" on the gateway to bring Internet connectivity back.
Br
Restarting the pf service from the dashboard also (temporarily) solves the problem for me.
I'm dealing with this issue as well, any configuration change -- just hitting apply without changing anything -- solves the issue until the next reboot