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

@KurianOfBorg: Why does 127.0.0.0/8 to WAN use the outbound port range 1024:65535 when LAN to WAN does not? IIRC that is the default for others it's just explicitly stated in the 127.0.0.1 rule. @KurianOfBorg: Why is a NAT rule for 127.0.0.0/8 even required? Won't the OS automatically use the WAN interface for all outbound traffic originating from itself? Not always, that's for services that explicitly bind to 127.0.0.1 rather than 'any'. It was one of a few things we added that helped squid+multi-WAN function in limited circumstances.

Thanks for the pro-tip. Enable NAT reflection on the WAN, or on the NAT/rule itself? I've tried the latter, with no effect, butI'll try it again. Unfortunately the crappy router does not support PPPoE - that would've been my own preference - let the "modem" only do the connection & have my pfSense to the routing & firewall work.

Sorry to answer that late! Thank you for your possible solution. As I had no time yet to get into the problem again (changed back to the old system), I'll do some research later (probably tomorrow as it's Friday). Regards, Bostjan

It's called "static port NAT". http://doc.pfsense.org/index.php/VoIP_Configuration http://doc.pfsense.org/index.php/Static_Port But, generally speaking, you shouldn't need it (at least I never had to enable it in the last couple of years). The port I'm seeing keeps changing on my hosted phones causing calls to behave strangely if the port for registration changes in the middle of a phone call. If port mapping changes in the middle of a phone call, it suggests that the NAT gateway may have expired that state. You should try tuning the qualifyfreq interval.

after having re re read the voip wiki I am no longer certain if voip nat outbond should be "static NO" or "static YES"… and which of those means "port rewritten".  'symmetric yes' is 'static yes', right? in that case would I replace the "Auto created rule for LAN to WAN" with three wan 192.168.40.0 src port: udp/my_sip dest: * dest port: udp/* nat addr: * nat port: * static: no wan 192.168.40.0 src port: udp/* dest: * dest port: udp/my_sip nat addr: * nat port: * static: no wan 192.168.40.0 src port: * dest: * dest port: * nat addr: * nat port: * static: YES