Sadly that was not the problem. I change that checkbox and its no different then before. Just for fun, I changed back to automatic nat and it still does not work. Stupid Computer!

This is primarily what I am doing too. The easiest, and cleanest way to do this is to create an alias for the ports you want to accept for that system. PRT_SERVER 21,80,110,443 etc etc Then create the firewall rule for the ports on the INTERNAL IP of your server.

I think, I have described my question not as clear as I should What I wanted, was to allow multiple subnets on one interface Luckily i have found an answer here: http://doc.pfsense.org/multiple-subnets-one-interface-pfsense.pdf

Hi vatson! I've experienced the same that you describe: <http: forum.pfsense.org="" index.php="" topic,19208.msg98830.html#msg98830="">Nobody (except you and me) has discovered this before? My release is 1.2.2 and the issue continues the same way. In my case, the interface in not the LAN one, but one of the OPTn. Regards: Paco.-</http:>

I could do that, but with 20 phones in 3 states this was much easier to do.

Thx will check it out asap.

Thanks I got it working!

I have also been trying to figure this out.  I tried using 1:1 NAT mapping to map the external IP from my OPT1 interface to the server but outbound IP is still from my WAN.  I thought that outbound mapping might take care of it but haven't tried it yet.  I will want to do that in a test environment to see how it will effect outbound traffic otherwise. Let us know if you ever found a solution or hopefully this will bump the thread and get some more eyes on it.

The keep state rules do not take care of it because there may be no existing state to keep.  The reason this kind of translation works for Starcraft is that its version of Battle.net expects Starcraft to be listening on the same port as was used for the source port.  It then tells the other players that you are listening on that port number.  For Starcraft you can also change the source port number through the registry, but the router needs to be told not to change the source port when it translates the outbound packets.  In either case a port forward is needed, though. For Warcraft III, its version of Battle.net does not care about the source port.  It directly tells Battle.net what port it is listening on instead.  Because of this, it only requires a simple port forward with the external and local ports set the same and no special outbound configuration.

nobody have any suggestion? new test: Wan1 (PPPoE) off, try to telnet from outside to port 25 on WAN2 IP. The correct rule is trigged: The rule that triggered this action is: @94 pass in log quick on bge0 reply-to (bge0 10.10.10.1) inet proto tcp from any to 192.168.1.7 port=smtp flag S/SA keep state label "USER_RULE:NAT SMTP FROM WAN2" but the packet don't pass… same test with WAN1 ON, the same rule is trigged and the packet correctly pass.. Thanks

@jimp: @greatmen: bcoz, two treads for 1 same issue with only different tittle isnt kinda spamm? No, because your problem is not the same as the original poster's. It may seem similar, but it's still a separate issue. It's considered hijacking someone else's thread. im sorry, it used to be like that in other forums… ill leave this thread. good luck to the thread starter!

Ok while adding the static port entry on both interfaces got it working, it only stays working for about 2-3 hours.  Then you have to reset the state table to get it to connect again.  Anyone have an idea why that is?  For obvious reasons, resetting the state table is not a viable workaround. Thanks, Roy

No one with an idea ?

NAT reflection doesn't seem to work here either, my NAT rules are also using aliases, have tried with IP addresses too but that didn't work either.

Will give it a whirl when I get back to the office in a day on Saturday. Thanks. BTW, bought the book and I'm reading through it. So far so good :)

I think I've figured it out.  The problem was with an alias I'd created.  I didn't know that VNC is a built-in alias for port 5900, so I created one with the same name and port number.  The last time I switched over to the pfSense cluster, the VNC connection port forwards were the first and only things I tried; when those didn't work I assumed that no port forwards worked.  So today I selected VNC from the drop-down instead of typing the alias I created and packets were allowed through (to the firewall at least; I was testing this with a notebook on a fake WAN) where before they were being dropped by the Default Deny rule.  All apologies for my carelessness.

Why not simply enable or disable the firewall rules that allow traffic to the NAT entries? Or are you switching a single port between multiple internal systems?

My outbound NAT is setup like this atm, does it look correct? [image: outbound-nat.gif]