Messages

Thanks @davesworld - Great stuff!

I'd forgotten what my Vigor130 interface even looked like!  :o

Perhaps check out https://www.freebsd.org/cgi/man.cgi?tuning

dcol also has a more specific tuning thread here. I found it helpful: https://forum.opnsense.org/index.php?topic=6590.0

If I remove the OPNsense box from the equation, I consistently get the faster 900 - 940 Mbps speed test results.

When you add the OPNsense box, is the modem/connection interface bridged properly? No double NATing or other double-ups?

[emulated]

I do have a full set of firewall rules set up for each of the vlans, but I don't think this would enable the dhcp serving appropriately.

I honestly do not remember requiring any other settings. My untagged emulated ESXi lan network is exactly that; untagged... but yours is bare metal. It may act differently due to brand/drivers/configuration.

Check this howto out: https://nguvu.org/pfsense/pfsense-baseline-setup/ it includes an interesting tidbit under the "Setup VLAN Interfaces" heading (pfsense but I'd assume OPNsense may act the same with these 'inconsistent' NICs):

We need to identify a parent interface before we start configuring VLANs, the parent interface refers to the physical interface where the VLANs will reside, e.g igb3 or ix0. Due to inconsistent behaviour with some NICs, you should not assign your parent interface to any interface in pfSense. Its sole function is to act as the parent interface to the VLANs we create.

Might be worth a shot... but means you won't have an untagged interface at all.

No probs!

My log shows the following:

Code Select Expand


Jul 29 22:27:52 dhcpd: DHCPOFFER on 192.168.0.6 to 34:xx:a9:7f:xx:8b (LiLaLaptop) via re0
Jul 29 22:27:52 dhcpd: DHCPDISCOVER from 34:xx:a9:7f:xx:8b (LiLaLaptop) via re0
Jul 29 22:27:44 dhcpd: DHCPOFFER on 192.168.0.6 to 34:xx:a9:7f:xx:8b (LiLaLaptop) via re0
Jul 29 22:27:44 dhcpd: DHCPDISCOVER from 34:xx:a9:7f:xx:8b (LiLaLaptop) via re0
Jul 29 22:27:40 dhcpd: DHCPOFFER on 192.168.0.6 to 34:xx:a9:7f:xx:8b (LiLaLaptop) via re0
Jul 29 22:27:39 dhcpd: DHCPDISCOVER from 34:xx:a9:7f:xx:8b via re0


I doubble checked the configured DHCPv4 config an the range is correct (192.168.10.X)?! So why does the firewall offer an IP from the DEFAULT VLAN?

Any Idea?

It certainly looks like your VLAN tag is being dropped - hence OPNsense offering an IP from your untagged 192.168.0.X network. (This was the same symptom as I previously experienced when I neglected to add the relevant ports to the vswitches within my ESXi install). Is there any way to check whether your tags are getting through at all? Perhaps a manual setup on one of the laptops to confirm it can access only via that set vlan?

Did you delete the physikal interface (on my APU-Board it`s called "re0") in the "Interface" -> "Assignment" menu? So you only have the VLANs (for example VLAN10 on re0) or did you leave it?

I have left the untagged interface and in fact have a number of machines connected to it - one of which is my AP similar to how yours seems to act.

Are you running all the latest unifi firmware & controller software? I'm assuming you've checked that first?

Ha! Good work!  :)

I'll start by saying I have slightly different gear here to use as examples: Unifi Switch 24 and an UAP-AC-Pro. I am currently running firmware 3.9.42.9152 on both. The Unifi Controller is version 5.8.24 and runs in a VM alongside my OPNsense 18.1.12 ... but lets try to nut it out anyway!

My interfaces appear to be set up similar to how you showed yours. IPv4 only, upstream gateway as none. All the vlans are on the same base LAN interface which is untagged.

The VLAN interfaces have static IPs (192.168.X.100). For each VLAN a DHCP range from 192.168.X.1 to 192.168.X.99 is configured.

The static IPs, in my case are 172.17.X.1/24 and the DHCP server range is set 172.17.X.100-199 with all other settings on that page blank. I'm guessing your differing X locations may just have been typos?

In the Unifi Controller, I have added Networks as 'VLAN Only' for each vlan, IGMP snooping enabled but the DHCP guarding disabled. In Profiles -> Switch Ports, I have a profile set up for each vlan where the native network for each vlan is simply selected as the associated vlan network (I have not selected any of the other vlans as tagged networks - I did intend playing with this eg. VOIP but never found the need).

On the switch ports, I have simply selected the appropriate port profile created above.

I *think* I may have used this how-to when configuring things - but it was a long time ago and I may have changed a few things! https://nguvu.org/ubiquiti%20unifi/ubiquiti-unifi-setup/

My DHCP log shows the following during a connection:

Code Select Expand

Jul 27 20:59:24 dhcpd: DHCPACK on 172.17.20.103 to 00:1b:24:9f:xx:05 (nc2400) via em2_vlan20
Jul 27 20:59:24 dhcpd: DHCPREQUEST for 172.17.20.103 (172.17.20.1) from 00:1b:24:9f:xx:05 (nc2400) via em2_vlan20
Jul 27 20:59:24 dhcpd: DHCPOFFER on 172.17.20.103 to 00:1b:24:9f:xx:05 (nc2400) via em2_vlan20
Jul 27 20:59:23 dhcpd: DHCPDISCOVER from 00:1b:24:9f:xx:05 via em2_vlan20
What does your log show?

G'day,

There is no chance your OPNsense is in a virtual environment is there? e.g. ESXi

I had something similar occur but it was because I had forgotten to set the virtual switch ports appropriately... so no VLAN tags got through. ::)

I added a logging floating 'pass' 'both' rule applied to both the vpn & wan interfaces:

Code Select Expand

IPv4 * This Firewall * 212.32.245.132 * * ALLOW OPNsense Update

I can now see the passed traffic during an update check attempt e.g.

Code Select Expand

WAN Jul 24 20:48:13 61.xxx.xxx.xx:3118 212.32.245.132:80 tcp USER_RULE: ALLOW OPNsense Update
WAN Jul 24 20:48:10 61.xxx.xxx.xx:62638 212.32.245.132:443 tcp USER_RULE: ALLOW OPNsense Update


The update gui now sits for far longer prior to eventually either timing out or aborting internally. I may leave it this way and check the results when there is actually an update to do...

The problem won't go away by expecting fixes from our side when we don't even know what's wrong.

Ha! Yes, no expectation that that would occur. Figured if this is the only thing that doesn't appear to work on my network but that I had a work-around, then it was simply easier to just perform the work-around!

Anyhow, it appears fetch is now working for me from the cli?!

Code Select Expand

root@OPNsense:~ # fetch https://pkg.opnsense.org/FreeBSD:11:amd64/18.1/sets/changelog.txz.sig                                                                                                                                                 
changelog.txz.sig                             100% of 1332  B 8498 kBps 00m00s

Meanwhile the gui reports:

Code Select Expand

Timeout while connecting to the selected mirror.

My network is firewalled such that all general traffic exits via a VPN gateway. Root cli traffic does not exit in this manner as proven with low pings to local websites i.e. it is exiting via clearnet wan. Are we confident that the gui fetch command is exiting via clearnet rather than the vpn gateway?

Interesting. Oh well... I guess I will continue to update via cli for the moment then!

Cheers!

More refined question. How do I whitelist DNS queries from my LAN clients on OPN box ? (forget VPN).

Another thought - have a look at using Dnsmasq DNS (the DNS forwarder in OPNsense, rather than Unbound resolver) - I have a feeling it may support whitelisting.

Is there a reason you would not make use of the integrated VPN functions within OPNsense - rather than running multiple separate instances? I'm aware of a few VPN providers that offer multiple connections on the same account, but within a single LAN it would still be more efficient to share a single router based VPN connection between LAN clients than to run them all independently. 

I'm guessing one use case may be that you wish independent LAN clients to appear as though they are in various locations around the world - possibly to avoid geoblocking or whatever... but lets say you have a default VPN gateway set up on the router, you can use firewall/nat rules to push certain LAN clients out through to clearnet (and then run independent VPN clients on these) OR just set up multiple VPN interfaces on the router if the exit regions are consistent and direct to whatever ones you wish on a per client basis.

This link may be of interest (but won't give you what you want): https://www.unbound.net/pipermail/unbound-users/2010-May/001168.html

Here is a pfSense walk-through that might give you a few ideas. It details multiple DNS servers (forwarder & resolver AND clearnet bypass), along with how to port forward such that your LAN clients are forced to use particular DNS IPs: https://nguvu.org/pfsense/pfsense-baseline-setup/

No luck with Waterfox, Firefox or Chrome from OpenSUSE Linux desktops.

The main issue is that the gui fails to see any updates - and records no history of the updates done via cli or console. I.e.

Code Select Expand

System: Firmware
Firmware status check was aborted internally. Please try again.
Updates
Version Date
18.1.10 2018-06-21
18.1.9 2018-05-31
18.1.8 2018-05-17
18.1.7 2018-05-03

And yet the main dashboard correctly reports:

Code Select Expand

System Information
Name OPNsense.local.lan
Versions OPNsense 18.1.12-amd64
FreeBSD 11.1-RELEASE-p11
LibreSSL 2.6.5

The system continues to function, and I have no issue upgrading via cli but it would obviously be preferable if the gui functioned as expected!

Thanks for the help Franco,

The output of those were provided in the first post but just for completeness:

Code Select Expand

root@OPNsense:~ # pkg update -f
Updating OPNsense repository catalogue...
Fetching meta.txz: 100%    1 KiB   1.5kB/s    00:01   
Fetching packagesite.txz: 100%  135 KiB 138.1kB/s    00:01   
Processing entries: 100%
OPNsense repository update completed. 506 packages processed.
All repositories are up to date.

root@OPNsense:~ # pkg upgrade -n
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (16 candidates): 100%
Processing candidates (16 candidates): 100%
Checking integrity... done (0 conflicting)                                                                                                           
Your packages are up to date.

So no apparent issue with updating from the cli or from the console. Is there any difference in the way the gui performs the update? Would it for example use a different gateway to what is used by the cli?