Messages

1681

20.7 Legacy Series / Re: Change user to other LDAP server

« on: September 10, 2020, 03:35:01 pm »

if i understad it right, not at this moment.
https://github.com/opnsense/core/blob/master/src/www/system_usermanager_import_ldap.php
php takes first ldap-server in array and try to take users from there
try to remove first server from System-Settings-Administration-Auth Server and start new import

1682

20.7 Legacy Series / Re: Every N-hours no more routing

« on: September 10, 2020, 10:16:01 am »

hmm. looks like that connection lost before "right at 17.20: 17"
right after your 4G failover LAN change IP and firewal been reloaded:
"Curl error occurred: Operation timed out after 15008 milliseconds with 0 out of 0 bytes received"
have you set "Dynamic state reset" to "on"?
have you tried to wait some time for connection reestabilsh?
--

Not sure why, and from where the resolv.conf is updated.

its just part of dhclient-script
it write this to log before ALLOWOVERRIDE check

1683

20.1 Legacy Series / Re: Let’s Encrypt EAP-PEAP WiFi certificate

« on: September 09, 2020, 01:29:20 pm »

will switch to my own PKI (currently use for inside services. for services available via the Internet i use LE)

1684

20.1 Legacy Series / Re: Let’s Encrypt EAP-PEAP WiFi certificate

« on: September 09, 2020, 01:19:15 pm »

I dont trust it, noone should

why?

1685

20.7 Legacy Series / Re: Every N-hours no more routing

« on: September 09, 2020, 11:14:04 am »

ok.
since we want to understand what is blocking traffic, check that logging is enabled in blocking fw rules

1686

20.1 Legacy Series / Re: Let’s Encrypt EAP-PEAP WiFi certificate

« on: September 09, 2020, 10:13:35 am »

GreenMatter, untrusted or not verified?
its how ios works
https://framebyframewifi.net/2017/01/29/use-lets-encrypt-certificates-with-freeradius/
first comments

1687

20.7 Legacy Series / Re: High Packet Loss When Using VPN in OPNsense Virtualized in vSphere 7.0

« on: September 09, 2020, 09:38:58 am »

oops. sorry. it's probably on server side log only.
do you have access to server logs?
and have you already tried --mssfix?

1688

20.7 Legacy Series / Re: High Packet Loss When Using VPN in OPNsense Virtualized in vSphere 7.0

« on: September 09, 2020, 08:13:02 am »

verbose 4 is realy huge )
is there messages like "AEAD Decrypt error: bad packet ID.."?

1689

20.7 Legacy Series / Re: High Packet Loss When Using VPN in OPNsense Virtualized in vSphere 7.0

« on: September 09, 2020, 07:42:11 am »

what's in the openvpn log?
have you tried tcp?

(1)  Inside Interfaces > [VPN Interface].  Do I need to set this for WAN interface too?
(2)  Inside Firewall > Settings > Normalization.  And this section is confusing to me, and I am not sure how to properly set it.
(3)  Inside VPN > OpenVPN > Clients, where I can try to set MTU and MSS directly in the VPN connection settings.

(3) I think

1690

20.7 Legacy Series / Re: NAT reflection issues with double NAT

« on: September 08, 2020, 06:58:05 pm »

yes, sorry, asymmetric routing will not work in any way. client expects reply from public ip(
I don't think this is an OPN bug - OPN is exactly generating the rule you are asking for.
Interface groups usage is not an opnsense feature. its PFs feature (and OPN creates interface groups through ifconfig. not just stores in its configuration )
it's just that pf doesn't interpret the rule the way you want/expect it to. I have read pf man several times and do think that pf cannot do what you need (use the ip of the actual outgoing interface). this logic is not mentioned anywhere.  pf wait for (( redirhost | "{" redirhost-list "}) at this place of the rule. just addresses - no interfaces info at all. (so you cant tell pf "use current egress interface ip". he wants ip or list of ips)
long story short "Translation/target" is not interface-type field. its address-type field. and InterfaceGroup feature shouldnt work here by design.
so the opnsense team needs to write some feature that will "expand" your interface group and generate a set of rules (for each interface in group)? or ... just hide the interface groups in the Translation / Target dropdown (or add some more info text to the help div).
imho all this is just a slight difference in understanding of  the purpose of interface groups and where to use them

1691

20.7 Legacy Series / Re: vpn access to intranet blocked by Default deny rule

« on: September 08, 2020, 05:23:15 pm »

on 192.168.1.61 add static route to 10.0.8.0 through 192.168.1.1

1692

20.7 Legacy Series / Re: NAT reflection issues with double NAT

« on: September 08, 2020, 09:31:31 am »

Yes. this is exactly what I meant when I talked about the confusion when using groups in nat rules. it is not clear how to use the group in translation/target. shortly - no way)
and I do not think that Source Hash will help here. it will assign the translated address to the source, but it is not clear which address it will assign.
if we consider specifically your ASCII scheme and all servers in the igb1 network, then you can try to change your rule like this:
nat on igb1 inet from (AnyLAN: network) to any -> (igb1: 0) port 1024: 65535

or try to abandon nat and try asymmetric routing

and one more moment:
in rdr rule
rdr on AnyExternal inet proto tcp from any to <Home_WAN> port = http -> <DBWSRV> port 80 round-robin
i dont see "AnyLAN". why dont you want to  reflect client packet at AnyLAN interfaces?

1693

20.7 Legacy Series / Re: NAT reflection issues with double NAT

« on: September 07, 2020, 09:32:51 pm »

ASCII is wonderful 
became a little clearer.
sorry, one unrelated question: what will vlan do in this configuration?
on topic. Am I right? do you have only one port forward rule and it contains only external interfaces ? in this case, try to add intrenal interfaces to this rule. why do we need to drive a packet from the internal network to the external interface and back to the internal ones. let it go from one internal to another
if this is not enough and nat rule with a interfaces group still does not work, then you will need to look at the actual rules that the opnsense generates for pf. while the GUI does not allow it (I just requested this feature https://github.com/opnsense/core/issues/4331). Please, in the shell, give the command pfctl -snat and share the result. it will be interesting how opnsense registers nat rule with interfaces group

1694

20.7 Legacy Series / Re: Static route troubles

« on: September 07, 2020, 05:52:24 pm »

looks like state tracking
if i understand your network right, SQL will reply to clients in 172.19/16 network bypassing opnsense
(SQL->microtik->client).
why dont you include route to 172.18/16 in clients DCHP options and let them work with 172.18/16 network without opnsense?

1695

20.7 Legacy Series / Re: Every N-hours no more routing

« on: September 07, 2020, 05:01:01 pm »

Hi!
what's in the firewall log?
are all daemons running?
what's in the General log?