@mvikman oh sorry - I must of hit reply on wrong post, corrected ;) thanks

Good idea about redmine, I will look to see if anything in there already - and not make the suggestion

Should be marked as solved.

It's common to have the SWAP as double the RAM size. That way you can dump the full ram to it if required. pfSense doesn't do that though.

@lohphat said in ASN lookup failing with empty files [solved]:

I still think that the failure mode could be better handled and alerted -- the logs indicated empty files, but was it due to d/l failure or the server returned an empty file? Something should throw an alert if possible.

Ofcourse that could be a good Idea!

yeah, I found this thread yesterday on forum.level1techs.com and switched it off, as you said, only to see no difference.

"PPP is weird if you’re used to LAN and ethernet addressing. There’s only a single IP on the other side, and peers are originally meant to be symmetrical and not really ask for IPs using DHCP - instead, they’d just announce what IPs they have using IPCP and expect the other side to ack.
Then the whole ip address discovery thing was bolted on, so you as a peer can say, “I have 0.0.0.0”, and ISP can say “no you don’t, you have 2.64.x.x”. ISP peer can still say “I have 10.64.64.0” and you’d typically use that as a gateway.
In your routing tables, you’d have a directly attached 10.64.64.0/32 route via ppp0 as well as a 0.0.0.0/0 (default gateway) route via 10.64.64.0/32 .
[well something along those lines anyway … ppp itself is dying … but you might end up having /32 on ethernet interfaces these days instead]

My PPP log says the same now.

Thanks and best regards,
Mike

@justconfused I can marked it solved for you. So your currently working? While as I said I really don't think this is a pfsense issue - want to help in anyway we can to get you working.

@lolcakes69 you should be able to edit the subject - but I will mark it for you.

I don't know why a testing device acquired an IP address for the Guests VLAN while connected to a wireless network associated with the IOT VLAN. I tweaked subnet/VLAN settings a little, but still very similar to the settings as described above. The testing device now acquires an IP address in the expected subnet, when connected to the IOT wireless network, so I guess that problem is resolved...
Even after the device acquired an IP address in the expected subnet, it still had no Internet access. After adjusting outbound NAT, this too was resolved.

Finally my problem is solved by just changing my lan cable from wan port 1 to port 2 at the ISP modem side! The speedtest reaches over 700Mbps.
alt text

@bingo600 thank you so much for your reply giving me direction to solve the problem.

@viragomann That triggered something in this tired brain. :)
I want to access and reconfigure the device (I'm not it's original admin) with IP 10.0.5.251 for a different subnet. The device is statically configured and from a previous packet capture, it appeared that it is configured for a default gateway of 10.0.5.1. After changing the virtual IP to 10.0.5.1, I can ping/access the device.
Thank you!

It's a known issue and fixed on 2.6.0/21.09 snapshots

@stephenw10 Thank you very much Steve for the info, I will take it in account.

You can only choose a switch port on one interface as you found. If you leave unset it will use the actual VLAN status which takes it's state from the parent interface. In this case though that's the in internal port which is always UP.

No, there's no private VLAN type function. That would need to be on a switch where hosts are connected directly.

Steve

@teamits

Thank you, Steve, you somewhat pointed me in the right direction.
The location of the events are located here:
Applications and Services Logs > Microsoft > Windows > DHCP-Server

I checked and I couldn't find the culprit, but there's a DHCP server log file here:
%windir%\System32\Dhcp

The log file revealed the following error while a client was asking for an IP and the OpenVPN tunnel was on:
"Packet dropped because of Client ID hash has mismatch or standby server"

Upon further search, it turns out that the Active Directory DHCP server on Site A was trying to contact an AD DHCP server on Site B that once was part of the AD Domain of Site A, but since was removed from, but some more cleanup was necessary on AD Site A to make it stop trying to contact that orphaned AD Domain Controller. The issue has been resolved, all clients are able to obtain IP #'s from Site A.

Thanks so much for the hint.

Stay safe my friends.

SuperVertrix.

@apsis-im You are welcome, enjoy :)

@herman

You should be able to edit the thread title and tag - if not I can do it for you.

Thread marked.

@viragomann Awesome, thanks again !

Hi @johnpoz

I have NAT enabled on both pfSense firewalls, however as a test I disabled NAT to ensure all natting was handled by the Cisco router and I was still unable to reach the 10.0.20.10 client.

RFC1918 blocking is disabled on all the pfSense interfaces.

I can access all clients on the LAN network of the pfSense LAB with NAT enabled. I also have a static route on the Cisco router for 10.0.15.0/24 via 10.0.50.10 and I can access any host on that network with no issues.

After some more playing around today I got it working.
Firstly I had to assignin the ovpns1 interface and enable it under the Interfaces > Interface Assignments.
Then I was required to add the 10.0.100.0/24 network into the “IPv4 Local network(s)” under the OpenVPN Tunnel Settings, however this setting wouldn't apply until a reboot of the pfSense.

Thanks to everyone for the suggestions.

Tyler

Look at Redmine, and the Github repos (on the RELENG_2_4_5 branches) and see what's there.

The snapshots are automated and on a timer. There will not be a per-snapshot set of release notes.