Messages

106

23.7 Legacy Series / Re: Restore problems - weird restore

« on: November 14, 2023, 07:27:31 am »

If I check /conf/config.xml the manual gateway I made, to point to the ISP router, is still in the config after restore:

Code: [Select]

    <gateway_item>
      <interface>wan</interface>
      <gateway>192.168.1.1</gateway>
      <name>WAN_VODA</name>
      <priority>255</priority>
      <weight>1</weight>
      <ipprotocol>inet</ipprotocol>
      <interval/>
      <descr/>
      <defaultgw>1</defaultgw>
    </gateway_item>
.... the above is NOT in the backup file I took.

107

23.7 Legacy Series / Restore problems - weird restore

« on: November 14, 2023, 07:24:36 am »

Good Morning,

So, I had some issues with one of my fibre providers and of course they wanted me to connect  their router - rather than using my own.

I re-configured the WAN interface on opnsense to be 'em0' and regular DHCP - rather than PPPoE over a VLAN - set a manual gateway to the ISP router, made some firewall changes.  Before doing so, I took a backup.

This morning I went to restore the original setup, as the ISP router didn't resolve the problem.  Shock horror.

However, upon restoring the config I took before, the firewall rebooted, I seem to end up with a 'mash up' of the changes I made and the original config?

For example, the WAN interface is still em0/DHCP (although PPPoE has been restored, it's not assigned to the WAN) and the various firewall rules are not back as they were (had some gateway rule changes).

If I view the saved backup XML file, the em0/DHCP WAN and the manual gateway I made, are NOT present in the backup config.  So I was hoping/assuming, they shouldn't be in the restored config!

Is there a restore log anywhere?  So I can see if it's puking on something in particular?  Nothing really 'fancy' just a basic firewall.

I tried a restore via the UI and also via option 13 on the CLI menu.  In a bit of a mess at the moment, my fail safe seems to have failed - anyone any ideas? 

Thanks,

108

General Discussion / Re: Virgin Media UK - 'Super' Hub 4 - Modem Mode

« on: November 03, 2023, 10:40:58 am »

I haven’t had a Hub 4 for over a year, but I no longer had issues after these settings.

109

23.7 Legacy Series / Re: Group Gateway help

« on: October 28, 2023, 12:11:44 pm »

I believe you are confusing 2 separate 'things':

- Gateway groups
- Default gateway and/or default gateway switching

Tiers - corresponds to Gateway groups
Priority - corresponds to default gateway/default gateway switching

For gateway groups, you need to have a firewall rule to match the traffic you want to use the gateway group, with the gateway set on the rule to the gateway group.  The 'Tiers' will then be respected for the traffic that matches this rule.

Or, ignore gateway groups, leave your firewall rules on * gateway, then enable default gateway switching - with each gateway tagged as upstream and the appropriate priority - then, the priorities come into play.

If you use gateway groups, without default gateway switching, the default route on the firewall itself will never be changed. 

Gateway groups apply only to the traffic that matches - with the gateway group set as the gateway on the rule that matches - on the firewall rules ingress to the port/interface that first matches.  A * gateway on a rule, does not use a gateway group - it uses the default route on the firewall (priorities).

Use cases:

a) You want all traffic to fail over:

- Default Gateway switching, (not groups), enabled, is probably the best way forward
- Default Gateway candidates all/both tagged as upstream, appropriate priorities set for each gateway
- All firewall rules set to * gateway

b) You want to leave some traffic as only ever using 1 gateway and failover some devices only:

- Default gateway switching, disabled
- One gateway tagged as upstream, i.e only 1 gateway is a default gateway candidate
- Add a specific rule, with the gateway set to the gateway group, of the traffic that you want to fail over. Perhaps a source group/alias of your computers, phones, etc
- Other devices, for example IoT, streaming boxes, with no gateway group set, still on * gateway, would lose internet access until the default route returns

b) Is probably more useful when bandwidth on the secondary WAN is limited, 4G for example.

110

23.7 Legacy Series / Re: Home Assistant, Matter, Aquara Hub, and HomeKit Woes on different VLANs

« on: October 28, 2023, 10:29:20 am »

I have no experience with the Aquara Hub.

... but, something I had to do for a Xiaomi Air Filter, was to add a NAT rule so that HomeAssistant (in another VLAN/subnet) appeared to be on the same local network as the Xiaomi (as it will only talk to/respond to devices in its local subnet).  Was a bit of a head-scratcher for a while.

Basically an egress NAT rule, so that Home Assistant appears to be the IoT firewall IP (on the IoT VLAN), when it tries to reach the Xiaomi (which has its own IP, on the IoT VLAN/subnet).  In my case, anyway.

It should be possible to work out if it's an mDNS problem, however:

- Connect a computer to the same VLAN as the device that needs to 'see' the announcement
- Run a mDNS debug tool on that VLAN
- See what it sees..

mDNS is just the announcement of where to find the announcing device, on what port, sometimes things like supported encryption, etc, however.  I'm not clear from your post, if you've allowed the actual communication ports between the device(s)?

On macOS, I've used the below (Discovery) a number of times for helping to troubleshoot (or, just to rule out mDNS as being at fault) similar problems:

https://apps.apple.com/gb/app/discovery-dns-sd-browser/id1381004916?mt=12

111

23.7 Legacy Series / Re: OPNsense 23.7.7 Upgrade Problem

« on: October 25, 2023, 12:41:51 pm »

Usually a good idea to read the release notes before attempting an upgrade ... *hint hint*

... perhaps the part about OpenSSL and 3rd party repos, requiring package rebuilds?

112

23.7 Legacy Series / Re: Dpinger broken

« on: October 24, 2023, 08:57:09 am »

For me, enabling 'Disable Host Route' on my problematic gateway (I think) helped.

Maybe my setup is similar to yours:

- 2 ISP connections
- 2 separate opnsense routers
- Failover network between them, to facilitate 'cross' failover if 1 ISP is down

On the failover network, just a /30 between then, I have to enable 'Disable Host Route' - otherwise, if I reboot router a), Dpinger on router b) sees the gateway as down but does not recover to an 'online' status on it's own (without a Dpinger restart).

I mentioned at the beginning 'I think it helped' - I can now reboot either router, the other router detects the gateway as down and now DOES recover when the rebooted-router comes back on line (without a Dpinger restart).

113

23.7 Legacy Series / Re: PPPoE over vlan MTU not honored

« on: August 12, 2023, 10:10:01 am »

I opened the below, in case anyone else is seeing this/unable to resolve:

https://github.com/opnsense/core/issues/6738

114

23.7 Legacy Series / Re: PPPoE over vlan MTU not honored

« on: August 12, 2023, 09:09:59 am »

Under:

Interfaces -> Point to point -> Devices -> Edit the PPPoE device

Then 'Show advanced options' do you have anything set under the 'Link Parameters ( vlan01 )'?

I didn't previously for things to work and still don't at the moment - as the MTU should already be set on vlan01, for the interface assignment, also the WAN/PPPoE interface where it shows 1508 calculated 1500.

115

23.7 Legacy Series / Re: PPPoE over vlan MTU not honored

« on: August 12, 2023, 08:34:51 am »

Unfortunately this didnt seem to fix it for me, after rebooting the machine this morning I still had to open the WAN/PPPOE interface and click 'Save', PPPoE then reconnects with 1500.

- WAN_PHYS set to 1512 (WAN_PHYS attachment)
- WAN set to 1508, with the PPPoE (WAN attachment) calculated to 1500.  As it should be.

The above used to work 'as is', I was on 22.7 before upgrading to 23.7 latest.

Then, after reading your post, I assigned the 'WAN_VLAN' and set 1508 there (WAN_VLAN attachment).  Rebooted this morning, but still came up at 1492 - open the WAN interface, click save, PPPoE reconnects, back to 1500.

116

23.7 Legacy Series / Re: pppoe jumbo frames -RFC 4638

« on: August 11, 2023, 07:50:59 pm »

Previously you didn't need to actually assign the VLAN interface - the post above suggests that a fix/work around is to now assign the VLAN interface, then re-set the 1508 MTU (1512 on the physical) there.  This didn't used to be needed.

Have done this, will reboot/test again the morning.

117

23.7 Legacy Series / Re: PPPoE over vlan MTU not honored

« on: August 11, 2023, 07:36:19 pm »

Thank you - I have just assigned the VLAN interface, enabled it and set the MTU to 1508. 

This didn't seem to be required previously, hopefully it will fix the issue - will test tomorrow morning.

118

23.7 Legacy Series / Re: pppoe jumbo frames -RFC 4638

« on: August 11, 2023, 05:42:32 pm »

Can confirm I see the same.

Checking ifconfig output I see:

- Physical, 1512
- VLAN, 1500
- PPPoE, 1492

119

23.7 Legacy Series / Re: let out anything from firewall host itself rule.

« on: August 10, 2023, 10:35:30 pm »

Pretty sure it's 'non quick'.

If you hover over the lightning bolt, it says 'last match'... which means specific first match rules (with quick) will take priority.

It's also an outbound rule, rules you apply to zones match inbound to the interface/zone.

120

Hardware and Performance / Re: Saturating 1Gbit NIC creates packet loss

« on: August 10, 2023, 10:21:47 pm »

I had a Ubiquiti UDM-PRO before on same WAN connection without packetloss when saturating it, so I was wondering why.

Don't they call it 'Smart Queuing' or something?  Wouldn't be surprised if it is fq_codel based, many such implementations are.

Likely they already do some form of queuing out of the box, might be wrong.