If you only want to allow connections to DMZ and don't need connections from DMZ, but if you also don't want to change anything on your production firewall yet, you could actually even add an outbound NAT rule to NAT all traffic that goes to the DMZ network.  To do so, just create an outbound NAT rule on the DMZ interface from all to all (or from all to DMZ network if you have the subnet set to match already).  Then you should be able to access all of the systems on the DMZ network, for access from LAN, port forwards, or 1:1 mappings.

Thanks jimp. That looks good, but now it appears that I have the same issue with IGMP traffic from the same public IP to destination 224.0.0.1.  :P  Looks like I'll have to do something similar there to cut down on the noise in my firewall log. BTW, I enjoyed the book.  I bought it in March and was able to read the entire thing when I had jury duty.  :)

You do not put the gateway on internal interfaces. And also the gateway would have to be within the subnet on the interface.

The internet is already accessible from the LAN side by default on a new install. By default, all ports are blocked inbound from WAN to LAN, and all traffic is allowed from LAN to WAN. Without getting more details about what exactly it is you want to do, the only pointer I have is this: http://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F

Very very simple. Try to use NAT 1:1, you´ll accept all traffic in a external IP to single private IP. But after do this, remember to check rules on interface to this destination address. Regards, Heitor Lessa Blog -> http://tinodiaadia.wordpress.com

Are you using squid as proxy? What application server do you use to hosting it? Ex: Tomcat, Glassfish, Jboss. If you´re applications are dynamics that using jsp pages and webservers like this and you´re uses proxy on network, post it. I had a same issue but I use proxy on network, to resolve i input the ip addresses on squid.inc in $rdr rules to bypass them when users access it. Regards, Heitor Lessa Blog -> http://tinodiaadia.wordpress.com

You are probably trying to log in as admin.  You need to log in as root instead. It´s correct. The same issue happens when you try to connect to the pfsense using any WinSCP or WinFTP cliente as BitviseTunnelier, if you´re logged as admin you cannot list the folders by GUI, but if you´re log in as root, works! Regards. Heitor Lessa Blog -> http://tinodiaadia.wordpress.com

Hi @ll Found the problem myself. It was a problem with Squid (sorry I forgot to tell you this is installed).  I have entered my own IP to bypass the Proxy and it works since then. @ jimp : Thank you very much for your help Thx thafener

You could try changing the firewall optimization to 'conservative' but I'm not sure if that will affect this particular type.

thank you GruensFroeschli. I understand now, I'll try it and I'll see if it works or not.

Rather than trying to guess at what you are doing, can you post your rules and config?

Disable that the dns can be overridden by DHCP and set it static as 208.67.222.222

ok thanks a lot. i've made the needed modifications to the filter.inc file on both firewalls and so far everything is working as expected. btw, i'm using this old old version (2008) since it's the only one, that i'm aware of, supporting multi interface traffic shaping besides 2.0 still in beta…. is anyone aware of any more recent version of 1.2 supporting it?

Please post the rules, not what you think the rules are.

@pneumoboy: Maybe coming in a little late, but I have a similar configuration using VLANs without an issue. Basically each subnet is on its own VLAN. For you: 192.168.1.0/24 VLAN1 192.168.4.0/24 VLAN2 192.168.44.0/24 VLAN3 Each subnet's default gateway resides on the pfSense box. And each VLAN has its own Firewall ruleset, which you can use to control the traffic between the VLANs. So it is possible to let both 4/44 talk to 1, but 4 cannot talk to 44 and 44 cannot talk to 4. My corp configs use one physical interface for the trunked link (for all the vlans), and one physical interface for management (that is not trunked). No one says you cannot use a trunked link for management, but for sanity (and fat finger mistakes) I keep them separate. I have this configuration setup, but for me the rules are negated by the "Default deny rule" and any connection to the other VLANs are dropped by the firewall. Any ideas of what  a possible problem is?

Yup. Thank you for citing original source.

It could be. I'll check it out. I've disabled ftp-user proxy and the lgos are gone. Don't have need for ftp from lan.

Never seen that unless the server isn't actually responding. Get a packet capture of the internal interface where the server resides when it fails and see what's happening on the wire.