Ok will try with NAT outbound, but first I need to read some manual's how to setup it :)

I went to 2.0-RC1 (i386) built on Tue Apr 19 18:39:57 EDT 2011, the oldest in the snapshot server and it works very well :-\

Thanks for answer, good to know! I have the "pfSense: The Definitive Guide" book also, very good work.

Why would you be seeing blocks on your LAN interface for IPs that are clearly public? Also if your going to manual create the forwards - then you have no need of UPnP port mapping or NAT-PMP to be set on the utorrent client.  I would suggest you turn those off, and make sure your client is not set to randomize port on restart, etc. Then post up your firewall rules and nat rules All that is required is to create a nat, and it will create the firewall rules. So either you have rules that are blocking it, or dont' have the rules setup correctly.  Or your pfsense is behind some other device blocking - ie maybe your "modem" you say you connect to and is working is really a gateway doing nat along with modem?  Post up model number of your modem.  Your pfsense is getting a public IP on its wan interface? This is a simple forward and works just fine with 2.0 RC1 I have too also update quite often and currently on build 2.0-RC1-IPv6 (i386) built on Tue May 3 10:16:12 EDT 2011 And even running development code for IPv6 support - and torrents were even working with ipv6 before I turned it off, ipv6 through my tunnel gives away more info then I wanted with torrents ;) Post up your firewall rules and happy to help you with your issues.

Hi Apply the fix today, and its generating the packages correctly now. Thanks Chris

@stephenw10: That seems fair. If your ISP is llu type then I think you have a chance. If you are reliant on btw then good luck! It is (apparently) LLU, which is why it is so annoying to me that they don't seem willing to entertain checking this or at least passing it along to someone in their team who is more clueful. Ultimately, the answer might come back as "yes we know this is an issue but we are unable/unwilling to support this because of xxxx", and that's an answer I would accept. There may be good technical/operation reasons. Incidentally, I have heard that people who use a Be line have had more success. I believe this is down to their use of PPPoE on their backhaul circuits which means they have an MTU of 1492 across most of their access network anyway and, therefore, know how to configure their kit to support this properly. Cheers, Keith

Brilliant!

thanks, I merged it.

I have the same problem with last soft from today. [image: ping.jpg] [image: ping.jpg_thumb] [image: ping2.jpg] [image: ping2.jpg_thumb]

I was bailed out by floating rules!!! I used a floating rule to block and ignore the multicast traffic. Here is how I created this firewall rule, notice that I did not highlight any interfaces [image: multicast.png_thumb] [image: multicast.png]

Is there a way to stop the modem from dialing in, and use the PPP from pfsense instead? It looks like in 1.2.3 it only says link#2, I assume this is an alias and who knows what it is. I see in you netstat -n the 192.168.1.1 entry, it doesn't mean it is being used as a gateway, just a connection, as if the modem sent a broadcast message or something.. If your interface is assigned a public IP address, and you're trying to use a private IP address as a gateway, it ends up being non-routeable. That is like saying on your windows XP computer, you assign 10.0.0.7 to the interface using gateway 192.168.1.1, well since they're different subnets, XP will not successfully use that gateway, unless you add a static route… Quick google pulled this up.. http://social.technet.microsoft.com/Forums/en-US/ForefrontedgeIA/thread/6f79860e-d8a9-4ed2-b79f-f4e16c678c66

May 6 18:17:28 ipfw-classifyd: Found Protocol: pdf (rule action block) May 6 18:17:09 ipfw-classifyd: Found Protocol: pdf (rule action block) like so? it still downloaded the pdf though.

Thanks for your feedback. I will try this in the future if the problem occures again. But for now I did a complete reinstallation because in the past I installed and reinstalled many package and so on and I think its good to know to have a clean system and a clean config.xml file to work with ;-)

If both IPs are in the same subnet (as you say, only change in the last place), they likely have the same gateway. You cannot have two WANs in the same subnet with the same gateway. If you can turn one of your modems into a router that does NAT, you could use that for your second WAN.

see http://forum.pfsense.org/index.php/topic,28649.0.html Seems issue is not with settings (see link within above link re mpd). Huawei e398 LTE modem gives same error in pfsense but works with Linux (Ubuntu 10.10).

Don't affect, If i only use  LoopBack interface in Squid ,browsing dosn't work,so i have to use Both LAN+Loopback. Also apply DNs Rule on Floating but no affect. What i perceive now, No One can done Failover for Default Gateway !!! Am i right . Where are the Pfsense Developers ??? they have placed feature of Load balancing .Please Guide us in how to achieve Failover +Squid regards

bump

I think there is a misunderstanding: the protocol you configure in the client config and the server config is the protocol to establish the VPN tunnel. It has NOTHING to do with the protocols you use inside this tunnel. The firewall rules tab "OpenVPN" is for the traffic inside the VPN tunnel and not the tunnel itself.

I modified the script as regis_f suggested, but I still see that behavior where freeRadius won't respond to requests after a reboot until it is killed and restarted manually. 2.0-RC1 (amd64) built on Thu May 5 18:46:28 EDT 2011 packages: freeradius widescreen I can't kill it from the web interface, I have to SSH in and Kill -9 <pid>. Killall radiusd from the console doesn't work either, so perhaps that's why regis_f's workaround isn't working for me. Any ideas? Edit: I also noticed that "top" reports radiusd as running, but as soon as the first client tries to authenticate, CPU useage for radiusd spikes to 100%.</pid>