I doubt that natreflection (or at least the way pfSense does it currently) will work for a crappy protocol like SIP.

Forgot to say thank you.. Thanks, Mark

Ok m8 Here it goes [image: 1.JPG] [image: 1.JPG_thumb] [image: 2.JPG] [image: 2.JPG_thumb] [image: 3.JPG] [image: 3.JPG_thumb]

Well, I setup up another machine with following those instructions - real basic… Still no good... So I know it's not the pfSense setup (I've setup pfSense countless times in different configs, so I doubted it was setup wrong). Anyway, I think I figured out the problem after watching the traffic on the network interfaces - the switches weren't configured to be in promiscuous mode... I reconfigured and was able to get to one website across the bridged interface. Tomorrow (well, today now, for me), I will go ahead and try it through pfSense. Thanks again... If I still need help, I'll go ahead and post back.

This is an old post but for Search reasons, I thought I would reply. ProxyARP and 1 to 1 NAT do not appear to work for FTP in this case.  There are several articles on the forums and on the net about the issues with Ftp -helper. 1.  Configure the VIP and then create CARP NAT.  Don't worry that you aren't doing true failover - it can work with 1 IP. 2.  Configure Port Forwarding and forward FTP to internal server. 3.  Configure rules on WAN interface to internal server. Worked like a charm for me.

For pfSense, I redid the IP addresses, moving the DMZ to a private net.  Trying to maintain the bridged net resulted in too many complications. In the end however, I ended up moving back to Linux as a base because FreeBSD does not support combining NAT and IPSEC.  I did however keep the DMZ as a private net. Denny

It was a problem from my ISP. It is working now.

Yep, the rule in the firewall has also been updated to * Attached the AON's for the three interfaces. Still not succesful. Did you read my PM ? regards, [image: AON2.jpg] [image: AON2.jpg_thumb]

No. What would you do if the pc was directly connected to the internet.

NAT on pfSense doesn't support RTSP so you really should be looking at a proxy for such thing. But again, i have never used that kind of server so might be mistaken. Try enabling static port as is recommended for VoIP phones, probably that might fix it. Or try setting a 1:1 rule only for the server to communicate if you have a spare ip.

Well, that may be so, but this problem exists before even the 2 pfSense networks try to connect. The error is taking place just trying to connect to battle.net itself. The other odd thing I've noticed is that the 2 different versions of pfSense seem to be setting things up exactly the same. (Which they should) When I run pfctl -sr or pfctl -sn I see exactly the same entries. At least with regard to the settings for port 6112 inbound and the change in the settings for the outbound NAT. But the thing that's consistent is that it doesn't work properly on this end. I wonder if this is effecting anyone else who needs the static-port setting, or if it's just my system? Update: I was able to track down a file for a 1.2RC3 build. It also had the same problems here. It seems to be something with this location. This is very strange because everything else between the 2 locations is very similar, and the firewall here works great for everything else. So far I can't track down any specific reason why this happens. I guess it's just another network oddity.

Would adding 'Source / Dest' rules, for port redirection, be considered a bounty topic? Whilst I am EXTREMELY impressed with pfSense, I think the NAT/Redirection could be improved upon. I now have two troublesome points due to the inability to identify Source Dest IPs/Subnets whilst performing redirection: 1. HTTP Proxy - internal clients need to be manually configured or network topology has to change (first is problematic due to mobile users, second is just not a viable workaround for me). Could be fixed (easily?) with a Source IP/Net scope in the redirect 2. Mail configuration for locally hosted server. Whether this is a bug or not, I can't tell. Here is the scenario: WAN IP resolvable to mydomain.com (for which MX record exists) WAN redirect rule for port 143 to go to mailserver.my.lan on LAN LAN client tries to connect to mailserver with public DNS of mailserver.hosted.com but passthrough does not occur as request comes from LAN (or at least that is what appears to be happening). Setting up a LAN redirect for port 143 is simply not an option due to connecting to multiple IMAP servers UNLESS a Destination IP/Net Scope can be implemented. What would probably be better is that if the outgoing LAN packet resolves back to the router then it be classified as WAN source and dealt with as such. There is another fix (maybe more) if internal DNS registrations for local clients are enabled and the LAN host name matches the public DNS record. And when I say fix, I mean the end user doesn't have to reconfigure their mail client whenever they are outside of the LAN. however, that is not such a great fix if you have more than one domain. Many, many thanks for a superb product in any case! n

Thanks! It looks like it's working now.

@sullrich: I had no idea how to fix it but googling tcp auto scaling windows 2003 came up with: http://thesystemadministrator.com/The_System_Administrator/Tips_&Tricks/Disable_TCP_Auto-Tuning_to_Solve_Slow_Network(Vista)/ thanks for your reply, but i don't think that this is the issue. It doesn'tmatter which OS the Client has. It can be an Win2003 Server, an XP Machine oder a Vista Box. Everywhere its the same Problem. I can receive some secondes every package from my Server - an then no –> the Server doenst response. if i took my m0n0 back, with the same conf --> everything work fine. Firewall lets every package pass - nat is configured well. what can i do to help you ? greets, sash sashxp@gmail.com

Cheers, I made that change, and I think I understand a little more about NAT now into the bargain. Thanks Ben

Search the forum for NAT Reflection. You will not be able to do reflection for 1:1 hosts but you can port forward on the WAN interface on top of the 1:1 items for the needed ports. Alternatively setup another DNS server on the internal network and point the internal hosts to it which overrides the DNS IP address to the internal address.

We have 42 subnests. Here is a example of some. nat (inside) 12 10.12.0.0 255.255.0.0 0 0 nat (inside) 13 10.13.0.0 255.255.0.0 0 0 nat (inside) 14 10.14.0.0 255.255.0.0 0 0 global (outside) 12 external ip netmask 255.255.255.224 global (outside) 13 external ip netmask 255.255.255.224 global (outside) 14 external ip netmask 255.255.255.224

RTP is being tranfered over either UDP or TCP. http://en.wikipedia.org/wiki/Real-time_transport_protocol Since it usually uses a port from 16384-32767 you need to take a look at your webcam config and select the right on for your FW rule. VNC uses RTP too and there is no problem with is over pfSense. So i suspect you just used a wrong port in your FW-rule.