hail,
I have a soekris 5501-70 running:
OPNsense 15.7-i386
FreeBSD 10.1-RELEASE-p14
LibreSSL 2.2.0
This box has two cable wan, and there is the point. I get once a day a lost connection. Even though all looks fine, I can't ping from the main wan. I have to go on interfaces UI and click on "release" e "renew". This happened today once, and tomorrow too.
Has anyone seen this ?
I have a strangely high load of, at least, 1.00. Does this have any to do ?
I come from the project that is sibling to this, I don't know if there is any problem on saying it (so I don't), and I want to give this a try. So far, a bit slow on the 5501-70, but still testing.
About the packages, how can I test or run them ?
All I need so far is the vnstat package. I found some links to git, but I can't find how to install them. The pkg add on CLI won't find vnstat :(
thanks for the project, its a great project !
none
Is this a PPPoE connection going down? It sounds like a scheduled provider timeout. Without further details it's hard to say if the scripts don't pick it up or if there is something else going on with the setup/deployment.
A load of 1.00 means your scheduler is always has exactly 1 process running. For a system that can be normal, even without producing high CPU time. It could be IO blocking or a daemon process misbehaving. Can you post top output for us? This Soekris CPU is quite slow, too, except that the RAM is ok with 512 MB. Maybe the load average is to be expected.
15.7 is rather old. I reckon this is nano? Have you had trouble upgrading?
There are only two test plugins at the moment, see the other thread:
https://forum.opnsense.org/index.php?topic=1187
Quote from: franco on August 11, 2015, 10:14:48 AM
Is this a PPPoE connection going down? It sounds like a scheduled provider timeout. Without further details it's hard to say if the scripts don't pick it up or if there is something else going on with the setup/deployment.
franco, both internet pipes are cable dhcp-only. I used ISP two on OpenBSD dedicated machine and both on pfSense on this same soekris and never got this dhcp issoe. Please don't get me as comparing opnsense to pfsense, just showing info I got. I am a big opnsense fan already :)
Quote
A load of 1.00 means your scheduler is always has exactly 1 process running. For a system that can be normal, even without producing high CPU time. It could be IO blocking or a daemon process misbehaving. Can you post top output for us? This Soekris CPU is quite slow, too, except that the RAM is ok with 512 MB. Maybe the load average is to be expected.
I know this box is not that fast. I see this on other scenarios, mostly on heavy traffic (50Mbps is heavy for it). The other test machines are quite close to it :(
last pid: 79597; load averages: 1.11, 0.89, 0.81 up 5+15:49:58 11:06:38
47 processes: 2 running, 45 sleeping
CPU: 57.8% user, 0.0% nice, 38.1% system, 4.1% interrupt, 0.0% idle
Mem: 17M Active, 165M Inact, 99M Wired, 46M Buf, 190M Free
Swap:
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
15362 root 1 52 0 34672K 21360K piperd 7:07 14.89% php-cgi
55786 root 1 52 0 34672K 20208K accept 6:39 8.98% php-cgi
58143 matheus 1 20 0 11232K 2424K RUN 0:00 0.29% top
54914 unbound 1 20 0 30044K 20488K select 123:16 0.00% unbound
61146 root 1 20 0 25300K 13848K kqread 52:44 0.00% lighttpd
37954 root 1 20 0 12044K 4220K select 26:22 0.00% miniupnpd
24573 root 1 20 0 10200K 1872K bpf 13:21 0.00% filterlog
78627 _dhcp 1 20 0 10160K 1976K select 8:11 0.00% dhclient
5309 root 1 20 0 10140K 1884K select 5:20 0.00% syslogd
50230 root 1 20 0 10020K 1932K select 1:07 0.00% radvd
99069 root 1 20 0 10212K 1768K select 0:34 0.00% ping
27792 root 1 52 0 10432K 2048K wait 0:34 0.00% sh
208 root 1 20 0 24132K 14300K accept 0:29 0.00% python2.7
51849 root 1 20 0 12972K 13000K select 0:15 0.00% ntpd
59957 dhcpd 1 20 0 16224K 9128K select 0:12 0.00% dhcpd
82917 root 1 20 0 10084K 1832K nanslp 0:05 0.00% cron
61049 matheus 1 20 0 15396K 5092K select 0:03 0.00% sshd
76974 root 1 52 0 10160K 1852K select 0:01 0.00% dhclient
31133 root 1 20 0 10036K 1696K nanslp 0:01 0.00% getty
32647 root 1 20 0 10036K 1696K nanslp 0:01 0.00% getty
30961 root 1 20 0 10036K 1696K nanslp 0:01 0.00% getty
31661 root 1 20 0 10036K 1696K nanslp 0:01 0.00% getty
31365 root 1 20 0 10036K 1696K nanslp 0:01 0.00% getty
32327 root 1 20 0 10036K 1696K nanslp 0:01 0.00% getty
32282 root 1 20 0 10036K 1696K nanslp 0:01 0.00% getty
31944 root 1 20 0 10036K 1696K nanslp 0:01 0.00% getty
61864 root 1 52 0 30576K 15256K wait 0:01 0.00% php-cgi
23252 root 1 52 0 9924K 1556K nanslp 0:01 0.00% minicron
215 root 1 20 0 8976K 3360K select 0:01 0.00% devd
61242 root 1 49 0 30576K 15256K wait 0:00 0.00% php-cgi
84848 root 1 20 0 10796K 2984K pause 0:00 0.00% csh
32850 root 1 22 0 10424K 2184K wait 0:00 0.00% login
8157 root 1 22 0 15396K 4572K select 0:00 0.00% sshd
84875 _dhcp 1 20 0 10160K 2000K select 0:00 0.00% dhclient
79066 root 1 52 0 10160K 1848K select 0:00 0.00% dhclient
46298 root 1 21 0 12644K 4172K select 0:00 0.00% sshd
62041 matheus 1 20 0 10796K 2784K pause 0:00 0.00% csh
Quote
15.7 is rather old. I reckon this is nano? Have you had trouble upgrading?
Yes, its nano. I never tried upgrade so far. I get the message when I click to "check for", but never clicked. I will try then. Is there any screen before it beginning the update that tells me the new version found ?
Quote
There are only two test plugins at the moment, see the other thread:
https://forum.opnsense.org/index.php?topic=1187
I saw that. So no way to install vnstat now, right ?
As my cable providers do some accounting, I like to measure it by myself. Hence the need for vnstat :(
thanks,
none
We need to know more about your WAN links still. Are both those WAN links running to the same modem or different modems?
Also are you referring to your DHCP isn't auto-renewing on the LAN side or is the DHCP not auto-renewing on the service provider side?
I can add vnstat to the package mirror in time for 15.7.8, how does that sound?
I know that early 15.7 had issues with DHCP on nano specifically, although I'm not 100% sure it applies to your case. I'm going to release a semi-official nano 15.7.8 image later today or tomorrow that fixes the headaches we had with nano in early 15.7 to see if that improves things for you.
Quote from: Shaok353 on August 12, 2015, 01:43:07 AM
We need to know more about your WAN links still. Are both those WAN links running to the same modem or different modems?
Also are you referring to your DHCP isn't auto-renewing on the LAN side or is the DHCP not auto-renewing on the service provider side?
Hi :)
I have two ISP's, each one has its own modem. I suspect just the link on the WAN interface has this issue.
My dhcp issue is not on LAN side, I have it all fine there.
thanks :)
Quote from: franco on August 12, 2015, 07:17:46 AM
I can add vnstat to the package mirror in time for 15.7.8, how does that sound?
Super !
I have quite simple needs on my home firewall. I have some clients outside that runs pfsense, so my goal is to try opnsense so I can change those clients in the future, if all runs fine. I will see the best choice and use it :)
Quote
I know that early 15.7 had issues with DHCP on nano specifically, although I'm not 100% sure it applies to your case. I'm going to release a semi-official nano 15.7.8 image later today or tomorrow that fixes the headaches we had with nano in early 15.7 to see if that improves things for you.
That's great for me, and I can try it later today.
BTW, I had to go back to pfsense on the 5501-70 as I tried to upgrade it and got some errors. Nothing was displayed on the WebUI, but now I can't make the dhcp server to run again, and the wife begun complaining about no internet on mobile phone :) So, as I had few to no time to deal with it, I got the old CF card back.
I can download the new nano image and use the config on the 15.7 and test it.
BTW, again, I tried to upgrade, got the package list and then clicked on upgrade. From that point on, nothing changed on UI, no progress bar, nothing would tell me that it was running. Is that the way ? I got no progress bar whatsoever, or nothing alike to inform me how my upgrade was.
thanks,
Quote from: none on August 12, 2015, 04:39:34 PMI will see the best choice and use it :)
Fair enough. We could ask for nothing more. :)
Quote from: none on August 12, 2015, 04:39:34 PM
BTW, I had to go back to pfsense on the 5501-70 as I tried to upgrade it and got some errors. Nothing was displayed on the WebUI, but now I can't make the dhcp server to run again, and the wife begun complaining about no internet on mobile phone :) So, as I had few to no time to deal with it, I got the old CF card back.
I can download the new nano image and use the config on the 15.7 and test it.
BTW, again, I tried to upgrade, got the package list and then clicked on upgrade. From that point on, nothing changed on UI, no progress bar, nothing would tell me that it was running. Is that the way ? I got no progress bar whatsoever, or nothing alike to inform me how my upgrade was.
I think you're seeing the bug that the initial nano had WRT package manager with all its side effects: the package database disappeared underneath the "/var" RAM disk and could not be accessed, causing empty updates and dhcp server issues. Let's start fresh with 15.7.8.
I was going to do it now but I realised I misplaced my Serial-to-USB adapter. Meh, tomorrow it is.
Quote from: franco on August 12, 2015, 04:59:29 PM
Quote from: none on August 12, 2015, 04:39:34 PMI will see the best choice and use it :)
Fair enough. We could ask for nothing more. :)
Quote from: none on August 12, 2015, 04:39:34 PM
BTW, I had to go back to pfsense on the 5501-70 as I tried to upgrade it and got some errors. Nothing was displayed on the WebUI, but now I can't make the dhcp server to run again, and the wife begun complaining about no internet on mobile phone :) So, as I had few to no time to deal with it, I got the old CF card back.
I can download the new nano image and use the config on the 15.7 and test it.
BTW, again, I tried to upgrade, got the package list and then clicked on upgrade. From that point on, nothing changed on UI, no progress bar, nothing would tell me that it was running. Is that the way ? I got no progress bar whatsoever, or nothing alike to inform me how my upgrade was.
I think you're seeing the bug that the initial nano had WRT package manager with all its side effects: the package database disappeared underneath the "/var" RAM disk and could not be accessed, causing empty updates and dhcp server issues. Let's start fresh with 15.7.8.
I was going to do it now but I realised I misplaced my Serial-to-USB adapter. Meh, tomorrow it is.
hehehe. Deal !
Looking forward to downloading this :)
none
Hi Franco,
where Will I find the image ?
I looked for it on some mirrors, not found so far :)
thanks,
none
Here is the test snapshot... 4 GB image for i386 for now, but it works the same with config import/export.
https://pkg.opnsense.org/snapshots/OPNsense-15.7.8-LibreSSL-nano-i386.img.bz2
We are probably giving out new images for all combinations with 15.7.9 because we want a few firmware upgrade tweaks to go in which are not in 15.7.8 yet.
Hi Franco,
I got it installed ok. And installed the vnstat package. Thanks :)
The config.xml from previous version worked fine, but I can't find how to access the vnstat page.
Is there a page for vnstat ?
I will try to reinstall the package anyway.
thanks,
none
That's why we differ in terminology between packages and plugins. Packages come from FreeBSD and only denote services. Plugins can tie these packages into installable plugins with a GUI on top. Long story short, the plugin for vnstat is missing for now. We are, however, just now adding code to allow plugins to live in the GUI menu and access control.
Hi,
a bit far from this plugin/package issue, is this normal ?
last pid: 75940; load averages: 2.84, 2.97, 2.83 up 0+22:17:46 13:22:25
48 processes: 5 running, 43 sleeping
CPU: 41.3% user, 0.0% nice, 56.5% system, 2.2% interrupt, 0.0% idle
Mem: 21M Active, 118M Inact, 42M Wired, 25M Buf, 290M Free
Swap:
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
64663 unbound 1 78 0 21852K 14184K RUN 7:05 19.48% unbound
81434 root 1 77 0 34792K 19328K RUN 0:07 16.36% php-cgi
522 root 1 21 0 34900K 21932K RUN 5:04 7.96% php-cgi
1809 root 1 22 0 12040K 4040K select 1:44 5.08% miniupnpd
29823 _dhcp 1 20 0 10160K 1940K select 0:40 1.07% dhclient
16919 _dhcp 1 20 0 10160K 1944K select 0:21 0.59% dhclient
50062 root 1 20 0 11232K 2428K RUN 0:00 0.20% top
56865 root 1 20 0 13016K 6580K kqread 17:58 0.00% lighttpd
38802 root 1 20 0 10200K 1872K RUN 1:51 0.00% filterlog
5138 root 1 20 0 10140K 1892K select 0:36 0.00% syslogd
74116 root 1 20 0 10020K 1776K select 0:12 0.00% radvd
197 root 1 20 0 23744K 13488K accept 0:10 0.00% python2.7
32363 matheus 1 20 0 15388K 4704K select 0:02 0.00% sshd
4650 root 1 22 0 15388K 4580K select 0:01 0.00% sshd
50254 root 1 52 0 10432K 2040K wait 0:01 0.00% sh
5951 root 1 22 0 10084K 1816K nanslp 0:01 0.00% cron
57582 root 1 52 0 30696K 14456K wait 0:00 0.00% php-cgi
56964 root 1 52 0 30696K 14528K wait 0:00 0.00% php-cgi
72574 dhcpd 1 20 0 16224K 9128K select 0:00 0.00% dhcpd
81603 root 1 20 0 11232K 2444K select 0:00 0.00% top
68862 root 1 20 0 10796K 2976K pause 0:00 0.00% csh
60941 root 1 22 0 10424K 2184K wait 0:00 0.00% login
24442 root 1 22 0 10160K 1840K select 0:00 0.00% dhclient
49055 matheus 1 23 0 10416K 2132K wait 0:00 0.00% su
59956 root 1 20 0 10036K 1700K nanslp 0:00 0.00% getty
60110 root 1 20 0 10036K 1700K nanslp 0:00 0.00% getty
60265 root 1 20 0 10036K 1700K nanslp 0:00 0.00% getty
60030 root 1 20 0 10036K 1700K nanslp 0:00 0.00% getty
60875 root 1 20 0 10036K 1700K nanslp 0:00 0.00% getty
60495 root 1 20 0 10036K 1700K nanslp 0:00 0.00% getty
60686 root 1 20 0 10036K 1700K nanslp 0:00 0.00% getty
60759 root 1 20 0 10036K 1700K nanslp 0:00 0.00% getty
203 root 1 20 0 8976K 3368K select 0:00 0.00% devd
50785 root 1 49 0 9924K 1560K nanslp 0:00 0.00% minicron
63923 root 1 20 0 10796K 3060K pause 0:00 0.00% csh
11987 root 1 38 0 10160K 1832K select 0:00 0.00% dhclient
32525 matheus 1 21 0 10796K 2884K pause 0:00 0.00% csh
66658 root 1 25 0 10432K 1912K wait 0:00 0.00% sh
61117 root 2 20 0 10212K 1760K nanslp 0:00 0.00% sshlockout_pf
61369 root 1 26 0 10432K 2032K wait 0:00 0.00% sh
51444 root 1 27 0 9924K 1556K nanslp 0:00 0.00% minicron
5481 root 1 20 0 12636K 4040K select 0:00 0.00% sshd
27289 root 1 52 0 5832K 1512K nanslp 0:00 0.00% sleep
44739 root 1 20 0 10136K 1740K select 0:00 0.00% inetd
50486 root 1 52 0 9924K 1548K wait 0:00 0.00% minicron
51722 root 1 52 0 9924K 1548K wait 0:00 0.00% minicron
51039 root 1 52 0 9924K 1548K wait 0:00 0.00% minicron
52433 root 1 52 0 9924K 1556K nanslp 0:00 0.00% minicron
load here was above 3. It is slow :(
Versions OPNsense 15.7.8-i386
FreeBSD 10.1-RELEASE-p17
LibreSSL 2.2.2
thanks,
none
ps: a small update on the dhcp issue. I got another dhcp failure as told on the opening post, but this is 22h after boot. So I got some progress here. Is there any update for this image here ? Just tell me and I will test :)
Quote from: franco on August 16, 2015, 05:01:30 PM
That's why we differ in terminology between packages and plugins. Packages come from FreeBSD and only denote services. Plugins can tie these packages into installable plugins with a GUI on top. Long story short, the plugin for vnstat is missing for now. We are, however, just now adding code to allow plugins to live in the GUI menu and access control.
Franco,
if there is anything I can do to help, test and whatever, just say :)
thanks,
Thanks, it would help to know your requirements of a vnstat plugin in terms of what you want to see implemented. We have a few talented contributors that pick up smaller bugs and feature requests so making the request formal on GitHub might speed up the development of said plugin.
Hi franco,
I am half the way to tell opnsense and 5501 won't match. I can't access the webgui now. I get:
last pid: 23672; load averages: 2.06, 2.07, 2.07 up 2+01:35:32 16:40:11
44 processes: 3 running, 41 sleeping
CPU: 88.1% user, 0.0% nice, 9.0% system, 3.0% interrupt, 0.0% idle
Mem: 23M Active, 127M Inact, 47M Wired, 43M Buf, 273M Free
Swap:
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
56865 root 1 76 0 13016K 6728K RUN 38:58 14.70% lighttpd
23421 root 1 52 0 30712K 18832K piperd 0:01 6.98% php
22415 root 1 20 0 11232K 2372K RUN 0:00 0.59% top
68862 root 1 21 0 10796K 2976K pause 0:00 0.29% csh
38802 root 1 20 0 10200K 1876K bpf 5:08 0.00% filterlog
46618 root 1 52 0 34792K 23080K accept 4:23 0.00% php-cgi
1809 root 1 20 0 12040K 4144K select 3:48 0.00% miniupnpd
91538 root 1 52 0 34792K 21500K accept 3:01 0.00% php-cgi
61369 root 1 52 0 10432K 2048K wait 2:07 0.00% sh
29823 _dhcp 1 20 0 10160K 1940K select 1:40 0.00% dhclient
5138 root 1 20 0 10140K 1892K select 1:37 0.00% syslogd
16831 unbound 1 20 0 25948K 14976K select 1:08 0.00% unbound
9500 root 1 52 0 10432K 2048K wait 0:29 0.00% sh
74116 root 1 20 0 10020K 1880K select 0:28 0.00% radvd
197 root 1 20 0 23744K 16300K accept 0:11 0.00% python2.7
5951 root 1 20 0 10084K 1816K nanslp 0:02 0.00% cron
22498 dhcpd 1 20 0 16224K 9128K select 0:01 0.00% dhcpd
The internet is fine so far, but webui is inaccessible.
Are there any other users running this version on 5501-70 ?
thanks,
Please explain to me why you even bother with running such an old piece of hardware.
It only has 512MB RAM in your model, which is known to have installation issues, so you having done that is impressive enough.
That's easy.
I have it. I have two ISP's and both combined sums 15Mbps. So why use a regular dlink, that is far too limited, and not use this ? It is stable and does all I need.
And to settle all, runs on less then 15W :)
no need to retire it so far.
Apart from the issues you're having right now?
You can't even configure it because of the non-working webconfig.
Well,
last version was ok, this is a bug, I suppose, not a feature. So far, I like what I see here, and I am willing to give the stable final production release a try. Then I can decide.
There is always the option to run OpenBSD or FreeBSD native, vanilla version.
thanks,
none, lighttpd is up, are you sure it's not a lockout issue? How are you accessing the GUI, HTTP or HTTPS? Do you see the root menu? Are you sure the boot went okay and wasn't OOM-killed?
I'm building a last test image for 15.7.9 later tonight.
https://pkg.opnsense.org/snapshots/OPNsense-15.7.9-LibreSSL-nano-i386.img.bz2
I've said it in the other thread: last test release, based on 15.7.9.
Images for both amd64 and i386 will be available for 15.7.10. Thank you for your support and feedback so far. :)
Hi Franco,
when 15.7.10 will show up ? I can try it then. I have some issues on opnsense, as said, that makes things here unstable. My wife can't complaint more about her internet access :)
I have dns issues, as related on another topic, and these slowness and dhcp issues on main isp.
I tried to test the WebUI responsiveness on a faster machine, Pentium dual core 1.8GHz and around 4GB ram. As my extra NIC's were usb from Linksys, I could not go much far. The WebUI was faster, that's a good thing (something I expect from the slow soekris), but I couldn't get as far as have both ISP's running. All boot it made me reboot for nic assignment. So I got on a loop where all boot both nic's were re-detected. I don't have how to test them without those usb nic's. As this pc was just a test (I can't have it as firewall 24/7), this is off for some time now. I also noticed that the install media, from usb memstick, wouldn't see the usb nic's. They are detected after the install script starts, so I get just the onboard nic as option in the first install run. When I passed that, I never got to have the WAN interface again. Created interfaces from there are OPTx. I dunno if that messes up something and that led me to no stable usb nics after all (the nic drivers are fine, I used them in other scenarios fine).
Just to help a little here, I must say FreeBSD itself has issues here. Before usb nics were all UEx, when axe based nics were axe0, axe1 and so on, it was easier to use them. Once axe1, I remember them so keep that index. Now they keep swapping. Saw this on vanilla FreeBSD not too long ago, so I guess that's the culprit to every boot opnsense scripts get confused.
Well, I got back to the old FW so far, but I have two cf cards, one being the opnsense test one. Just need to known when I will try it again. Is a problem to use the old cfg file ?
thanks,
none
Not a problem. I understand your concerns. Unbound is being worked on to be more stable, I just pushed a larger rework that needs more testing to get accepted for the stable version. I think that some of your USB nicks are not available on bootup because the kernel driver isn't loaded. That needs to be addressed in /boot/loader.conf. A lot of variables that make this hard to track and find a fix for. We have little time and a lot of priorities. :)
By all means try with 15.7.10 one more time when it's out and if it doesn't work you'll have to wait longer, maybe 16.1 to give it another go. Getting through this with us or spending a few times on waiting for issues to be tackled is the options you have.
Can only get better, right. :D
Cheers,
Franco
Hi franco,
just as feedback, I just installed 15.7.11, and apart from a dhcp disconnect (just as before) less then an hour after boot, the UI is has better responsiveness, the load is way lower (less then 1, by far):
12:51PM up 59 mins, 1 user, load averages: 0.04, 0.10, 0.11
USER TTY FROM LOGIN@ IDLE WHAT
root u0 - 12:05PM - w
even though I have the UI opened on browser.
I will test more, this is the first boot after 15.7.8, but so far is great news. I will follow-up news about dhcp and the vnstat, when possible.
thanks,
none
small update:
the dns issue still stands. The machines that use the alternate gw must use 8.8.8.8 dns :/
I will try changing to dns resolver and see.
thanks,
DNS and DHCP issues may be related. Could it be that at some point the ISP drops the lease and the box won't bother picking a new one?
franco,
I don't know, but could be. I just need to renew dhcp and it is back again. That's on the main ISP. The other, dhcp/cable as well, never shows this behavior. That's odd.
Indeed, do you renew via the GUI button on the interface status page or on the command line?
GUI, on the status->interfaces page.
Ok, thanks. Are there any dmesg lines that seem to indicate why the lease has gone stale? Do you know the lease time the link has?
Log when the link was not ok. I then click renew, and the log is bellow.
vr0 is my lan, vr1 is the default ISP, vr2 is the second isp.
Sep 14 23:44:40 OPNsense dhclient[34470]: bound to 187.61.x.x -- renewal in 5400 seconds.
Sep 14 23:44:28 OPNsense dhclient: Creating resolv.conf
Sep 14 23:44:28 OPNsense dhclient: Adding new routes to interface: vr2
Sep 14 23:44:28 OPNsense dhclient: New Routers (vr2): 187.61.x.y
Sep 14 23:44:28 OPNsense dhclient: New Broadcast Address (vr2): 187.61.x.255
Sep 14 23:44:28 OPNsense dhclient: New Subnet Mask (vr2): 255.255.248.0
Sep 14 23:44:28 OPNsense dhclient: New IP Address (vr2): 187.61.x.x
Sep 14 23:44:26 OPNsense dhclient: ifconfig vr2 inet 187.61.x.x netmask 255.255.248.0 broadcast 187.61.x.255
Sep 14 23:44:26 OPNsense dhclient: Starting add_new_address()
Sep 14 23:44:26 OPNsense dhclient: BOUND
Sep 14 23:44:26 OPNsense dhclient[34470]: DHCPACK from 10.18.0.1
Sep 14 23:44:26 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 255.255.255.255 port 67
Sep 14 23:44:26 OPNsense dhclient: ARPCHECK
Sep 14 23:44:24 OPNsense dhclient: ARPSEND
Sep 14 23:44:24 OPNsense dhclient[34470]: DHCPOFFER from 10.18.0.1
Sep 14 23:44:24 OPNsense dhclient[34470]: DHCPDISCOVER on vr2 to 255.255.255.255 port 67 interval 2
Sep 14 23:44:24 OPNsense dhclient: Removing states through old gateway '187.61.x.x' (new gateway '')
Sep 14 23:44:24 OPNsense dhclient: Comparing Routers: Old: 187.61.x.x New:
Sep 14 23:44:24 OPNsense dhclient: Starting delete_old_states()
Sep 14 23:44:24 OPNsense dhclient: PREINIT
Sep 14 23:44:24 OPNsense dhclient: Deleting old routes
Sep 14 23:44:24 OPNsense dhclient: Removing states from old IP '187.61.x.z' (new IP '')
Sep 14 23:44:24 OPNsense dhclient: Comparing IPs: Old: 187.61.x.x New:
Sep 14 23:44:24 OPNsense dhclient: Starting delete_old_states()
Sep 14 23:44:24 OPNsense dhclient: EXPIRE
Sep 14 23:37:20 OPNsense dhclient[13991]: bound to 187.123.x.x -- renewal in 2195 seconds.
Sep 14 23:37:20 OPNsense dhclient: Creating resolv.conf
Sep 14 23:37:20 OPNsense dhclient: RENEW
Sep 14 23:37:20 OPNsense dhclient[13991]: DHCPACK from 187.123.x.x
Sep 14 23:37:20 OPNsense dhclient[13991]: DHCPREQUEST on vr1 to 187.123.x.x port 67
Sep 14 23:14:04 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 192.168.228.175 port 67
Sep 14 22:58:13 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 192.168.228.175 port 67
Sep 14 22:49:47 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 192.168.228.175 port 67
Sep 14 22:44:57 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 192.168.228.175 port 67
Sep 14 22:42:37 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 192.168.228.175 port 67
Sep 14 22:40:57 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 192.168.228.175 port 67
Sep 14 22:40:13 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 192.168.228.175 port 67
Sep 14 22:39:52 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 192.168.228.175 port 67
Sep 14 22:38:09 OPNsense dhclient[34470]: DHCPREQUEST on vr2 to 192.168.228.175 port 67
Sep 14 23:56:40 OPNsense dhclient[29327]: bound to 187.123.x.x -- renewal in 8525 seconds.
Sep 14 23:56:30 OPNsense dhclient: Creating resolv.conf
Sep 14 23:56:30 OPNsense dhclient: /sbin/route add default 187.123.x.x
Sep 14 23:56:30 OPNsense dhclient: Adding new routes to interface: vr1
Sep 14 23:56:30 OPNsense dhclient: New Routers (vr1): 187.123.x.x
Sep 14 23:56:30 OPNsense dhclient: New Broadcast Address (vr1): 187.123.x.x
Sep 14 23:56:30 OPNsense dhclient: New Subnet Mask (vr1): 255.255.248.0
Sep 14 23:56:30 OPNsense dhclient: New IP Address (vr1): 187.123.x.x
Sep 14 23:56:26 OPNsense dhclient: ifconfig vr1 inet 187.123.x.x netmask 255.255.248.0 broadcast 187.123.x.255
Sep 14 23:56:26 OPNsense dhclient: Starting add_new_address()
Sep 14 23:56:26 OPNsense dhclient: BOUND
Sep 14 23:56:26 OPNsense dhclient[29327]: DHCPACK from 187.123.x.x
Sep 14 23:56:26 OPNsense dhclient[29327]: DHCPREQUEST on vr1 to 255.255.255.255 port 67
Sep 14 23:56:26 OPNsense dhclient: ARPCHECK
Sep 14 23:56:24 OPNsense dhclient: ARPSEND
Sep 14 23:56:24 OPNsense dhclient[29327]: DHCPOFFER from 187.123.x.x
Sep 14 23:56:24 OPNsense dhclient[29327]: DHCPDISCOVER on vr1 to 255.255.255.255 port 67 interval 1
Sep 14 23:56:24 OPNsense dhclient: Starting delete_old_states()
Sep 14 23:56:24 OPNsense dhclient: PREINIT
Sep 14 23:56:24 OPNsense dhclient: Deleting old routes
Sep 14 23:56:24 OPNsense dhclient: Removing states from old IP '187.123.x.x' (new IP '')
Sep 14 23:56:24 OPNsense dhclient: Comparing IPs: Old: 187.123.x.x New:
Sep 14 23:56:24 OPNsense dhclient: Starting delete_old_states()
Sep 14 23:56:24 OPNsense dhclient: EXPIRE
Sep 14 23:56:24 OPNsense dhclient: Removing states from old IP '187.123.x.x' (new IP '')
Sep 14 23:56:24 OPNsense dhclient: Comparing IPs: Old: 187.123.x.x New:
Sep 14 23:56:24 OPNsense dhclient: Starting delete_old_states()
Sep 14 23:56:24 OPNsense dhclient: PREINIT
Sep 14 23:56:16 OPNsense dhclient[55496]: exiting.
Sep 14 23:56:16 OPNsense dhclient[55496]: connection closed
franco,
I kinda got some info about my dns issue on double wan.
It seems the packages goes out without any NAT:
14:00:53.157631 IP 187.61.x.x.12297 > 10.1.1.81.53: 2399+ A? teredo.ipv6.microsoft.com. (43)
14:00:54.170517 IP 187.61.x.x.12297 > 10.1.1.81.53: 2399+ A? teredo.ipv6.microsoft.com. (43)
14:00:55.184505 IP 187.61.x.x.12297 > 10.1.1.81.53: 2399+ A? teredo.ipv6.microsoft.com. (43)
14:00:57.197080 IP 187.61.x.x.12297 > 10.1.1.81.53: 2399+ A? teredo.ipv6.microsoft.com. (43)
14:01:01.206079 IP 187.61.x.x.12297 > 10.1.1.81.53: 2399+ A? teredo.ipv6.microsoft.com. (43)
I have auto NAT on nat page, and my gui shows there are NAT rules for WAN2. I must use DNS outside, (like 8.8.8.8) to browse.
Is this seens anywhere ?
thanks,
Apologies for the delay. I'm not sure what's going on, but I think it's not a larger issue, which makes it harder to pin down the offending line of code. Can we do remote SSH access to the boxes in order to see if anything suspicious can be found?