I have attached the diagram. I guess I have messed up somewhere in firewall rules and NAT rules. My firewall rules are something like this WAN Proto: -IPv4 TCP Source: IP address (x.x.x.240) of the system from which I remotely access pfsense. port: * Dest: Ip address of pfsense x.x.x.216 port: 443 NAT IP: x.x.x.216 (Pfsense IP) NAT port:: 443 LAN: Proto: IPv4 TCP Source : * Port: * Dest: !LAN Address port: 443 NAT IP: x.x.x.193 Port:3128 I am able to access pfsense box via WAN but I am not able to access DHCP/NAT server behind pfsense eventhough it is having public IP. Any idea where I am going wrong.  

Thanks Palmer.. That did the trick!! Cheers

Did you try adding a rule on the outbound nat page? Try (Manual Outbound NAT) adding a rule on the interface in question wit the source being the internal IP/32 and the NAT addressing being the public IP they are using. Move that rule before the other rules.

Sorry for the lack of proper terms. The SIP adapter / client I use behind pfsense on a fios connection had to have its re-registration times cut from 3600 to about 60? I didn't see a keep alive option on that one.  Of course "recheck" isn't an option. This was a change in behavior 100% related to pfsense though.  Minor annoyance.  Easily handled. BTW - The reason I was looking at this old thread again is because my son wants to use my xmpp server there for video/audio behind pfsense / NAT. Figured it out.  Just needed to use a STUN server.  Thanks.

can lan1 and lan2 use the internet? So running on virtual?  is the lan1 rules the default or did you create them?  Do you have any floating rules?  So 2k3 has no firewall, not even 3rd party antivirus/firewall suite? Does it have a gateway set to pfsense an IP? Same for you lan1 devices. Issue I have seen when users create rules is they they think its any any, ie source is any and dest is any but they have protocol set to tcp or tcp/udp which would not allow icmp (ping)

What do you have for Firewall - NAT - Port Forward?

KOM, Perfect. Thanks, ~eric

@cceraja: Hello Derelict, I agree that it may not be a standard way. But still when a feature is there why not exploit it? Look at the advantage it has… You don't need additional switches and additional nic for subnets. Regards, Raja That's not a feature, it's an undefined configuration that is highly recommended against. Kind of like people using a high or low IP address of a subnet. It can work in some setups, but expect strange stuff to happen.

Many thanks for your reply, Ok with the manual outbound nat enabled and the rule of SNAT I reach perfectly the server on port 81 from the outside However, though the subnet 192.168.2.x / 24 does not reach server 192.168.1.200 on port 80. Instead, if I enable automatic outbound nat perfectly reach the server 192.168.1.200 on port 80 but not the server 192.168.10.230 on port 81. I forget what? thanks again

We upgraded to 2.1.5. If I am right there was something about that in the version-info. With the new version it works because they changed things in the behavior on CARP failover regarding to deleting states. Best regards Patrick

1.  If you have Auto NAT Rule generation on, which it is by default I believe, then the required rule should be created. 2.  If you have Manual enabled before you created your port forward then you will have to create the firewall rule. I had an issue like this where I had to ensure VoIP packets leaving WAN had to be within a specified port range.  I think I just had to create the WAN rule and that was it.  I'll check in the morning.

THANKS A LOT!!!! really I'm very happy to have always answers from someone, so this is one reason more to install pfsense and to know any problems u can ask in forum and someone is ready to help u. bye and again thanks. roberto

Yeah, that's how much I understood of it as way. I just don't understand why that "default route" is nowhere to be seen in the GUI. That made it so much more harder to understand what's happening. Thanks for the explanation though

It worked right up to the moment I added the pfsense box. So I knew it's not the ISP. Its a setting blocking it somewhere. I'll just have to keep poking around. Thanks, Rick

For a reason that I don't know, NAT reflection was disabled. When I enabled it, the Outbound rules came back. Why?

From pfSense side that all looks good. Are there settings in TeamSpeak that would restrict it to responding only to connects from local LAN IPs? Or some subnet of "all"?

Set up the interface as the modem's vlan. Can't get the rule to fire up if it's not listening on the right interface.