I gave up and installed a third NIC. Everything is working.

If you setup a virtual switch with no real interface and assign yours hosts to it and config firewall with real/bridge interface and virtual switch, then It's possible.

Thanks, i have waited in fact i didnt move it when i connected it to the internet directly and it started to work then but then when i connected to my network with pfsense i when it doesnt work. So i know that the gps and the device itself are good

Do you have ports blocked by default, default config is all ports our allowed outbound from the lan.

Ahhh, got it  :) Thank you!

sure just forward 10001 to web1 ip on port 443 then forward 10002 to web2 ip port 443 This is done under your nat rules, and then just let it create the firewall rules for you.

@marcelloc: You have 192.168 as well 10.27 as source ip on the same interface, did your setup your network this way? Isn't these logs from infected machines? Setup are as above, logflood are from smartphone devices which are connected though dhcp-WIFI

I see… I will give that a try.. thanks a lot.

Documentation for configuring FTP on FreeNAS can be found at http://doc.freenas.org/index.php/FTP. The settings which you have to make sure are set are: Masquerade address - Should be set to the public address of your WAN interface Minimum passive port - Set this to an available highport (larger than 1023) which is not being used for any port forwards, for example 10000 Maximum passive port - Set this to an available highport which is 500 higher than the minimum passive port which you configured, for example 10500 Now what you need to do is to set up port forwards for TCP ports 20 and the 10000-10500 range from your WAN interface to the IP address of your FreeNAS device. Make sure that you also create associated firewall rules to allow this port forwarded traffic. When you attempt to connect to your FTP server through the WAN interface, make sure that the FTP client you are using is configured to connect in passive (PASV) mode, and everything should work as a treat. Andreas

@Tikimotel: The logging of this rule message can be stopped by disabling "Log packets blocked by the default rule" in the settings. Status: System logs:–> Settings Yes, this is right. But this will stop logging of all logging. And I would like to have the chance to check who tries to connect from outside. The way by setting-up a manual filter for the private networks without logging works fine.

Do your APs have a default gateway set? If not, they can't find their way back to the client. Though you may also want to check the firewall settings, you might find that you'll need an outbound NAT rule (and manual outbound NAT) on LAN to translate traffic going to the APs into an IP on their own subnet, so they are tricked into thinking the traffic is local.

LAN: 10.20.11.0/24 alias Proxies LAN_7: 10.0.7.0/25 Host on LAN use PFsense as a GW Host on LAN_7 use another Router as a GW OBS: if I start the conecction, like ssh from Host on LAN to host on LAN_7, there is no problem, but, if I start from host on LAN_7 to host on LAN, PFsense block on interface LAN_7, even if I adde a rule with Easy rule on System logs thnks [image: fire1.png] [image: fire1.png_thumb] [image: fire2.png] [image: fire2.png_thumb]

Hello All, I have the same problem with schedules like whoamib. I noticed that when I create a schedule which involves more than one month, the schedule is not working properly. For example I have attached 2 screenshots and when time range which involves 2 months (or more) is configured in one range - don't work! when time range which involves 2 months (or more) is configured in two ranges - works! As you can see in the pictures, time ranges for 828_Eli and test are identical, but 828_Eli is active today 11-Mar-2012, but the other schedule is not active! I think this is a bug! [image: work.JPG] [image: work.JPG_thumb]   [image: 3.JPG] [image: 3.JPG_thumb]

Additional info for anyone watching this thread: If I use tcpdump and watch the bridge0 interface, the packets from my PC come in and get redirected to 10.1.1.3:3128 –- but nothing every responds. If I connect directly to 10.1.1.3:3128 via  telnet or browser proxy settings... that works fine. It's like something in the packet filter/rewrite isn't sending the packet to where it needs to go or squid is ignoring it. I'm really trying to avoid using "routed" mode vs "bridged" mode... Am I missing a system tweakable? Thanks, -Ben

That update script checks the timestamp of the file to see when it was last updated, and it won't update it for a week. Though if you edit the code that does that check (follow the code from that rc script) it should be easy to work around.

Thanks Marc for the Reply, Yup I got it now after I found this explanation of the screen it became clear. –--------------------------------------------- Take traffic entering the chosen interface, using the specified protocol, initiated from the specified source, destinated to the specified destination, and redirect it to the specified target IP and port. If you understand the above, then  you also understand the power of Pfsense, combined with Alias for Incomming IP's and Ports you can narrow your open port's to the bare minium needed. Most SOHO's and even advanced Firewalls dont have this fine grade filtering  they just open the range of ports for all thats happens to hit them. It is running super stable for days already, so bye bye to my other device. ::)

OK - progress!  Thanks for the extra push in the right direction!  After my last reply I went off to learn more about MTU issues in general (it's years since I looked at the topic last time), to see what I'd forgotten/what had changed in the interim. I remembered the problem with blocked ICMP messages resulting in silently discarded packets.  That's likely on my LAN as pfsense drops all ICMP inbound on the WAN.  But I did think lowering the MTU on the WAN interface should pretty much take care of that. Then I read a little about MTU and MSS and decided to try an MSS of 1492 on the WAN interface - and lo' everything works.  (Many, many thanks. I've been busting my head on that one for a couple of days, perhaps I need to go back to school!) I'm not 100% clear on why the MSS setting made a difference?  I would have thought that MSS + TCP headers = MTU. So setting MTU on pfsense should tell pfSense "only ever send packets of 1492 bytes" And setting the MSS should tell the remote host "only ever sent me packets of (1492 - TCPHeaders) bytes" If anyone would care to elaborate on the differences in the settings that would be great - I'm reading about it right now but just not 100% clear on the difference.