Netgate Store

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jimp

Pages: [1] 2 3 4 5 ... 1466
The "apply when renewing..." rule can never match anything, based on your NAT rules. It can't open port 80 on the WAN address because the destination is a private address, not WAN. There is also no NAT rule with a destination NAT port of 80, so that won't match either. So it will never do anything with the rules you show there now.

Your NAT rule maps a destination of  <WAN IP Address>:80 to

The firewall rule you have enabled passes to a destination, which will match because that's what the destination is on the packet after NAT applies.

So right now the rules you show are forwarding and passing port 80 and 443 in from your WAN IP address to the local server on on ports 81 and 443.

There is no mechanism to do that automatically. You'd have to create a script to do it from scratch, using the certificate functions from /etc/inc/ and probably copying some code from the certificate management page.

Firewall rules are processed after NAT in the inbound direction. So by the time a firewall rule is evaluated, the destination port is 81, so the rule needs to pass to the private IP destination on port 81, not 80.

Looks like we can consider all of these issues resolved as far as I can see. Every system I'm aware of that has tried the updated code is working properly now.

Can you post the contents of the routing table when it doesn't work? It would be under Diagnostics > Routes or from the command line, "netstat -rnW". The interface configuration for the PPPoE interface in the GUI may also help, along with the interface info from "ifconfig pppoe0".

I am not sure if it's related but after upgrading from 20 Apr snapshot to 19 May I lost connectivity to the internet. It is showing that PPPoE WAN is up and running, but I can not ping any IP on the internet from pfSense or LAN. I don't see anything unusual in the logs except those messages that pkg can not reach servers, rolling back ZFS snapshot restores connection immediately.

P.S. Looks like in some stage it got connected because it shows my dynamic DNS as updated and once it reinstalled packages, but can not get package list anymore, ping 100% lost, traceroute does not even start to trace.

What can I do else to analyze it?

That doesn't quite sound like it's related to anything in this thread. Start a new thread and post details of your setup there, at least show the routing table and what the gateways list/page looks like, maybe the config.xml entries for the gateways you have configured. You can redact any IP addresses in that info.

Latest Build fixes issues with my DHCP WAN connection.

Bug is squashed.

Thank you for the hard work.

Did you have the link cycling issue, the MTU issue, or both?

That is unclear yet. Apply the patch with the System Patches package and you will have the fix immediately and won't have to upgrade to get it (or wait for a release)

The next round of snapshots should be better here. It was related to the MTU. Turns out in 11.2, FreeBSD improved dhclient so it could handle the MTU, but it took the upstream MTU unconditionally and had no way to ignore the value. In each case I've seen so far, the ISP has sent a bogus MTU back which caused two things:

1) On e1000 and some other drivers, setting the MTU causes the link to go down and back up, which triggers the interface event scripts, which restarted dhclient, which set the MTU again, which made the link go down and back up, repeat, repeat, repeat, boom.
2) On other drivers, the MTU would be set to this value but it may not have been right. In my case and for others, this was a stupid low value like 576 which meant some sites would work and others would fail or be half broken.

We have a patch in the tree now from a FreeBSD dev which will be in the next set of snapshots that lets us ignore the incoming MTU with a supersede in the dhclient config (which I also added in the tree), and hopefully all this should hopefully return sanity to cases affected by these issues.

What is the process for upgrading to 2.4.4 in the future?  Will I need to revert the patch and then issue the upgrade or will I simply just upgrade to the next release as usual?

Do most people wait a while to upgrade usually?  I'm kind of nervous now to do upgrades given this bug which basically broke NAT.

This bug was never present in 2.4.4, only 2.4.3-p1. You can upgrade as usual. The patch won't reapply itself automatically unless you went out of your way to set it that way, and since the patch won't apply on 2.4.4 anyhow it wouldn't matter if you did.

Feedback / Re: something wrong nrpe with 2.3.5-RELEASE-p2 (i386)
« on: May 18, 2018, 08:28:09 am »
Yeah that should be fixed to refer to the new version. It isn't on 2.4.3 though, just 2.4.4 and now apparently 2.3.5-p2. I've just pushed a package update that will show up shortly to fix that.

See also:

OpenVPN / Re: Filter error after setup of OpenVPN
« on: May 16, 2018, 12:54:31 pm »
If you upgrade to 2.4.3-p1 that wizard issue has been fixed. So if you use the wizard again after upgrading it will be OK for future tunnels. Editing the current rule and fixing it manually will work around the issue on 2.4.3.

The problem OP hit is unusual but should also be fixed by a commit I pushed a few moments ago. There are others hitting a similar issue as well but it has a much different cause:

See and

No. Use 2.4.x for new features.

Pages: [1] 2 3 4 5 ... 1466