Messages

Sorry for my late reply, I got inundated with some more pressing projects. Thank you, that sounds like a good possible work around. I appreciate your input.

Well, the issue with that is this is a production server with our main app on there so it needs to be completely accessible by clients on the network. I could do some fancy routing configurations and it "might" work but this is an old AS/400 app and there are a lot of hard coded IP settings in there and if it is even possible to get working, support would never support it when there was an issue. Besides, it would be so much easier to have an exclude option in the proxy for specific hosts for these situations. I understand the security concern but I'm just using the web filtering to keep the honest folks out of trouble anyway because anyone who really knows what they are doing can find other ways.

I am trying to figure out if there is a host exclude list when using the Squid Proxy. Basically I have a server behind the firewall that needs an unfiltered port 443 access to download updates from IBM. It will not work through any sort of proxy as it has to have its own certificate and such so it needs a direct connection. Is there any way that I can bypass the Squid proxy for a particular host behind the firewall like that?

Okay so other than memory use being a bit higher than I like, the rest of the hardware in that performance chart seems to be doing okay but that chart doesn't really show disk performance. If you are using a standard HD then you might try an SSD instead and see if that will help the swap file performance and therefore help your overall performance throughput. As a comparison, I am running a dedicated standalone hardware box with an i5-7400, which is only 4 cores at 3.0 GHz, 8GB of RAM and an SSD and my Internet speed is only 300/35 but I am getting the full speed with IPS enabled. It may be that there is a cap on max throughput that the software package can handle? It may be that the extra layer of running a virtualized box may have an impact? Have you heard what anyone else with a faster Internet speed is getting in comparison to you?

Did you disable all hardware offloading as the help on the IPS line warns you to do before enabling?

So Demusman is correct, you have to tag the traffic from your NIC in order to access that VLAN 15 network and hence reach the DHCP server and receive an address. As stated, this can be tricky at the PC. It is usually done in the switch as you have done already.

I would venture a guess that you might be having some blockages with the DHCP server being trusted and passing through in the switch or the DHCP firewall rules in the OPNsense. I did not research your switch directly but I have dealt with these kinds of issues with some TP-Link switches in the past where the DHCP server for the VLAN was not configured as trusted in the switch and it was blocking it. Look into this and see if that could be your issue.

This problem has only started occurring since the last couple of updates. The setup has worked great for many many months up until recently. We are on 22.7.7 currently but this has been a problem for at least this and the last update. Primary WAN is cable and that is pretty rock steady for the most part. Secondary WAN is T-Mobile Home Internet. What happens is I plug it all in and test the failover which works flawlessly and Internet access is great on either WAN and all DNS lookups do fine. I leave it setup and invariably the next morning I have the early birds calling me to say the Internet is down or having trouble so I walk one of them through unplugging the secondary WAN Ethernet and all returns to normal. Unfortunately, I have not been on the premises when this happens so I don't know what OPNsense is saying at the time but when I check the logs I don't see anything that sticks out but maybe I don't have logging setup correctly. Please help me figure this out if you can. Thanks.

Strange problem and I am too tired and hungry tonight to be able to figure it out after a long day of working. Hopefully some of you smarter people than me can chime in and help me. The scenario is this: I updated from 22.7.4 to 22.7.5 earlier this evening. After that I could not reach Google searches at all nor google.com. It gives me an ERR_CONNECTION_CLOSED error. I reverted back to 22.7.4 and reloaded my last auto backup of the system from Sep. 21 2022. I still cannot reach anything Google search related. I have tried turning off the Web Proxy completely and bypassing it in the firewall rules and everything I can think of at the moment and nothing seems to work. It is not a DNS issue as far as I can tell because I can ping the URL all day long. Something is glitching or misconfigured somewhere but for the life of me I cannot figure it out. I remember having this same or a very like issue when I first started piping SSL through the web proxy but that has been a long time ago now and I can't remember how I solved it back then. Please help me with your marvelous ideas. Thanks a bunch in advance. 

Thanks, I'll look into that.

Actually, now I have figured out what happened and what my mistake was. I previously had the VPN setup using the aforementioned subnet and all was working fine. Sometime after that, I migrated a guest WiFi network to the opnsense firewall and chose the 10.10.10.0 subnet. All was working fine until I went to rebuild and then got the conflicting results because that guest network is a separate VLAN that is not allowed access to the main network so it was sort of allowing access and sort of blocking it I suppose. Anyway, that now explains why changing the subnet fixed the issue. Thanks for looking into it with me.   

So I think I have it fixed now. I was using a 10.10.10.0/24 as the tunnel network. Nothing I tried would allow more than one client to access the network resources at a time. All could connect fine to the VPN but no access for anyone but whoever got in first. So after countless rebuilds of the VPN server, I got to thinking what if something is just corrupt in the firewall concerning that subnet so I rebuilt it using the wizard and chose the example network they give which is 10.0.8.0/24 and now everything seems to be working. So I don't know if there is some sort of bug in the latest version update that effects VPNs using that tunnel network but it makes no sense that it worked but it did. This needs to be brought to someone's attention to look into for sure.

Okay here's my scenario: I've had openvpn up and running using Viscosity clients for several years now without any issue. My self signed certs expired on the same day I updated opnsense to the latest version. I noticed there were a lot of warnings about deprecated settings and protocols I was using so I decided to just rebuild the openvpn server. I did it manually the first time but have since rebuilt it three or four times and I've used the wizard for most of those. The issue I'm having is that I can connect to the VPN just fine but I cannot access anything beyond that. If I restart the VPN server then I can get to the remote network but only that first client. If another client tries to connect, they get the same issue until I restart the openvpn server on the firewall. I have gone through it so many times and everything looks right but just for kicks I have tweaked everything I could think of and still no dice. Please somebody help me before I pull all of my hair out and get run out of town by users and management. Thanks in advance. Also, DNS never works across the VPN but that is really not that important as I am only using the VPN for remote desktop access so I can use reserved IPs for that.

So to update everyone, it must have been a strange quirk with 22.1.3 because since I updated to 22.1.4 the problem has gone away. Very strange behavior and I still can't figure out how it was doing it but I'm glad it is gone.

So I'm not entirely sure if this is related only to 22.1 or not but I have only recently noticed it. If I do a speed test on any OOKLA based site or service, (i.e. speedtest.net, speedtest Windows or mobile apps, or on the Cox Cable site - my primary ISP), according to the results, it appears to use my failover WAN and not my primary even though it still states it is using Cox as the provider. When I say it appears to, I mean that the results show ping times and speed results consistent with my failover instead of my primary. Also, if I temporarily disable my failover then the results match the primary as expected. All other traffic seems to be routed correctly including other brand speed tests. As far as I know, I have not done any specific routing for those sites and this has just recently started happening. Any thoughts on why this strange phenomenon is taking place? I sure don't have any.

So I'm not quite certain why you want to switch firewall boxes with just the loss of WAN. This seems a bit overkill for that scenario. Typically you would only want to switch firewall boxes if one of those boxes actually goes down. So I say this wondering if the functionality you are looking for actually exists in the software. I have not personally attempted to do what you are looking at doing so I don't really have anything helpful to add.