Messages

I'm seeing an odd issue with PPPoE connections using a VLAN where they don't connect properly ... but when I go and start a tcpdump on the interface everything is connected on to capture the handshake etc, things connect.  Initially I thought this was just coincidence, but I've reproduced this multiple times.  Connections on the same interface work fine without VLANs, so it's specifically when VLANs are added to the mix.

Hardware is a PC Engines apu2, running OPNSense 20.7.4.

ISP has configuration which allows multiple PPPoE sessions on different VLANs (to which they then bind different IP's to for public access), so we have a session on the "main" interface (igb2) for a "shared" IP, and then a single vlan at present setup which doesn't connect until a tcpdump on igb2 is started.  This occurs whether the main "shared" connection is enabled or not so that seems irrelevant. 

Happy to provide configuration files and logs if required, please just specify what you need. Also happy to do any testing needed, as it's easily reproducible here!

Tested with a MicroTik router separately to verify that it wasn't anything else on the network or at the ISP end.

Upgraded from 19.1 to 19.7.2, no issues.

Gateways encountered an issue, as per this thread - https://github.com/opnsense/core/issues/3625. Applied the patches.  That got them appearing again in admin, however, IPV4 one is always disabled and hitting enable doesn't work.

dpinger service either doesn't appear in the list, or just refuses to start :/ Can't seem to find any config file or logs for it.

I've been noticing that flowd_aggregate.py script is pushing my opnsense hard of late.
I've tried a reset of the data but it reoccurs after a few days.

Any reasons to this? It's not consistent, nor does there appear to be any real pattern to it.
Didn't appear pre 19.1.4.

Hardware is a PC Engines apu4c4:
4GB RAM
AMD GX-412TC SOC (1Ghz)

Thanks Franco!

So, just to be doubly sure, the underlying script that is being called will run with root privileges?

What user do the scheduled jobs, for example those created as in https://forum.opnsense.org/index.php?topic=11798.msg53551, run under?

Done :) #66

Been doing some digging, and it seems this is a "feature" that's been added to Squid to validate connections against things like NAT tables to confirm its a "safe" request.
http://www.squid-cache.org/Doc/config/host_verify_strict/


The problem is by doing the port forward for transparent proxy it breaks the check (or so it appears).

Looks like other vendors have hit this, and patched:

https://github.com/NethServer/dev/issues/5348


Any chance of OPNSense patching?
Causes  a lot of problems with SNI inspection - I really don't want to do full SSL decrypt due to having to then maintain a long no-bump list, but the SNI inspect doesn't really work because of this and intermittent failures.

Has anyone had any success getting an IPSec VPN setup compatible with the built in Windows 10 client ?

Fraid the patch didn't work.
I think I've found it though...

Two issues;

NAT on automation and hybrid was NOT generating any rules:

root@firewall:~ # pfctl -sn
nat-anchor "zabbix-agent/*" all
no rdr proto carp all
no rdr on re0 proto tcp from any to (re0) port = https
no rdr on re0 proto tcp from any to (re0) port = http
no rdr on re0 proto tcp from any to (re0) port = ssh
rdr on re1 inet proto tcp from any to (re1) port = 5341 -> 192.168.0.112 port 5341
rdr on re1 inet proto tcp from any to (re1) port = 32400 -> 192.168.0.198 port 32400
rdr on re1 inet proto tcp from any to (re1) port = 10050 -> 192.168.0.102 port 10050
rdr on re1 inet proto tcp from any to (re1) port = 10051 -> 192.168.0.102 port 10051
rdr-anchor "zabbix-agent/*" all

Changing it to manual, and creating a WAN rule generated the following nat rule set:

root@firewall:~ # pfctl -sn
nat on re1 inet all -> { 151.229.241.160, 192.168.5.2 } port 1024:65535 round-robin
nat-anchor "zabbix-agent/*" all
no rdr proto carp all
no rdr on re0 proto tcp from any to (re0) port = https
no rdr on re0 proto tcp from any to (re0) port = http
no rdr on re0 proto tcp from any to (re0) port = ssh
rdr on re1 inet proto tcp from any to (re1) port = 5341 -> 192.168.0.112 port 5341
rdr on re1 inet proto tcp from any to (re1) port = 32400 -> 192.168.0.198 port 32400
rdr on re1 inet proto tcp from any to (re1) port = 10050 -> 192.168.0.102 port 10050
rdr on re1 inet proto tcp from any to (re1) port = 10051 -> 192.168.0.102 port 10051
rdr-anchor "zabbix-agent/*" all

I had a virtual IP configured, but not used - and this was being picked up by the nat rule as above - removing this corrects the NAT rule nat on re1 inet all -> 151.229.241.160 port 1024:65535 which gives me working internet again!

Upgrade completed through the WebGUI without any errors, however, after the upgrade completed NAT was non-functional.

I could ping the firewall, DHCP etc all working, but no NAT was occurring.  Firewall was indicating a default deny rule being hit on cases.

Cleared the firewall back to factory, and changed just the LAN interface IP - this caused NAT to fail.

Cleared the firewall back to factory, applied a config override on WAN interface (needed due to options required for Fibre Modem), and again, NAT failed.

It seems it will only run with NAT with no interface changes - assume this is unexpected?
Is there any configuration diagnostics that I can perform (bearing in mind only the above have been altered on this testing, no previous config!), I'm happy to capture logs etc when I'm not going to impact users. At the minute I'm trying to decide if I downgrade back to v17, or try a completely blank install of v18 (and not an upgrade).