Messages

136

18.1 Legacy Series / 18.1.10: dpinger activation -how to replace apinger

« on: June 21, 2018, 07:46:36 pm »

Hi there,

with pleasure i noticed that now a package for dpinger is provided with 18.1.10. Do I assume right that for now no GUI support for   dpinger is provided?

If so is there a safe recommendation how to replace apinger with dpinger via console?

Looking forward to your reply

Br br

 

137

18.1 Legacy Series / Re: Error when installing 18.1.9

« on: June 02, 2018, 08:10:39 pm »

Yes, it was - tried the proposal without reboot first, also restart of configd did not change the situation - I simply rebooted and now all is fine ...

Br br

138

18.1 Legacy Series / Re: Error when installing 18.1.9

« on: June 01, 2018, 10:17:37 pm »

Hmmm,

this only shows 'führe aus, bitte warten', and nothing happens ....

Br br

139

18.1 Legacy Series / Re: Error when installing 18.1.9

« on: June 01, 2018, 09:04:03 am »

Thanks Franco,

Will reboot when back home. As I found all files and also the Router Class thought something like that. Interesting enough, 18.1.9 runs normal and also the Router Configis there ...

Dashboard says that 18.1.9. is installed, but I can‘t likely get away the error message without reboot ?!

BR br

140

18.1 Legacy Series / [SOLVED] Error when installing 18.1.9

« on: May 31, 2018, 09:06:20 pm »

Hi there

Get an error when installing 18.1.9. Installation screen hangs with extracting opnsense-18.1.9 and the following error message appears:

Code: [Select]

[31-May-2018 20:58:01 Europe/Berlin] PHP Fatal error:  Uncaught Error: Class 'OPNsense\Core\Routing' not found in /usr/local/opnsense/mvc/app/config/services_api.php:87
Stack trace:
#0 [internal function]: Closure->{closure}()
#1 [internal function]: Phalcon\Di\Service->resolve(NULL, Object(Phalcon\Di\FactoryDefault))
#2 [internal function]: Phalcon\Di->get('router', NULL)
#3 [internal function]: Phalcon\Di->getShared('router')
#4 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle()
#5 {main}
  thrown in /usr/local/opnsense/mvc/app/config/services_api.php on line 87
Any idea how to fix that?

Br br

141

18.1 Legacy Series / Re: em0 watchdog timeout -- resetting / no traffic is being routed

« on: March 17, 2018, 03:01:49 pm »

Hi

at least in my case https://forum.opnsense.org/index.php?topic=4918.0 it turned out at the end to be a hardware issue with the board which could only be fixed by RMA the board to Supermicro (see https://forum.opnsense.org/index.php?topic=5869.msg25622#msg25622)

See also here for a little bit more in depth description https://forum.opnsense.org/index.php?topic=5063.0

Since then, it is rock solid stable. I also experimented a lot around with the sysconf settings in /boot/loader.conf.local before with no sustainable success

Br br

142

18.1 Legacy Series / Re: IGMPProxy1.3 is not starting

« on: March 13, 2018, 10:42:21 pm »

Hi,

how does your config file look like?

can you check whether your /usr/local/etc/igmpproxy.conf has a valid upstream config?

Br br

143

German - Deutsch / Re: OPNSense blockiert ausgehenden POP3 Traffic von fetchmail?

« on: January 06, 2018, 06:38:16 pm »

 Hi Jeen

Hmm - wenn der pop Host per ping erreichbar ist und fetchmail 'connected' sagt würde ich mal auf ein TLS/SSL Thema tippen .... Was sagt denn fetchmail -vvv (Erhöhung des loglevel)?

Br br

144

17.7 Legacy Series / igmpproxy and Telekom Entertain behind Fritzbox - now working

« on: January 02, 2018, 05:58:24 pm »

Hi all,

the same procedure as every year - but this time with progress:  igmpproxy in 17.7 now working with Telekom Entertain and Opnsense behind a Fritzbox as Router. Several topics dealt with that over the last 18 months eg https://forum.opnsense.org/index.php?topic=1968.0,https://forum.opnsense.org/index.php?topic=5295.0.

Over the last year there has been some updates of igmpproxy coming from pfsense space and fed back to freebsd ports, eg https://redmine.pfsense.org/issues/6099. Also, the problems with the correct aging of mcast routes in the table seems to be fixed now. Although not knowing whether all of them are fully reflected in the igmpproxy plugin of the current Opnsense release 17.7.11, I could make it work at least for Telekom Entertain 1.0 (NOT yet proven for the new Telekom Entertain TV 2.0) at least for the following configuration:

                                                                                 ----
                                                                            +-+ S +------> DMZ   <-----> Client
                                                                            |   | W |
Telekom ISP <--> Fritzbox 3490 <--> Opnsense <--+-+ I  +------> LAN    <-----> Client
                                                                            |   | T  |
                                                                            +-+ C +------> WLAN <-----> Client
                                                                                | H  |
                                                                                 ----
The switch supports IGMPv3 snooping and provides separated networks for DMZ, LAN, WLAN via untagged VLANs

After installation of the igmpproxy plugin, the following upstream networks should be configured:

• 193.158.0.0/15
• 87.140.0.0/15
• 224.0.0.0/4

The downstream networks should contain the networks of the LAN side interfaces accordingly.

The resulting /usr/local/etc/igmpproxy.conf should look like eg

Code: [Select]

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint igb1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4
altnet 87.140.0.0/15

phyint igb0 downstream ratelimit 0 threshold 1
altnet 192.168.X.0/24

phyint igb2 disabled
phyint igb3 disabled

Indeed you can also configure more downstream interfaces (in my case disabled here) important is to have ONE single upstream interface with the shown networks .... At the moment, I don't have yet a BNG network connection (migration announced for Q1), might be that then the upstream networks needs to be adapted.

Then, some firewall rules need to be configured:
On WAN interface:

• IPv4 IGMP from all sources, all ports to dest 224.0.0.0/4, all ports, activate extension
• IPv4 UDP from all sources, all ports to dest 224.0.0.0/4, all ports, activate extension

On LAN

• activate also extensions on all general rules

Then, very important, under Interfaces->WAN, the box 'block private networks' may NOT be ticked. Otherwise, Opnsense igmpproxy does not see the IGMP Queries from the Fritzbox anymore which prevents in time answers with member reports from the Opnsense and the Fritzbox stops the UDP stream after 2-3 mins.

In my config, TV can be seen stable on all devices in my LAN and WLAN with the vlc player. Thanks to IGMPV3 snooping capable switch, the additional traffic load on the LAN is neglectible ....

I will go for testing of direct connected Opnsense to Draytec Modem (leave out fritzbox) in the next step; as well I am currently working on a full igmpv3 implementation on the downstream side (this seems to be a prerequisite to make Entertain TV 2.0 work)...

Br br

145

17.7 Legacy Series / Re: Update 17.7.8: apinger and ipv6 gateway monitoring not working

« on: November 23, 2017, 10:53:56 am »

Hi franco,

nope it does - i am running two identical hardwares, one with 17.7.7_1 and one with 17.7.8.. This is seen only on the 17.7.8 engine.

Br br

146

17.7 Legacy Series / Update 17.7.8: apinger and ipv6 gateway monitoring not working

« on: November 22, 2017, 09:07:38 pm »

Hi there,

after upgrading to 17.7.8, ipv6 gateway monitoring is not working after reboot anymore. apinger.conf does not contain any target ... entry for the ipv6 gateway, only vor ipv4.

Simply restarting apinger does not help in my case.

Fix has been by going into system->gateways->all, then go into the config page for the ipv6 gateway and press Save. Then restart apinger and the target .... entry is in apinger.conf again. however, it is wrong one address (Link local WAN interface not Link Local WAN gateway).

With the next automatic restart, it went back to the correct values again

I can reproduce this when rebooting

Br br

147

17.7 Legacy Series / [SOLVED] IPv6 and letsencrypt

« on: October 26, 2017, 10:37:39 pm »

Hi there,

I am running a configuration like

FritzBox<-->opnsense (dmz interface) <--> web server with dyndns.

The web server acts as a public subdomain (sub.example.com)  and shall now get an ssl certificate via letsencrypt. As I have a dual stack running, Dyndns takes the ipv6 address of the Fritzbox as the ipv6 subdomain address. So far so good.

Due to the fact that Dyndns now offers ipv4 AND ipv6 a  DNS AAAA record iss created for the domain and therefore lets encrypts certbot is using ipv6 for certificate installation and renewal; obviously fallback to ipv4 is still not working in case that there is no answer from the server from ipv6. Currently certbot is failing as it does not reach the servers directory via ipv6

As with public ipv6 addresses NAT is no longer the valid method, how do I tell opnsense, that it should 'forward' the Fritzbox ipv6 address to the (public ?) ipv6 address of the webserver?

Looking forward to your reply

Br br

[EDIT] For those who are interested: The workaround is to configure the dyndns client on the FritzBox to update ipv4 only; this eliminates the AAAA record in DNS and letsencrypt is using Ipv4. To do so (here for dyn.com) Goto the Fritzbox in Internet->Freigaben->Dyndns and select user defined;  then put the following URL in the field:
https://members.dyndns.org/nic/update?hostname<DOMAIN>&myip<ipaddr>&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
Click apply and then wait for 5 min; the AAAA record has been disappeared; certbot renew then runs fine ....

148

17.7 Legacy Series / Re: Opnsense hardware keeps craching

« on: October 09, 2017, 09:31:32 am »

Hi all,

there is a two year long running thread in pfsense wrt to the X11SBA-LN4F Mainboard

https://forum.pfsense.org/index.php?topic=98230.0.

There also some backgrounds are described (see inputs from user 'engineer')

I have been affected too from this and saw precisely the same issue:
(see also here: https://forum.opnsense.org/index.php?topic=5063.0)

after a few weeks of stable operations, I got a watchdog timer reset on at least one NIC (most WAN) and then the entire machine crashed. No debug output, if there were luck, SOMETIMES an watchdog reset message has been thrown to console (only visible in debug mode)

I RMA the board to Supermicro (which was HW Rev. 1.1) and got a new one with HW Rev. 1.2 and a BIOS Update to 1.0c.

Since then, the entire machine is absolutely stable, I have an uptime of 180 days by now and no crash since then at all.

I bought meanwhile a second board, same revision, same BIOS and made the same experience ....

So a check could be worthwhile (if you have this board running what I assume from your description (tbc)) which HW version you have and which Bios Version. Perhaps an RMA/update might also be helpful for you

Br br

149

17.7 Legacy Series / Re: [SOLVED] Adding IPv6 static route for rc.newwanipv6 fail

« on: October 02, 2017, 09:46:18 pm »

Super, thats great!

No further error also on my productive environment, stable gw monitoring and static routes to DNS;

Br br

150

17.7 Legacy Series / Re: [SOLVED] Adding IPv6 static route for rc.newwanipv6 fail

« on: September 28, 2017, 04:42:50 pm »

 

I let it run in my productive environment up to then and let you know if something particular happens too

BR Br