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!

I would not expect that unless that alias is somehow in use somewhere else.

It looks like the WAN might not be set to dhcp which every interface has to be in AWS. Can you connect from the LAN? From another VM in the LAN perhaps? What was the last change you made? Otherwise I would probably just remove it and re-deploy. It's likely to be quicker than anything else. Steve