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

@stephenw10
Based on the idea you had about why I needed that rule at all, I went ahead and disabled that rule. Everything seems to still be working just fine. Guess that's what happens when you follow some guides on how to do things. The guide I followed was accurate to get the forwarding to work properly, but it was also why I added that NAT rule. If you can, can you update the title of this thread to include [SOLVED] in it, just in case anyone else runs across this. Thanks again for help. :)

It lools like you have either a lot of columns on your dashboard or you're viewing it in a narrow window.

Using less columns should make it wider.

Steve

4 days uptime. Looks like it was a fault in the ISP router!

Squid is a package you install in pfSense to proxy and log http/s traffic.
https://docs.netgate.com/pfsense/en/latest/cache-proxy/index.html#squid

If you watch the video I linked above it walks through the entire process.

Steve

This could easily be something in your browser filling the credential fields when you switch back to page. I've hit similar things before though not on that page.

Steve

That looks like plenty in hand in performance terms. No cpu core is anywhere near 100%. The bxe processes are not at 100%. I would have to guess the limit is somewhere else.

You might try running tests from the pfSense box itself. It's not a good way to show absolute values but you have CPU cycles to spare and it will allow you to test the WAN and LAN separately.

So you could run iperf on pfSense and test to it from the client to be sure you're getting speeds on the LAN that are above 1Gbps. You won't see 10Gbps but if you see, say, 4Gbps you know that's not limiting.

You can run the CLI speedtest client on pfSense to test only the WAN. That might show almost anything! My experience is that it usually shows low speeds on high bandwidth WANs but if it shows closer to 1200Mbps that would prove the WAN is good.

Steve

@kiokoman
Its a PFsense 2.4.4 P3 running on a Xen hypervisor, so yes it is a virtuel machine.

Based on the service status in his screenshot it's neither of those. But it looks like he went dark on us anyway.

@petreza yes, but we know about this thread. We will get back to you.

@jimp Thanks for the heads up, Im not aware of my /28 addresses yet so I will hold fire on adjusting anything.

Yes, you can bridge a 2nd interface to your WAN and allow them to use a single public IP directly.
You should also be able to apply Limiters to that traffic.
Whether or not you should is a different question.

Steve

Yup, probably. Unless that rule has a restricted source.