Just remember, when you run into problems in future and post looking for help, mention what you've done. It is entirely possible that your problems may be linked to the changes you've made doing this.

no idea ? ???

I have noticed the same thing using the 32 bit build (yesterday's date). It only happens with a multi-wan connection and an internal routing switch. Again with PPTP the only way I can get around this is by adding the pptp addresses as a proxy arp address in the pfsense box. Shouldn't have to do this IMO. Is this a bug?

Thanks!

A TCP connection (say to send an email) has a special sequence to establish a connection and a special sequence to teardown a connection. A flow is a data structure describing data transfer within a connection. It will normally have at least source IP, source port, destination IP and destination port. Thus a connection has two associated flows (because data can travel in both directions). Simplified firewall processing - packet arrival at firewall Is there a flow for this packet? Yes - forward the packet. No - Is this a connection setup?     No - discard packet     Yes - Does this connection setup match an ALLOW rule for this interface?         No - discard packet         Yes - create flow for this direction of data transfer,             create flow for reverse direction of data transfer,             forward connection setup @broncoBrad: His computer is on LAN which has the standard allow LAN to any rule. As first rule on the interface I add a BLOCK rule to LAN to block access FROM his computer TO game servers in peak times. Any access from other computers doesn't match that rule and falls into the LAN default rule allowing access. Why is it "FROM" (i.e. Source) and "TO" (i.e. Destination) on the LAN interface? I guess what I'm saying is if you're looking at when it arrives at the firewall I thought it was only coming into the LAN thus the rule doesn't make any sense, but if it's both going in and out then the rule makes sense. So instead of just doing a Destination rule to your son's computer (which would allow his attempts out to the internet, WAN), but be blocked on the way back in, you stop it from even going out the LAN, correct? The simplified firewall processing description says the firewall rules are consulted only on an attempt to setup a connection and if that attempt is allowed then the "back traffic" to the initiator of the connection is also allowed. The firewall rules apply to connection setup attempts. If my son wants to have a conversation with his games servers the firewall will see on the LAN interface a connection setup attempt FROM his computer TO a games server. If the firewall allows that connection attempt (and the target accepts it) then all traffic (both directions) on that connection is allowed.

Thank you, it works !

Use this to show valid engines: # openssl engine (cryptodev) BSD cryptodev engine (padlock) VIA PadLock (no-RNG, no-ACE) (dynamic) Dynamic engine loading support You probably want "cryptodev" as the engine. That's where the OS hooks into crypto devices generally.

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!