ah ok, but where I save my wpa key if the secret share is for the client auth?

"…the wai-ait-ing...is the hardest part..." [image: Petty_Tom_1.jpg] [image: Petty_Tom_1.jpg_thumb]

Hi Cino, I was asking to update the package to version 0.5.4… I don't know what is better between updating the current package or create a new package (LCDProc-dev) until it is stable to replace the current package... anyway, let's see what the guys will answer me... I will update this post when I have news about that! Ciao, Michele

Thanks to all who replied. I haven't been with the client since posting, so excuse me for not answering your questions. However let me clarify a few things. @Metu69salemi: You need rules on dmz interface, only lan has default allow any rule. Yes, the rules I mention are set up on the DMZ interface. @wallabybob: Can you ping the pfSense LAN IP address from a system on your LAN? If not, what is reported? Yes. Everything on the LAN segment can ping each other. @wallabybob: Did you mean Port Forward mapping from 12.23.34.44 to 10.10.10.10? Its a 1 to 1 NAT I believe. The external IP is an Alias for the WAN interface. What I was trying to acheive was that all traffic to .45 goes to the firewall and all traffic to .44 goes to the DMZ server. @wallabybob: Please give more details than "can't connect". How are you attempting to connect? What does it report?  If you are using ssh do you have sshd running on the DMZ server and is it configured to allow access from LAN? Yes, of course I have sshd running on the DMZ server. I sit in the LAN, try to connect to the DMZ server on its DMZ IP 10.10.10.10 and the connection times out. There is no communication from the LAN to the DMZ. Aha … maybe I should turn on logging for the DMZ rules. I'm assuming this is possible. I'll try to figure that out to see if it gives me any clues. @lonevipr: If you only have one public IP address & your DMZ & LAN are on separate NICs & separate physical interfaces, you may have to enable bridging to make anything in your DMZ subnet accessible from the public internet. We have two public IP addresses. As I explained above one is meant to direct to the firewall (and LAN) and the other is meant to map to the server in the DMZ. I'll look into bridging. @lonevipr: Like Metu69salemi said, you will need to create a firewall rule for the DMZ interface allowing traffic IN from the internet TO the DMZ server, also possibly allowing traffic IN from the LAN as well. After created you will need to goto reload filter option in pfsense to make sure the rule is actually applied once it's created. … which I thought I'd done. OK well I'll tear it down and start again. It does work with an Allow All rule between LAN and DMZ server, but if I'm doing that, then pretty much no need for a DMZ then! :-) Thanks for the encouragement. I've been setting up firewalls of different brands for 10 years or so (Netscreens, PIXes, Fortigates etc), which is why I'm a bit confused that this isn't working. Sounds like I'm doing everything right, so I'll keep plugging away.

Due to another problem I went back to my Jun 21 snapshot build, upgraded to Aug 26 snapshot build then gitsync'd to get IPv6 support. On reboot after the gitsync, pfflowd appears to get started multiple times but only one copy is left running: ps ax | grep pfflowd 52323  ??  SNs    0:00.24 /usr/local/sbin/pfflowd -n sme.example.org:5678 -S any -v 5 39759  0  R+    0:00.01 grep pfflowd clog /var/log/system.log | grep pfflowd Sep  2 11:30:36 pfsense pfflowd[2924]: pfflowd listening on pfsync0 Sep  2 11:30:36 pfsense pfflowd[2924]: pfflowd listening on pfsync0 Sep  2 11:30:38 pfsense pfflowd[5216]: pfflowd listening on pfsync0 Sep  2 11:30:38 pfsense pfflowd[5216]: pfflowd listening on pfsync0 Sep  2 11:30:41 pfsense pfflowd[5216]: pfflowd exiting on signal 15 Sep  2 11:30:41 pfsense pfflowd[2924]: pfflowd exiting on signal 15 Sep  2 11:30:45 pfsense pfflowd[52323]: pfflowd listening on pfsync0 Sep  2 11:30:45 pfsense pfflowd[52323]: pfflowd listening on pfsync0 siproxd is still started multiple times with one copy left running: clog /var/log/system.log | grep siproxd Sep  2 11:30:28 pfsense siproxd[58103]: siproxd.c:247 INFO:siproxd-0.8.0-5472 i386-portbld-freebsd8.1 starting up Sep  2 11:30:28 pfsense siproxd[58359]: siproxd.c:295 INFO:daemonized, pid=58359 Sep  2 11:30:28 pfsense siproxd[58359]: plugins.c:112 INFO:Plugin 'plugin_logcall' [Logs calls to syslog] loaded with success, exemask=0x40 Sep  2 11:30:28 pfsense siproxd[58359]: sock.c:131 INFO:bound to port 5060 Sep  2 11:30:28 pfsense siproxd[58359]: siproxd.c:349 INFO:siproxd-0.8.0-5472 i386-portbld-freebsd8.1 started Sep  2 11:30:34 pfsense siproxd[62885]: siproxd.c:247 INFO:siproxd-0.8.0-5472 i386-portbld-freebsd8.1 starting up Sep  2 11:30:34 pfsense siproxd[63269]: siproxd.c:295 INFO:daemonized, pid=63269 Sep  2 11:30:34 pfsense siproxd[63269]: plugins.c:112 INFO:Plugin 'plugin_logcall' [Logs calls to syslog] loaded with success, exemask=0x40 Sep  2 11:30:34 pfsense siproxd[63269]: sock.c:131 INFO:bound to port 5060 Sep  2 11:30:34 pfsense siproxd[63269]: siproxd.c:349 INFO:siproxd-0.8.0-5472 i386-portbld-freebsd8.1 started Sep  2 11:30:36 pfsense siproxd[2489]: siproxd.c:247 INFO:siproxd-0.8.0-5472 i386-portbld-freebsd8.1 starting up Sep  2 11:30:36 pfsense siproxd[2808]: siproxd.c:295 INFO:daemonized, pid=2808 Sep  2 11:30:36 pfsense siproxd[2808]: plugins.c:112 INFO:Plugin 'plugin_logcall' [Logs calls to syslog] loaded with success, exemask=0x40 Sep  2 11:30:36 pfsense siproxd[2808]: sock.c:543 ERROR:bind failed: Address already in use Sep  2 11:30:36 pfsense siproxd[2808]: siproxd.c:337 ERROR:unable to bind to SIP listening socket - aborting Sep  2 11:30:41 pfsense siproxd[25686]: siproxd.c:247 INFO:siproxd-0.8.0-5472 i386-portbld-freebsd8.1 starting up Sep  2 11:30:41 pfsense siproxd[26409]: siproxd.c:295 INFO:daemonized, pid=26409 Sep  2 11:30:41 pfsense siproxd[26409]: plugins.c:112 INFO:Plugin 'plugin_logcall' [Logs calls to syslog] loaded with success, exemask=0x40 Sep  2 11:30:42 pfsense siproxd[26409]: sock.c:131 INFO:bound to port 5060 Sep  2 11:30:42 pfsense siproxd[26409]: siproxd.c:349 INFO:siproxd-0.8.0-5472 i386-portbld-freebsd8.1 started ps ax | grep siprox 26409  ??  SN    0:00.25 /usr/local/sbin/siproxd -c /usr/local/etc/siproxd.conf 50356  0  S+    0:00.01 grep siprox

I've noticed the same behind the built in load balancer relayd.  We've had to be more explicit with our rules starting about 2 weeks ago.

It's easy on 2.0. Just use the IP Alias type VIP.

Yeah, it has to differ from system to system. I use shutdown -h all the time and it cuts the power after the shutdown process completes. Well I'm glad the php script worked for you. Take care!

First thing you'll have to do is to check your 3g modem and use that model with search. if there is no results, then you reply to this topic and add that information

Hi GE, My original setup was in VMware. What gave me issues was splitting the subnet between 2 DMZs. Are you having issues getting your DMZ working?

For quick and dirty:``` netstat -an Alternatively you can use``` iftop ```to see a better list of clients using bandwidth.

@Wendo: I may be missing something here, but why do you think you need 2.5Ghz + to run a 7Mb DSL connections? I can max a 15Mb cable connection with a 500Mhz Pentium 1 If you have more than one internal subnet and have them segregated using different interfaces in pfSense then traffic between the subnets (and hence the interfaces) is filtered just as it would be between WAN and LAN. This if both 'LAN' interfaces are gigabit you will need to filter at gigabit speeds. @sully: If you can't have segregated internal networks, because of your existing wiring, then you don't need fast box. Even so I can get throughput of around 500Mbps from my Pentium-M 1.5GHz box. It would be faster if it had nice Intel NICs. If you think about it carefully you can probably come up with some compromise solution. E.g. put your teamspeak boxes on a separate interface close to your pfSense box. Leave your NAS in the same subnet as your clients so that traffic is not filtered. The concept of red, green and orange interfaces doesn't really hold true for pfSense since, especially in 2.0, all interfaces are treated equally. The differences between them are simply down to what rules you have applied. E.g. you could have five internal interfaces and they would all be 'green'. If you are going to use pfSense as a web proxy it would probably actually be easier to use it as a router as well.  ;) Steve

Thanks :) After i figure all this out im shooting for OpenVPN and RADIUS stuffs. Thats easily searched though.

Did you enable the traffic shaper on the old connection and set it to those values by chance?