Ran some tests on this a few different ways this morning. It appears to work fine when pfSense is set to use PAP or MD5-CHAP to the server, but fails when using MSCHAPv1 or MSCHAPv2. I've tried a few different ways to encode the values (UTF-8, UTF-16) and in varying places around the auth request but no luck so far. It works using any method I've tried with radtest at the CLI, so it appears to be an issue either in the PHP RADIUS code (PEAR modules for Auth_RADIUS or the CHAP specific module(s)) or how it's called when pfSense forms auth requests with these types of passwords. I created https://redmine.pfsense.org/issues/10352 to track it down eventually but at least at the moment I'm not seeing anything that looks like it would be a quick fix.

The most common way people add a LAN gateway by mistake is if they add a new internal interface in the webgui or they set a new IP address on the existing LAN from the console menu. In both those situations you are presented with an option to add a gateway. There is text guidance explaining that only 'WAN' type interfaces should have a gateway but it's easy to think you are entering the gateway clients should use and add the LAN IP as a gateway. That's incorrect but we see a lot of people do that. Only WAN interfaces should have a gateway defined on them directly. That is adding a gateway for the firewall itself not a gateway for clients to use. pfSense uses the presence of a gateway on an interface to identify it as a WAN and will add automatic outbound NAT rules to it. Steve

I've managed to get the OpenVPN connected now. It appears the issue was at the OpenWRT/OpenVPN end (due to my inexperience with it). I didn't use the bare config file but rather the "wizard" (if you can call it that, its more of a text entry box). This is the correct config needed on the OpenVPN end: option dev 'tun' option keepalive '10 60' option verb '3' option persist_tun '0' option persist_key '0' option port '1194' option auth 'SHA256' option cipher 'AES-128-CBC' option enabled '1' option secret '/etc/openvpn/dcvpn.key' list route '10.94.43.0 255.255.255.0' option ncp_disable '1' list remote '12.64.66.45' option comp_lzo 'yes' option ping_timer_rem '1' option proto 'udp' option ifconfig '10.94.32.2 10.94.32.1' And pfSense: verb 1 dev-type tun dev-node /dev/tun2 writepid /var/run/openvpn_server2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 12.64.66.45 ifconfig 10.94.32.1 10.94.32.2 lport 1194 management /var/etc/openvpn/server2.sock unix route 10.94.48.0 255.255.255.0 secret /var/etc/openvpn/server2.secret compress lzo

How do you have pfSense configured here? Is it just routing between those subnets? Is there any NAT happening? What is the default gateway clients in the 192.168.1.X subnet? 192.168.1.1? Does that have a static route to 10.10.1.X via the pfSense WAN IP? It sounds like you have some asymmetric routing happening. You may see blocked traffic in the pfSense firewall log if so. Steve

@hwcltjn said in Cannot install/update packages on fresh install: traceroute files00.netgate.com That also fails for me in exactly the same way but I am able to update packages. It succeeds if I traceroute using ICMP though: traceroute -I files00.netgate.com Steve

Did you install this using ZFS? Did you use GPT or MBR? If it's booting EFI, you might also try this in /boot/loader.conf.local: efi_max_resolution="1280x800" Or something lower like 800x600 in either that or my previous example. Lastly you might also try this form for /boot/loader.conf.local: exec="gop set 3"

There is no limit from the software. The only limit is your hardware. The primary limitation will be total throughput. Secondary to that will be RAM since each user connection will require more memory. We don't have any definitive quantification of those values, however. OpenVPN may have them published somewhere. Also for remote access VPNs with user authentication, the pfSense user manager isn't geared well toward large numbers of users. For that kind of scenario, consider using an authentication server. FreeRADIUS on pfSense may be slightly better here, but optimally it would be an authentication server behind the firewall on another device. Something using FreeRADIUS backed by a database (e.g. DaloRADIUS) or LDAP (e.g. slapd), AD, etc.

@stephenw10 Thanks - that is exactly what I need!

Thanks Steve. I don't see one so created one under Issue #10348.

Yes it will return anything that's defined locally directly. So host overrides and dhcp leases if you have that enabled. Steve

If you are seeing the password option when you go to the user manager it's because you are using an admin account that is not actually admin and hitting this bug: https://redmine.pfsense.org/issues/9541 There is a patch but you can just manually go to the user manager url as shown there. If all changes you make don't report errors but also don't seem to apply you almost certainly have the User - Config: Deny Config Write permission set on your account. Steve

I you're only using the reverse proxy in order to host several sites at one IP address couldn't you just port forward 9418 to the server and use git directly for this? Steve

Depending on what you run on this Server, maybe building a DMZ would be a good option for you...now when you have two subnets anyway. There is a GREAT hangout done by jimp on Creating a DMZ: https://www.netgate.com/resources/videos/creating-a-dmz-on-pfsense.html -Rico

We had another brief instance today where pfsense stopped authenticating over LDAP, so I can rule out leap-day shenanigans. My best guess is that our virtual infrastructure is doing something funky during backups. I have idea idea why that would cause a problem that persisted for hours last time, but only a few minutes today, but I think it's safe to rule out pfsense. Thanks for your help @jimp !

Thanks dotdash for the answer. My firewall is not yet in production, I will test your information and I will return it soon. Once again, thank you for your kindness.

Hello team. Short update: it looks like the "net.inet.udp.maxdgram" is actually doing what I expected it to do. I double checked my lab layout and I found a piece of incorrect configuration. With the lab correctly setup, I can see that in case "net.inet.udp.maxdgram" is larger than my 3.1kb made up record, the DNS response from the auth server is one large UDP frame in case "net.inet.udp.maxdgram" is smaller, the communications switch to TCP. So, net.inet.upd.dgram seems to be the way to go. Thank you all for your attention, my best wishes of a good weekend to you all. Manuel

Yeah, you can't really do that. One solution here would be to put the SG-1100 on a different subnet on a different interface on the Watchguard. That way all clients in LAN trying to reach it (or coming from it) will send their traffic to the Watchguard as their default gateway and it will route the traffic to the SG-1100. The traffic takes the same route in both directions, there is no asymmetry. Effectively that is creating a transport subnet for the SG-1100 (and any other router) to reside on. As long as you only have routers and no hosts in the transport subnet you will probably be OK. Steve

Thanks again.. the solution posted by @jimp worked for me!