pfSense logs are circular logs. That is they are fixed size (cannot grow indefinitely) and contain only the most recent entries. You need to use the clog utility to convert them to standard text, for example:```
clog /var/log/system.log

Seems to have been something obvious since it has been fixed upstream right away. The packet loss is minimal again. They didn't tell me about the cause though. Would have been nice I think. Something like "sorry for the performance issues, our foo was bar and has been replaced".

Your ISP is not routing the IP properly. Please check with them. I asked this in your other ticket, but, if you can ping WAN IP but not WAN GW IP, then the ISP is the problem as they are not routing correctly. Perhaps they are sending your /24 to .9 instead of .10 or something like that.

I noticed that you have the FW off, so no rules are going to apply anyway. This means no NAT, FW, nothing, only routing. Since that is the case, it would seem that you probably have a basic routing problem. Can machines on your VLAN ping the WAN ip of pfSense, then, can they ping the WAN Gateway?

Thanks fellas.

That's what I ended up doing.

@wallabybob:

@Gio:

I am trying to implement pfsense as "transparent" but have not been successful.

Have you configured default gateway in client?

Have you configured default gateway in pfSense?

You seem to have posted pretty much the same problem report in at least two topics. In which topic do you want to continue the conversation?

– To answer your questions:

Client VLAN lets assume is 200.10.20.128/29 - with a 200.10.20.129 IP gateway (accessible from client IP 200.10.20.130)

Default gateway in PFsense is also setup, shows up in gateway and "Routes" show default 0.0.0.0 using WAN next hop.

Let's continue the conversation in this thread http://forum.pfsense.org/index.php/topic,60980.0.html

I have simillar problem. FTP server is behind pfSense NAT in LAN. I have already tried turn on and off TFTP proxy helper for LAN/WAN but still no success. For now I have NAT rule x.x.x.x:47020 -> 192.168.2.80:21. I can connect control channel but can't connect passive ports. WAN IP is dynamically assigned so no resolve_passive_ip or simillar possible(?).

Interesting, I tried this but used Comcast's name server (75.75.75.75) because they offered a lower ping time however check_reload_status.php kept hammering my Alix CPU for hours; tried rebooting but that didn't fix it.  I reverted back to using the dynamic gateway and check_reload_status.php went back to normal.  Strange but clearly not a solution in my case.

thanks for sharing your similar experience with me Tim, it sounds almost exactly like my problem; changing the monitor IP worked for me as well; but i wish i could actually understand the root of the problem. ill dig around a bit more but if i don't find anything i wont worry so much as its basically resolved.

That means that it received an ARP packet from some other device on the network and that device sent a packet that wasn't recognized.

It could be coming from the WAN or LAN, hard to tell without running packet captures and looking for it.

virtual box clients don't normally start up until you launch them..  is pfsense vm starting when you start your machine?

Have you looked at the 2.1 version of pfSense? If you are making a new module it might be worth doing your work against it instead of 2.0.x.

2.1 forum: http://forum.pfsense.org/index.php/board,53.0.html

The logs would be approximately the same as pf on OpenBSD, since we use pf as the packet filter in pfSense.

They would probably find more references looking for that.

Thanks

Yes.
You will need to add a VLAN interface on the pfSense box with the correct vlan tag number and add a dhcp server instance on that interface. Then add appropriate firewall rules to allow traffic on that interface to go out to the internet.

Steve

The file appears to be here: http://people.freebsd.org/~thompsa/rancid-compat
However since the blog is down I cannot compare it with the originally linked version. It is dated 30th Aug. 2012 though.
Steve

http://forum.pfsense.org/index.php/topic,60510.0.html

pfSense appears to always insists on "wrapper mode"
http://forum.pfsense.org/index.php/topic,60517.0.html

Should be able to use the port of your choosing so long as it is configured for "wrapper mode".

The queues can be modified and added to. IF you add a new queue, remember to add a floating rule or rules to put traffic into that queue.

i find it a good specs here so my other problem is there another STOREURL.PL code…