What has a X-Box on a monowall to do with pfsense?

@kejianshi: Time to consider another option I guess: http://images.clipartof.com/small/1045996-Cartoon-Black-And-White-Outline-Design-Of-Businessmen-Communicating-On-Can-Phones-Poster-Art-Print.jpg Could I order 60 more of those please?

I'm glad thats helpful.  I'm interested to see how it turns out.

@kejianshi: If this is the case and nothing else on the network is plugged into that DSL modem/router the world isn't magically being to be able to get into this guy's network.  Not unless he does something really dumb.  This is what PF sense is.  A firewall.  If exposing its WAN port to the world were a security risk there would be no point in using pfsense. Huh? You just repeated what I said. You do realise that it's entirely possible to plug the modem into the LAN switch and still configure a WAN (PPPoe) on pfSense? It's secure only if you isolate the bridged mode modem by plugging into a physically separate port on the pfSense box or using a VLAN. This is the whole reason off-the-shelf routers have a dedicated WAN port. There is no need for a separate WAN port if you simply want it to act as a NAT gateway for PPPoE. Off-the-shelf routers can technically dial PPPoE even if the modem is on the LAN interface but they don't allow it. pfSense does allow you do bridge the modem on the LAN interface and still use the PPPoE connection as the WAN interface.

1.  If you are inside your own LAN and you are trying to access your server page using its private IP pfsense is dishing out, it should work. 2.  If you are inside your own LAN and you are trying to access your server page using public IP, it shouldn't if NAT reflection is off.  If NAT reflection is on and you are inside your own LAN it should work, however this is no guarantee its actually working from the outside since your ISP could block the port.  3.  Its possible your ISP is blocking 80? 4.  Assuming none of the above are the problem, is the computer on port 192.168.0.201 running a firewall? Also, there are people here in the forums who don't like to do this, however if you are going to need 443 and 80 for other servers, I'd change the ports my pfsense gui operates on.  While there is a command to allow pfsense and another host to basically share a port, I wouldn't use that solution.  I'd keep my pfsense interface exposed only on the LAN side of the network and move the interface port to non-standard ports and leave 80 and 443 free for my other servers. If you want to know if things are working from the outside but don't have a second connection to try from handy, a cellphone browser with a data plan is good for that or you could use browsershots.org

I found the problem. Even though the inbound rules were defined on the LAN2 interface, the responses were using the policy based routing rule on my LAN interface group rule for "*** to * through WAN gateway**". The associated firewall rules on LAN2 from the NAT port forward were not being used at all. I changed the LAN interface group rule to "LAN1/LAN2 to * through WAN gateway" so that it doesn't match the packets being forwarded by the NAT modem. Now I am able to port forward to both pfSense as well as to LAN1 servers from the NAT modem on LAN2.

Wiz – nice to have you on the forums, but you might want to actually read a thread before you post ;)

phil.davis! YOUR THE MAN!! You just saved me alot of hair ;) Now they get their own public IP, exactly how I wanted it to be.

You need a reverse proxy. There are some packages for pfSense that can do that for you. Search around the forum a bit and you'll see it's been discussed many times.

I actually just set WAN_HOME as the default gateway so that takes the traffic back out that interface.  I have the policy based routing on the LAN's to send them out their respective WAN connections.

Not really what you asked for, but I wonder If this wouldn't get your mail where you want to forward it to?  Not sure. postfix http://forum.pfsense.org/index.php/topic,40622.0.html In packages: Postfix mail forwarder acts as a relay server for your domain. It can do first and second line antispam combat before sending incoming mail to local mail servers. Postfix can also detect zombies, check RBLS, SPF, seach ldap for valid recipients and use third part antispam engines like policyd and mailscanner for better antispam solution.

No IPv6 on 2.0.x, you'd need 2.1 May as well use 2.1 now, it's nearly ready, just a few more bugs to fix, nothing too major for most people.

https://secure.hostgator.com/ip.php Same note here http://support.hostgator.com/articles/hosting-guide/hosting-plan-comparison/dedicated-ips-ip-address Notice: Due to the global shortage of IPv4 addresses, we are now required to request justification for dedicated IP address requests. Please be aware, at this time the only acceptable justification for a dedicated IP address we can accept is for use with an SSL certificate. You can only have 1 dedicated IP address per shared account. The dedicated IP address must be assigned to your entire cPanel. Your primary domain and all addon domains and subdomains will use the same IP address. You cannot purchase a dedicated IP for only an addon domain. Hatchling accounts are not eligible for a dedicated IP. I will stick with Comcast until I use up the 13 that are listed http://business.comcast.com/smb/services/internet/ipaddress Then I will move up to a different provider. By that time, I will have some funds generated to justify the cost of a new provider. Granted, all the ideas I am formulating from these readings are true. I may not be completely understanding it still.

@pa-k: In this config, one server on the DMZ can not reach a ssh connexion to a remote server on the internet area… ssh_exchange_identification: Connection closed by remote host From the pfsense master, i can connect to the remote server without problem… Correction : From the LAN and the DMZ, i can not access to a server on the internet by the ssh port with the cluster of pfSense although i can from anywhere else (e.g. from my home)… The same error although the rules are opened on the LAN and the DMZ : ssh_exchange_identification: Connection closed by remote host What could be the problem here ?!? The tcpdum from DMZ and LAN are almost the same, the traffic can not go out… : 16:48:29.157536 IP 192.168.4.42.10.55162 > 42.42.42.42.22: tcp 0 16:48:29.160836 IP 42.42.42.42.22 > 192.168.4.42.55162: tcp 0 16:48:29.177688 IP 192.168.4.42.55162 > 42.42.42.42.22: tcp 0 16:48:34.194287 IP 42.42.42.42.22 > 192.168.4.42.10.55162: tcp 0 16:48:34.221315 IP 192.168.4.42.10.55162 > 42.42.42.42.22: tcp 0 16:48:34.224327 IP 42.42.42.42.22 > 192.168.4.42.10.55162: tcp 0

I would assume those are answers to your dns queries.. BTW At a loss to understand why you should block out the IP of isp dns? They shouldn't be blocked since you should have connection tracking of your query to them, etc. I would sniff the traffic and see what is in there if it was me - is dns working?  Is it constant or does it come and go in bursts as you surf?  Running p2p can generate large amount of dns queries.

The rule should be in LAN and OPT1 that basically says that from LAN/OPT1 Net to any is allowed.

It works! The bolded part is the key! I can confirm that this in fact works fine in 2.0.1 and 2.0.3. I didn't have to configure outbound NAT on the home side either. So basically I have a NAT rule at the DC on WAN interface where the "Redirect target IP" is an IP of the server at home. @jimp: You can't port forward across an OpenVPN tunnel on pfSense 2.0.x. It can be done on pfSense 2.1. On the target side, you need to have the OpenVPN interface assigned and enabled (IP type of 'none') and have the firewall rules to pass in the traffic on the interface tab for the VPN and not the 'openvpn' tab – that tab should not have any rules to match the traffic. The reason that works is, when assigned, the VPN gets an automatic gateway. And on 2.1, rules on the assigned VPN interface will have reply-to added to send the traffic back out the VPN when it comes in that way. Without reply-to, the packets go from the source side to the target side across the VPN, but the replies go back out the WAN rather than flowing back through the VPN.

Perhaps you need to change your pfSense webConfigurator port to other than 80 and / or disable the "webConfigurator redirect rule" (on System: Advanced: Admin Access)

thanks for your answere! Good to know. best regards, divotion